我们有一个带有约400个节点的umbraco 4.11实例,该实例在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
,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等。
希望这有所帮助。
本文收集自互联网,转载请注明来源。
如有侵权,请联系[email protected] 删除。
我来说两句