我已经尝试跟踪内存泄漏的自定义代码,但一无所获.我还在应用程序池内存转储上运行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
解决方法
你是如何访问节点内容的？最基本的错误是使用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重复使用代码.这意味着我总是可以确定当我查询媒体项,布尔属性,根节点等时.我每次都使用相同的代码.此时我还可以执行一些额外的缓存.因此,如果我有一个“站点设置”节点,我可以在自定义轻量级对象中缓存它的属性,这样我就不必在每次需要访问时查询“站点设置”节点,然后查询其属性网站范围内的数据,如地址,电话号码,网址等.
希望这有所帮助.
