我们收到了很多内存异常，我们似乎无法诊断发生了什么。这似乎是一个问题，会在几分钟内将内存使用率从300兆的增加到千兆以上。现在这是一个IIS应用程序，有3个应用程序域在不同的线程池中运行。
我们希望记录内存异常即将发生的时间。所以我们可以尝试找到一种模式。我的问题是：最好的方法是什么？有没有办法每分钟查询内存使用情况，看看有多高，并发送警报电子邮件。或者编写一个可以监控CLR内存使用情况的应用程序？一个想法或方向更受欢迎。
修改
我正在使用Perfmon，但除非我正在观看这个过程，否则它不会那么有用。我只能看到是什么以及什么时候。我还使用了红门内存配置文件工具，顺便说一句，这是很棒的，只是我似乎无法点击导致异常的页面或进程。
答案 0 :(得分：3)
在您的服务器上安装ADPlus（它是Windows Debugging Tools的一部分）。当您开始观察异常高的内存使用量时，使用以下方法捕获内存转储：
adplus -hang -p <PID> -quiet -o <dump file folder path>
<PID>是您可以从tasklist.exe获得的工作流程的流程ID。
如果您在此问题发生时并不总是在身边，那么您可以使用DebugDiag自动捕获内存转储：
在专用或虚拟内存使用达到特定阈值时，在泄漏跟踪模式下使用DebugDiag来触发进程转储。也就是说，我并不总是觉得这很可靠。
在抛出CLR异常时，在崩溃模式下使用DebugDiag捕获转储。您可以使用“高级设置”将DebugDiag配置为在遇到类型为System.OutOfMemoryException的CLR异常时生成完整内存转储。这更可靠，肯定会触发。仅使用高级设置 - ＆gt;例外，请勿触摸未配置的第一次机会例外，将此设置保留为无。
一旦你的内存转储启动WinDBG，加载转储文件并加载SOS并开始探索。
Tess Ferrandez的blog是一个很棒的.NET调试资源，她有很多关于如何追踪内存泄漏的文章和实验：
If it is broken, fix it you should - memory issue articles
.NET Debugging Demos Lab 6:_Memory Leak
.NET Debugging Demos Lab 6:_Memory Leak - Review
.NET Debugging Demos Lab 7: Memory Leak
.NET Debugging Demos Lab 7: Memory Leak - Review
PerfMon计数器很有用，可用于确认您有内存泄漏，但它们并不能说明整个故事。 WinDBG和SOS是您需要用来查找内存使用位置的工具。
答案 1 :(得分：2)
Perfromance monitor aka Perfmon是您的朋友 - 免费且不侵入且轻量级并且可以安全地运行如果您使用频率较低的采样（每隔几秒钟），请在生产服务器上它可以做的最小化是为您的进程（w3wp.exe）采样内存/ CPU使用并将它们存储在一个文件中。
由于您还没有在应用程序中共享您正在执行的操作，因此我无法建议存储性能计数器，但ASP.NET和.NET以及CLR中有很多。
由于你正在获得CLR内存异常，我的预感是GC由于固定对象或某些东西而无法正常工作。我怀疑它是非托管资源，例如位图没有被释放，尽管它可能是。
以下是我建议的柜台清单：
.NET CLR内存
进程
<强> ASP.NET
答案 2 :(得分：1)
试试RedGate Memory Profiler。我认为它适用于ASP.NET站点（他们的性能分析器确实如此）。
答案 3 :(得分：0)
使用内存分析器。那里有几个很好的，例如来自红门的JetBrains dotTrace或ANTS Memory Profiler。在stackoverflow处有几个讨论，其中包含许多其他提示和建议。
答案 4 :(得分：0)
如果您买不起优秀的个人资料，您应该使用微软推荐的内容，http://msdn.microsoft.com/en-us/library/ee817663.aspx
答案 5 :(得分：0)
我会在“崩溃”模式下使用ADPlus在发生异常时捕获内存转储，然后使用WinDbg和SOS来计算占用所有内存的内容。
答案 6 :(得分：0)
使用dotTrace或YourToolkit .Net，您可以将探查器附加到ASP流程，它们具有试用版，因此您无需立即花钱。使用这些分析器，您可以选择内存开始增加的时间线（您可以在图形中直观地看到内存使用情况），因此应该很容易选择范围并了解导致内存使用率如此之高的原因。 / p>