我正在使用内存分析器、dotTrace 和 perfmon 计数器对 C# 应用程序中的内存进行分析。我无法回答的一个问题是：垃圾收集在我的应用程序中导致的最大延迟是多少？我可以通过使用垃圾收集中的 % time 来获得一个近似值，但是有没有办法为单个收集计时？
【问题讨论】：
标签： .net garbage-collection profiling
您似乎在问 2 个问题 1- GC 是否有最大延迟？ 2- 如何计时单个 GC 收集？
对于 #1，GC 吞吐量大约为 200MB/秒/堆。这意味着 GC 能够在 1 秒内收集大小为 100MB 的堆。 perheap 概念是因为服务器 GC，因为我们为每个 CPU 创建 1 个堆。
所以，如果你有一个巨大的堆，你会看到很大的延迟。 请记住，当 GC 收集内存时，它会以短暂的方式执行此操作，因此与完整 GC 收集相比，Gen0/Gen1 收集非常便宜。
在 .NET 4.0 中，我们添加了一个功能来最小化客户端应用程序的 GC 延迟，该功能在 GC Concurrent 模式下默认启用。在这种模式下，我们尝试在应用程序运行时在后台线程中收集堆。这会为客户端应用程序带来更好的暂停时间
For#2：我们在 .net 框架中有一个非常强大的跟踪，称为 ETW（它在 Windows 中可用，我们在 CLR 中利用它）。 ETW 代表Event Tracing For Windows (。当 GC 即将开始和 GC 完成时，我们会触发 ETW 事件。使用这些 ETW 事件，您可以计算每次 GC 所花费的时间。
更多信息您可以参考CLR ETW reference。此外，对于允许您处理 ETW 事件的良好托管库，请查看TraceEvent
希望对您有所帮助。 谢谢
【讨论】：
可以使用 GC.RegisterForFullGCNotification() 方法对第 2 代收集（较慢的收集）进行计时。但是，这需要收集器的服务器版本（.config 文件中的<gcserver> 元素）。
经典的 Heisenbergian，因为只有工作站版本支持并发 gen #2 集合，所以它失败了，它们可以显着改善延迟。它产生的实际延迟是非常不可预测的，它在很大程度上取决于程序中的线程在并发收集过程中分配和填充 gen #0 和 #1 的速率。强烈建议您不必问这个问题。
【讨论】：
我认为没有“最大延迟”。 GC 在必要时启动 - 当存在内存压力时。在 2GB 的机器上运行的同一个应用比在 4GB 的机器上运行的同一个应用会看到更频繁的收集。
在开始使用 .NET 时，我遇到的一件非常困难的事情是看着内存增长。伙计，这很可怕，因为我认为我有泄漏。但随着时间的推移，您会看到 GC 稳定下来，一切都在顺畅地运行。
如果您遇到 OOM 异常或其他不良行为，那就是您担心的时候了。否则，让 GC 做它的事。
编辑：zneak 发表了很好的评论——我可能误解了你的问题。
在 GC 上花费的时间也取决于很多因素，收集的是哪一代？ Gen0 的速度非常快。 Gen1 需要更长的时间，Gen2 需要更长的时间。凭借良好的内存利用率，我为每个 Gen2 寻找 10 个 Gen1 集合，为每个 Gen1 寻找 10 个 Gen0。在我们频繁使用的网站上的一天中，我可能会看到 10,000 个 Gen0、1000 个 Gen1 和 100 个 Gen2。 YMMV。
【讨论】：