c# - 当 .NET 不在垃圾回收 (GC) 中间时，如何捕获 .NET 进程的进程内存转储

Question

在捕获转储文件并对其进行分析时(例如在 WinDbg 中)，我经常会收到数据可能不准确或命令可能无法访问的警告，因为转储文件时进程正处于 GC 中间已收集。

我们在做内存分析的时候，经常是因为进程内存高，内存压力大，估计逼迫.NET频繁GC。

如何避免在 GC 期间进行转储？有没有办法知道什么时候捕获转储文件是安全的？

Answer 1

我不是这方面的专家，但我注意到您可以使用 .NET 运行时的性能计数器来监视一些有趣的事情 - 其中之一是垃圾收集器在运行期间分配的字节数这是最后一个系列。Performance Counters in the .NET Framework 中Allocated Bytes/second 的描述状态:

Displays the number of bytes per second allocated on the garbage collection heap. This counter is updated at the end of every garbage collection, not at each allocation. This counter is not an average over time; it displays the difference between the values observed in the last two samples divided by the duration of the sample interval.

根据我的测试，如果将性能监视器的更新间隔设置为 1 秒，并仔细查看 Allocated Bytes/second 指标，它似乎显示的值为 0 收集完成后。所以我假设，无论收集是否在进行中，您都可以从这个值中得出。

我通过在 VS 2015 中构建一个小应用程序来检查它，它能够显示是否正在进行垃圾收集。如果是这种情况，则指标的值不同于 0。

更新(感谢 Thomas)

可以使用 ProcDump用于监视性能计数器并以自动方式创建转储。这样做的正确方法是:procdump ProcessName -s 1 -ma -pl "\.NET CLR Memory(ProcessName)\Allocated Bytes/second"1000 如果值下降将触发转储一千以下。

这应该有效，因为如果没有进行垃圾收集，该值仅为零。

如果您使用的不是英文版操作系统，则必须找出性能计数器的正确语言特定名称(可以通过查看上面提供的 MSDN 链接并切换到其他语言来完成那里)。例如。德国名字会是 "\.NET CLR-Speicher(ProcessName)\Zugeordnete Bytes/Sek."。