ASP.NET 应用程序 - 突然出现高 CPU/内存问题答案

【问题标题】：ASP.NET application - sudden high CPU/memory issuesASP.NET 应用程序 - 突然出现高 CPU/内存问题
【发布时间】：2018-12-22 01:33:39
【问题描述】：

我有一个 .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

【问题讨论】：

有趣！ 3 票接近，没有一条评论。
在调试方面，语言开始变得重要。 “几乎每个线程” - 94 个线程，32 个 ReliableEnter，这不是“几乎每个”，它恰好是 94 个线程中的 32 个。找出这一点并不难，写下来也不难。但它告诉读者你是否关心细节。
另外：它使用 99% 的 CPU？多长时间？使用 99% 的 CPU 很好，不是吗？这意味着 CPU 为您花费的钱做了一些事情。下一个：它使用 3 GB 的 RAM？那真的是 RAM（工作集）还是虚拟内存？为什么要在 3 GB 后面加上感叹号？我有使用 18 GB 的应用程序，这完全没问题。如果您认为 3 GB 太多，请告诉我们您的预期或“正常”。
使用ETW to trace CPU usage和other tools to trace memory usage

标签： c# asp.net windbg dump debugdiag

【解决方案1】：

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

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

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

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

【讨论】：