asp.net – 使用umbraco的iis应用程序池使用过多的内存

发布时间：2020-12-15 21:04:02 所属栏目：asp.Net 来源：网络整理

导读：我们有一个umbraco 4.11实例,有大约400个节点,运行在iis 7.5,.net 4,windows 2008 r2上.在第一次访问时它消耗大约500mb的内存并且移动到大约900mb.由于该站点将部署在共享主机上,这将导致我们的大量问题. 我已经尝试跟踪内存泄漏的自定义代码,但一无所获.我

我们有一个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中,这将是通过传递给宏的DynamicNodeContext模型的umbraco.NodeFactory.Node,INode或DynamicNode.您应该避免使用Document,Content对象等,因为它们会调用数据库.

你是如何访问媒体的？从4.8开始,CMS中保存的所有媒体都以与节点相同的方式编制索引.在4.7中,您将使用新的媒体(id)来检索媒体库中的文件.这会打击数据库,因此每个请求都非常昂贵.您应该使用新的DynamicMedia(id),因为它会从索引中检索文件信息,并且非常快速并且会产生重大影响.

你在缓存宏吗？仔细使用此功能可以大大帮助.即使对XML缓存的调用也有足迹,诸如渲染站点的主导航之类的东西可能非常昂贵.我倾向于缓存像这样的复杂导航宏,这些宏在整个站点中重复出现.是的,仍会在第一次请求时造成打击,但随后不会.但是,如果您的资源有限,请不要使用宏缓存.有选择性地考虑哪些页面获得最多流量以及哪些页面具有更复杂的节点遍历查询.

您在文档类型中存储了哪些数据？你不应该真的要审查这个,但是值得检查一下,特别是如果你对你的网站规模不断增长很有信心.如果使用多节点选择器,是否存储XML或CSV？ CSV实际上更小,因为它只存储节点的ID.存储XML对于结构化数据和使用XSLT进行访问非常有用,但如果您只是提取媒体或内容节点的ID,则这是多余的.您是否还有其他未使用的字段？这些将发布到XML,并可以随着XML的增长节省资源.更多字段还意味着在保存和发布节点时更多地访问数据库.所以越少越好.

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

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

希望这有所帮助.

（编辑：李大同）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!