我有一个.NET Framework 4 ASP.NET应用程序（WebForms和MVC的组合），已经运行了很多年。在过去的几个月中，应用程序突然停止响应，并且应用程序池将开始使用99％的CPU和3gb（！）的RAM。大约每2周发生一次，尽管今天已经发生了两次。
通常，我们终止进程并重新启动有效的应用程序池，但是现在我们使用DebugDiag进行了转储，以尝试深入了解此问题。但是，我在弄清问题出在什么地方时遇到了麻烦-主要原因是看来垃圾收集器正在运行或处于异常状态-'！dumpheap'为我提供了以下信息
The garbage collector data structures are not in a valid state for traversal.
It is either in the "plan phase," where objects are being moved around,
or we are at the initialization or shutdown of the gc heap. Commands related
to displaying, finding or traversing objects as well as gc heap segments may
not work properly. !dumpheap and !verifyheap may incorrectly complain of
heap consistency errors.
Address MT Size Object <exec cmd="!ListNearObj /d
01ef1000">01ef1000</exec> has an invalid method table.
我已经运行〜* e！clrstack并获得了很多输出，几乎每个线程都显示'System.Threading.Monitor.ReliableEnter'...这正常吗？
我只是想知道是否有人基于以上内容了解任何信息，或者在分析此转储文件时有任何提示？转储是一个完整的转储，所以大约3gb
我将clrstack输出粘贴到下面，以防万一有人幻想一下！
答案 0 :(得分：1)
我会说：在您捕获转储的状态下，该过程处于垃圾回收的中间。这些对象的结构已损坏，您将无法分析这些对象，因此很难知道什么使用了内存。
使用Procdump并将其配置为根据虚拟内存大小进行崩溃转储，例如如果您的应用程序通常仅使用1 GB，则为2 GB。那应该是-m命令行开关。
希望持久的垃圾回收过程尚未开始，您可以使用!dumpheap -stat查看内存中的对象，或者将崩溃转储导入Jetbrains dotMemory进行分析。
另一个观察是在您的调用堆栈中。有26个GetBuildResultFromCacheInternal()。我认为这表明该应用程序正在被回收。