IIS应用程序池在使用Umbraco时内存占用过高

6
我们有一个运行在IIS 7.5、.NET 4、Windows 2008 R2上的Umbraco 4.11实例,大约有400个节点。初次访问时会消耗约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


你找出这个问题的原因了吗? - Digbyswift
如果从转储中只获得了这么少的信息,请尝试更多了解该转储,http://msdn.microsoft.com/en-us/library/ee817660.aspx - Lex Li
3个回答

10
正如Eric Herlitz在他的回答中指出的那样,Umbraco安装程序底层有许多事情要处理。简言之,400个节点不应该太过于影响性能,因为它们会被发布为XML并进行缓存。此外,标准的Umbraco安装程序并不需要太多资源,所以肯定存在其他原因,并且可能是相当基础的。因此,请检查以下内容: 您如何访问节点内容? 可能犯的最基本的错误是在不必要的情况下使用Umbraco API来访问节点内容。对于只需要已发布数据(例如在发布网站中显示内容)的只读场景,应该使用查询XML缓存中已发布数据的方法。在4.11.x版本中,可以通过传递给宏的DynamicNodeContext模型来使用umbraco.NodeFactory.NodeINodeDynamicNode。应避免使用DocumentContent等对象,因为它们会调用数据库。 您如何访问媒体文件? 自从4.8版本以来,所有在CMS中保存的媒体文件都像节点一样进行索引。在4.7版本中,您将使用new Media(id)来检索媒体库中的文件,这会访问数据库,因此每个请求非常昂贵。您应该使用new DynamicMedia(id),因为它从索引中检索文件信息,非常快速且使结果显著不同。 您是否缓存了宏? 谨慎使用此功能可以大大帮助优化性能。即使对XML缓存的调用也会有一定的占用率,例如渲染网站的主导航可能相当昂贵。我倾向于缓存像这样在整个网站上重复出现的复杂导航宏。是的,它们仍将在第一次请求时产生影响,但随后不会再有影响。然而,如果资源有限,请不要过度缓存宏。请进行选择并考虑哪些页面流量最大以及哪些具有更复杂的节点遍历查询。您在文档类型中存储了哪些数据?虽然您可能不需要审核此内容,但检查一下仍然值得,尤其是如果您担心网站规模会扩大。如果您使用多节点选择器,则存储XML还是CSV? CSV要小得多,因为它仅存储节点的ID。存储XML对于结构化数据和使用XSLT访问非常有用,但如果仅提取媒体或内容节点的ID,则是冗余的。您是否还有未使用的其他字段?这些将发布到XML中,并且随着XML的增长可以节省资源。更多字段也意味着保存和发布节点时需要进行更多数据库访问。所以越少越好。 是否存储不需要的数据?往往有将所有内容都放入CMS可编辑中的倾向。LinkedIn链接、Twitter ID、公司电话号码、支付网关回调页面等等。但事实上,像这样的内容很少甚至不会改变。这些可以安全地降级为web.config文件中AppSettings模块中的键。然后通过静态“ConfigConstants”类访问这些键使其成为只读。这样可以节省一些XML缓存空间并减轻保存和发布页面的负荷。这还意味着您不必查询XML缓存以获取数据。 是否具有中间查询层和/或扩展方法?这并非必需,但我喜欢拥有防止UI中重复使用代码的扩展方法。这意味着每次查询媒体项、布尔属性、根节点等时,我都可以确保使用相同的代码。我还可以在此处执行一些额外的缓存。因此,如果我有一个“站点设置”节点,则可以将其属性缓存在自定义轻量级对象中,以便每次需要访问站点范围的数据(例如地址、电话号码、URL等)时,不必查询“站点设置”节点及其属性。
希望这对您有所帮助。

感谢您的全面回复。我已经检查过我的代码,符合您的指南。但是我们没有使用Umbraco宏,而是在整个网站中使用了class ASP.net webcontrols。当然,这些控件使用内置的ASP.net缓存功能。我想知道是否使用ASP.net web控件可能会导致这种行为? - dannni_mo
可能。这取决于您如何访问Umbraco内容 - 您是否在站点上运行了SQL Profiler?如果您看到对数据库的调用过多,则几乎可以确定这是问题所在。b)您做了多少缓存。显然,您进行的缓存越多,内存使用量就会越多。 - Digbyswift

0

需要缓存400个节点,并且还有很多活动没有被你的测试覆盖。我们之前已经讨论过这个问题了,请参考优化Umbraco内存占用

另外,你配置了什么数据库?是本地数据库还是SQL Server?


0

过去我们需要处理的一些问题:

  • 网站是否使用imagegen?如果是,它是否是最新版本?
  • 网站是否使用任何类型的定期导入/导出?是否有直接调用数据库的内容?
  • 备份任务是在什么时候运行的,是针对数据库还是网站文件?

网页内容由stack overflow 提供, 点击上面的
可以查看英文原文,
原文链接