1

我有一个已经存在多年的 .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 输出，以防万一有人看中！

https://pastebin.com/dBE5VAYJ

4

1 回答 1

1

我想说：在您捕获转储的状态下，该进程处于垃圾收集的中间。对象结构已损坏，您将无法分析对象，因此很难看出是什么使用了内存。

使用Procdump并将其配置为根据虚拟内存大小进行故障转储，例如，如果您的应用程序通常仅使用 1 GB，则为 2 GB。那应该是-m命令行开关。

希望长期的垃圾收集过程尚未开始，您将能够查看内存中的对象!dumpheap -stat或将故障转储导入 Jetbrains dotMemory 进行分析。

另一个观察结果在您的调用堆栈中。有 26 个GetBuildResultFromCacheInternal()。我认为这表明该应用程序正在被回收。

于 2018-12-21T17:33:39.323 回答