gpt4 book ai didi

asp.net - 使用 umbraco 的 iis 应用程序池过度使用内存

转载 作者:行者123 更新时间:2023-12-04 14:01:52 31 4
gpt4 key购买 nike

我们有一个 umbraco 4.11 实例,大约有 400 个节点,在 iis 7.5、.net 4、windows 2008 r2 上运行。第一次访问时,它消耗大约 500mb 的内存,并移动到大约 900mb。由于该站点将部署在共享主机上,这会给我们带来巨大的问题。

我尝试跟踪内存泄漏的自定义代码,但一无所获。我还在应用程序池内存转储上运行 Windbg 却发现以下报告:

--- Usage Summary ---------------- RgnCount ----------- Total Size -------- %ofBusy %ofTotal    
Free 461 7fb`9ab99000 ( 7.983 Tb) 99.79%
<unknown> 1201 4`4ec32000 ( 17.231 Gb) 98.00% 0.21%
Image 2604 0`1123e000 ( 274.242 Mb) 1.52% 0.00%
Heap 74 0`037c2000 ( 55.758 Mb) 0.31% 0.00%
Stack 172 0`01c00000 ( 28.000 Mb) 0.16% 0.00%
Other 9 0`001b2000 ( 1.695 Mb) 0.01% 0.00%
TEB 57 0`00072000 ( 456.000 kb) 0.00% 0.00%
PEB 1 0`00001000 ( 4.000 kb) 0.00% 0.00%

--- Type Summary (for busy) ------ RgnCount ----------- Total Size -------- %ofBusy %ofTotal
MEM_PRIVATE 628 4`50cda000 ( 17.263 Gb) 98.18% 0.21%
MEM_IMAGE 3453 0`135fc000 ( 309.984 Mb) 1.72% 0.00%
MEM_MAPPED 37 0`01181000 ( 17.504 Mb) 0.10% 0.00%

--- State Summary ---------------- RgnCount ----------- Total Size -------- %ofBusy %ofTotal
MEM_FREE 461 7fb`9ab99000 ( 7.983 Tb) 99.79%
MEM_RESERVE 985 4`226fb000 ( 16.538 Gb) 94.06% 0.20%
MEM_COMMIT 3133 0`42d5c000 ( 1.044 Gb) 5.94% 0.01%

--- Protect Summary (for commit) - RgnCount ----------- Total Size -------- %ofBusy %ofTotal
PAGE_READWRITE 881 0`2edd3000 ( 749.824 Mb) 4.16% 0.01%
PAGE_EXECUTE_READ 406 0`0f016000 ( 240.086 Mb) 1.33% 0.00%
PAGE_READONLY 1157 0`02c1a000 ( 44.102 Mb) 0.24% 0.00%
PAGE_WRITECOPY 422 0`01cde000 ( 28.867 Mb) 0.16% 0.00%
PAGE_EXECUTE_READWRITE 121 0`00328000 ( 3.156 Mb) 0.02% 0.00%
PAGE_EXECUTE_WRITECOPY 89 0`0026e000 ( 2.430 Mb) 0.01% 0.00%
PAGE_READWRITE|PAGE_GUARD 57 0`000e5000 ( 916.000 kb) 0.00% 0.00%

--- Largest Region by Usage ----------- Base Address -------- Region Size ----------
Free 5`3f530000 7f9`54ca0000 ( 7.974 Tb)
<unknown> 2`835b4000 0`7bf7c000 ( 1.937 Gb)
Image 7fe`e79da000 0`01338000 ( 19.219 Mb)
Heap 0`0c5e0000 0`00961000 ( 9.379 Mb)
Stack 0`00960000 0`0007b000 ( 492.000 kb)
Other 0`006b0000 0`00181000 ( 1.504 Mb)
TEB 7ff`ffe90000 0`00002000 ( 8.000 kb)
PEB 7ff`fffdb000 0`00001000 ( 4.000 kb)

其他关于内存托管部分的报告被忽略,因为它们没有显示任何异常。
转储显示该区域或非托管部分消耗了最多的内存,这表明 win32 api 调用或其他我不知道的东西。
我需要知道的是这种内存使用情况是否正常?如果不是,可以对其应用的原因和修复是什么?
如果您能帮助我解决这个问题,我将不胜感激!
0

最佳答案

正如埃里克·赫利茨 (Eric Herlitz) 在他的回答中指出的那样,Umbraco 装置的幕后有很多事情正在发生。简而言之,400 个节点应该不会造成太大问题,因为它们是作为 XML 发布然后缓存的。此外,标准的 Umbraco 安装并不需要资源,因此几乎可以肯定还有其他东西在起作用,而且可能非常基本。因此,请检查以下内容:

您如何访问节点内容? 最容易犯的错误是在不需要时使用 Umbraco API 访问节点内容。对于只需要已发布数据(例如在已发布网站中显示内容)的只读场景,您应该使用在 XML 缓存中查询已发布数据的方法。在 4.11.x 中,这将是 umbraco.NodeFactory.Node , INodeDynamicNode通过 DynamicNodeContext模型传递给宏。您应该避免使用 Document , Content对象等,因为它们会调用数据库。

您如何访问媒体? 从 4.8 开始,保存在 CMS 中的所有媒体都以与节点相同的方式进行索引。在 4.7 中,您将使用 new Media(id)检索媒体库中的文件。这会影响数据库,因此每个请求都非常昂贵。您应该使用 new DynamicMedia(id)因为这会从索引中检索文件信息,并且速度非常快,并且会产生很大的不同。

你在缓存宏吗? 小心使用此功能可以大有帮助。甚至对 XML 缓存的调用也有占用空间,并且诸如呈现站点的主导航之类的事情可能非常昂贵。我倾向于缓存像这样在整个站点重复的复杂导航宏。是的,第一个请求仍然会导致命中,但随后不会。但是,如果您的资源有限,请不要对宏缓存发疯。有选择性地考虑哪些页面获得的流量最多,哪些页面具有更复杂的节点遍历查询。

您在文档类型中存储了哪些数据? 您不应该真的必须查看此内容,但值得检查一下,尤其是当您意识到网站规模不断扩大时。如果您使用多节点选择器,您是存储 XML 还是 CSV? CSV 小得多,因为它只存储节点的 ID。存储 XML 对于结构化数据和使用 XSLT 进行访问很有用,但如果您只提取媒体或内容节点的 ID,则是多余的。您是否还有其他未使用的字段?这些将被发布到 XML 中,并且可以随着 XML 的增长而节省资源。更多的字段也意味着在保存和发布节点时更多的数据库访问。所以越少越好。

您是否正在存储不需要的数据? 有一种趋势是让所有内容都可以由 CMS 编辑。 LinkedIn URL、Twitter ID、公司电话号码、支付网关回调页面等。但实际上,这样的事情即使有也不会经常改变。这些可以安全地降级为 web.config 文件的 AppSettings 模块中的键。然后通过静态“ConfigConstants”类访问,使 key 只读。这会在 XML 缓存中节省一些空间并减轻保存和发布页面的负担。这也意味着您不必为数据查询 XML 缓存。

你有中间查询层和/或扩展方法吗? 这绝不是必要的,但我喜欢使用扩展方法来防止通过 UI 重复使用代码。这意味着我始终可以确定,当我查询媒体项、 bool 属性、根节点等时,我每次都使用相同的代码。此时我还可以执行一些额外的缓存。因此,如果我有一个“站点设置”节点,我可以将它的属性缓存在一个自定义的轻量级对象中,这样我就不必在每次需要访问时查询“站点设置”节点及其属性站点范围的数据,如地址、电话号码、URL 等。

希望这有所帮助。

关于asp.net - 使用 umbraco 的 iis 应用程序池过度使用内存,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/18029808/

31 4 0
Copyright 2021 - 2024 cfsdn All Rights Reserved 蜀ICP备2022000587号
广告合作:1813099741@qq.com 6ren.com