检测ASP.NET中的内存泄漏

My development team is using ASP.NET 3.5 / 4.0 right now, and our sites are running on IIS 7.5. Recently, we've been having problems (about once a week) that are causing Out of Memory exceptions to be thrown in our ASP.NET applications. The "Solution" is to restart the application pool on our website. I say "Solution" because it's hardly a solution; it's more of a bandage that's just keeping our application pool running at a reasonable state. It seems to me that some application or many applications are leaking memory, which is building up over time and causing the out of memory exception. While I can set IIS to periodically restart the application pool, I'd rather know how I can detect the memory leaks in order to attempt the fix the program rather than keep applying band-aids. Are there any tools out there that can possibly detect and log memory leaks for ASP.NET applications?

我的开发团队现在正在使用ASP.NET 3.5 / 4.0，我们的站点在IIS 7.5上运行。最近，我们遇到了一些问题（大约每周一次），这些问题导致我们的ASP.NET应用程序抛出内存不足异常。 “解决方案”是重新启动我们网站上的应用程序池。我说“解决方案”因为它不是解决方案;它更像是一种绷带，只是让我们的应用程序池保持在合理的状态。在我看来，一些应用程序或许多应用程序正在泄漏内存，这会随着时间的推移而累积并导致内存不足异常。虽然我可以设置IIS以定期重新启动应用程序池，但我宁愿知道如何检测内存泄漏以尝试修复程序而不是继续应用band-aids。是否有任何工具可以检测和记录ASP.NET应用程序的内存泄漏？

Also, we really started seeing more of this problem when we switched to using Telerik's RAD controls. Has anyone else had problems similar to this using these controls?

此外，当我们切换到使用Telerik的RAD控件时，我们真的开始看到更多这个问题。有没有其他人使用这些控件有类似的问题？

Thanks,

谢谢，

Aaron

亚伦

5 个解决方案

#1

I previously posted this guide in response to another question, but that question and my answer appear to have been deleted. It's not for the faint of heart:

我之前发布了此指南以回答另一个问题，但该问题和我的回答似乎已被删除。这不适合胆小的人：

Install the Debugging Tools for Windows (Available as part of the Windows SDK) on the server
在服务器上安装Windows调试工具（作为Windows SDK的一部分提供）
When the application has been running for a while, use adplus to capture a memory dump of the process (It's useful to use something such as Process Explorer to find the correct process ID to dump):

当应用程序运行一段时间后，使用adplus捕获进程的内存转储（使用Process Explorer之类的东西来查找要转储的正确进程ID很有用）：

ADPLUS -hang -p <process id> -o .

ADPLUS -hang -p <进程id> -o。
This will create a directory containing the memory dump. You can now use windbg, and open the dump file (File -> Open Crash Dump...)

这将创建一个包含内存转储的目录。您现在可以使用windbg，并打开转储文件（文件 - >打开崩溃转储...）
The joys of unmanaged code now appear. But you use something called Son of Strike, which understands .NET code, to see what objects are allocated. First you load SOS:

现在出现了非托管代码的乐趣。但是你使用一种叫做攻击之子的东西来理解.NET代码，看看分配了什么对象。首先加载SOS：

.loadby sos mscorwks

.loadby sos mscorwks

And then you ask it to examine the managed heap:

然后你要求它检查托管堆：

!dumpheap -stat

This generally spews a ton of output, but there are two columns showing the number of instances and the amount of memory being consumed, by type. Some types you expect to see a lot of (e.g. String), but if, say, there are thousands of instances of one of your own types, you might be leaking these objects somehow. One that's caught me in the past is hooking up an event handler in an object to a static event in the application - that event then has a live reference to every one of those objects.

这通常会产生大量输出，但有两列显示实例数和按类型消耗的内存量。你期望看到很多类型的某些类型（例如字符串），但是，如果你自己的类型有数千个实例，那么你可能会以某种方式泄露这些对象。过去引起我注意的是将对象中的事件处理程序连接到应用程序中的静态事件 - 该事件随后会对这些对象中的每个对象进行实时引用。

I can never remember how most of this works, and generally refer to this cheat sheet for SOS

我永远不会记得大部分工作原理，并且通常会参考这个SOS的备忘单

Tess Ferrandez has a good blog which sometimes covers .NET debugging using the unmanaged debuggers

Tess Ferrandez有一个很好的博客，有时候会使用非托管调试器进行.NET调试

E.g. a post from last May, detailing a potential problem if you use XmlSerializers with a non-default constructor.

例如。来自去年五月的帖子，详细说明了如果将XmlSerializers与非默认构造函数一起使用时可能出现的问题。

#2

There are many memory profilers out there.

那里有很多内存分析器。

One popular one is DotTrace, another is the ANTS memory profiler, both are commercial offerings.

一个流行的是DotTrace，另一个是ANTS内存分析器，两者都是商业产品。

#3

You can get down to a very low level without paying for a third party tool. This is not for the faint of heart though.

您可以在不支付第三方工具的情况下降低到非常低的水平。这不适合胆小的人。

Get Started: Debugging Memory Related Issues in .Net Application Using WinDBG and SOS

入门：使用WinDBG和SOS调试.Net应用程序中的内存相关问题

Memory Leak Detection Using Windbg

使用Windbg进行内存泄漏检测

#4

A .Net memory leak for ASP is going to be limited to anything that persists. Application state and to a lesser extent, session state.

ASP的.Net内存泄漏将限于任何持续存在的内容。应用程序状态，在较小程度上，会话状态。

Anything that works within these areas are the first to check.

在这些区域内工作的任何东西都是第一个检查。

Also, static objects in any class, especially lists or anything of the sort.

此外，任何类中的静态对象，尤其是列表或任何类型的东西。

#5

You can also try using the asp.net web profiler. It is a free tool which allows you to view information as it is stored in memory while the application is running.

您也可以尝试使用asp.net web profiler。它是一个免费工具，允许您在应用程序运行时查看存储在内存中的信息。

This allows you to analyze the asp.net cache, view all the current sessions and contents of the application state.

这允许您分析asp.net缓存，查看应用程序状态的所有当前会话和内容。

#1