Question

我有一个遗留的ASP.NET网站，包含230多个独特的.ASPX文件。该网站每天在许多不同的文件中有数十万次点击。它会泄漏内存，导致全天定期进行流程回收（Windows事件ID 5117：服务应用程序池'％2'的进程ID为'％1'的工作进程已请求回收，因为它已达到其专用字节内存限制。）< / p>

我已经测试了30个最常访问的页面并修复了其中几个页面中的内存泄漏，从而带来了显着的改进。这些页面的负载测试表明它们不再泄漏。但这仍有200多页尚未检查过。但要检查200多个文件，我想知道是否有更有条理或更聪明的事情可以做。

例如，是否有可以添加到Global.asax中的Application_BeginRequest或Application_EndRequest事件处理程序的工具？如果是这样，具体应该监控什么？示例代码和/或讨论将是最有帮助的。

Answer 1

你可以用来组织和填补最大漏洞的最佳工具是windbg。

它附带了windows sdk

继承人参考

http://msdn.microsoft.com/en-us/library/windows/hardware/ff551063(v=vs.85).aspx

一开始习惯命令可能有点困难但是你想要做什么。

1. Install windbg on a machine that is running the site
2. Load test all the pages and get the memory usage way up
3. (optional) Force garbage collection with gccollect()
4. Attach to w3wp.exe with windbg
5. load your symbols (.pdbs and the clr and sos)
6. dump the memory (!dumpheap -stat)

这将按内存中的对象数显示排序列表。当你有泄漏时，你开始积累大量相同的物体。

你需要深入挖掘才能获得这些物体的大小

1. The first number in the row will be the method table copy this number
2. Dump the method table (!dumpheap -mt #######)
3. Choose a single objects ID from the first column and copy this number
4. Get the size of the object (!objsize #######)

（对象数）X（单个对象的大小）=泄漏的大小

找出占用空间最多的类并先插入它们。

这可能也有帮助 - CLR分析器 http://www.microsoft.com/en-us/download/details.aspx?id=14727

追逐传统ASP.Net网站上的内存泄漏

1 个答案: