带有 umbraco 的 iis 应用程序池使用过多的内存答案

【问题标题】：excessive memory usage by iis application pool with umbraco带有 umbraco 的 iis 应用程序池使用过多的内存
【发布时间】：2013-08-03 05:52:16
【问题描述】：

我们有一个 umbraco 4.11 实例，大约有 400 个节点，在 iis 7.5、.net 4、windows 2008 r2 上运行。第一次访问时，它消耗大约 500mb 的 ram，并移动到大约 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

【问题讨论】：

你找到原因了吗？
如果您从转储中获得的信息很少，请尝试了解有关转储的更多信息，msdn.microsoft.com/en-us/library/ee817660.aspx

标签： asp.net memory-management iis-7.5 umbraco windbg

【解决方案1】：

正如 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 中，您将使用 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”类访问。这在 XML 缓存中节省了一点空间，并减轻了保存和发布页面的负担。这也意味着您不必在 XML 缓存中查询数据。

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

希望这会有所帮助。

【讨论】：

感谢您的全面回复。我检查了，我的代码符合你的指导方针。但是，我们没有使用 umbraco 宏，而是在整个网站中使用了类 ASP.net webcontrols。当然，这些控件使用内置的 ASP.net 缓存功能。我想知道使用 ASP.net Web 控件是否会导致这种行为？
可能。这取决于您如何 a) 访问 Umbraco 内容 - 您是否在该站点上运行了 SQL Profiler？如果您看到对数据库的调用过多，那么这几乎肯定是问题所在。 b）你正在做多少缓存。显然，您执行的缓存越多，内存使用量就会越多。

【解决方案2】：

400 个节点需要缓存，并且还有很多活动正在进行，您的测试没有涵盖。我们对此进行了另一次讨论，请参阅Optimizing Umbraco memory footprint

另外，你配置了什么数据库？一些本地 db 或 sql server？

【讨论】：

【解决方案3】：

就像我们过去必须处理的几个领域一样：

网站是否使用 imagegen？如果有，是最新版本吗？
该站点是否使用任何类型的预定导入/导出？有什么可以直接调用数据库的吗？
备份任务何时在数据库/站点文件上运行？

【讨论】：