6

我们有一个 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

4

3 回答 3

10

正如 Eric Herlitz 在他的回答中指出的那样，在 Umbraco 装置的引擎盖下发生了许多事情。简而言之，400 个节点应该不会造成太大问题，因为它们以 XML 形式发布，然后被缓存。此外，标准的 Umbraco 安装并不占用大量资源，因此几乎可以肯定还有其他一些东西在起作用，而且可能非常基本。因此，请检查以下内容：

您如何访问节点内容？可能犯的最基本的错误是在不需要时使用 Umbraco API 访问节点内容。对于只需要已发布数据的只读场景（例如在已发布网站中显示内容），您应该使用在 XML 缓存中查询已发布数据的方法。在 4.11.x 中，这将是umbraco.NodeFactory.Node,INode或DynamicNode通过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”类访问。这在 XML 缓存中节省了一点空间，并减轻了保存和发布页面的负担。这也意味着您不必在 XML 缓存中查询数据。

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

希望这有所帮助。

于 2013-08-05T09:38:38.003 回答
0

400 个节点需要缓存，并且还有很多您的测试未涵盖的活动。我们对此进行了另一次讨论，请参阅优化 Umbraco 内存占用

另外，你配置了什么数据库？一些本地数据库或sql服务器？

于 2013-08-04T07:48:26.547 回答
0

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

  • 该网站是否使用 imagegen？如果是这样，它是最新版本吗？
  • 该站点是否使用任何类型的预定导入/导出？任何会直接调用数据库的东西？
  • 备份任务何时在数据库/站点文件上运行？
于 2013-08-04T21:06:45.027 回答