.NET 垃圾收集器使用的 CPU 百分比是否是任何指标？

Question

作为应用程序运行缓慢的原因，有人报告说垃圾收集器在收集期间占用了 17% 的 CPU。对我来说，这个统计数据听起来无关紧要，因为 17% 无论如何也不用担心。此外，它是一个任意指标，无法告诉我有关进程内存构成的任何信息。

对我来说更相关的数据是：

1. 我们有多少 Gen 2 系列？

2. 给我看一下内存转储，让我和它一起玩，然后回到你身边。让我看看 heapstat（来自 psscorX 的!dumpheap -stat）、syncblocks 等。

3. 显示严重缓慢期间的 CPU 利用率，以便我知道这不是 I/O 绑定问题，它要求在设计中引入异步。

4. 自我们启动可疑操作以来，我们进行了多少次垃圾回收，其中有多少是完整回收？

5. 显示 LOH 堆碎片。

6. 显示非托管堆、进程中的可用空间以及托管堆占用的总空间。

7. 分析代码并查看需要花费的时间。然后将花费最多时间的操作归零。

但是垃圾收集运行所占用的 CPU 利用率？这对我来说似乎根本不是一个相关的指标。

所以，我要求确认。

1. 是 GC 使用的 CPU 指标，尤其是。当它只有 17% 时，是否是应用程序问题的相关指标？

2. 是否存在预期的 CPU 使用率阈值，GC 通常应在该阈值范围内才能被视为良好且健康的应用程序的正常集合？

我们谈论的是在工作站版本的 CLR 上运行的进程。

Answer 1

垃圾收集是内存分配的副产品。 如果垃圾收集占用了 17% 的 CPU 时间，则表明总体内存分配占用了更大的比例，例如 34%。 （当然，如果你的程序是 I/O 密集型的，那么 CPU% 就不太重要了。）

程序变慢的一种常见方式（或者用积极的话说，一种加快程序速度的常见方式）与可以避免的内存分配有关。 我使用random pausing 方法来确定这些机会。

This link 探讨了一个示例，其中池化和重用对象，而不是总是分配新对象，是最大的加速之一。 似乎总是需要说的是，程序通常有不止一种方法可以让程序运行得更快，因此性能调整可以分阶段进行。 因此，假设您现在在内存分配上花费了 100 秒中的 34 秒，并且假设您可以删除其中的 30 秒。然后时间缩短到 70 秒，加速为 100/70 = 1.43 倍。 现在几乎可以肯定还有其他事情（不一定是内存分配）需要 20 秒。它是 20/100 = 20%，但在解决第一个问题后，它更多；它是 20/70 = 29%。 通过第一次加速，它按比例变大。 修复它可以加快 70/50 = 1.4 倍。 如果您有多个问题并且一次解决一个问题，那么它们的加速因素会成倍增加，并且可能非常显着。

Answer 2

经过一番搜索，我找到了一些关于这个主题的信息here。

在收集期间检查 CPU 利用率似乎可以让人们了解是否发生了太多或太频繁的收集。这可能意味着对象被分配得太快和/或没有被释放，即存活时间太长（例如太多的类级别对象），因此垃圾收集器需要更长的时间，因为没有太多要收集的东西在每个集合中。

我从文章中复制了相关的sn-p：

Garbage Collection and Performance -> Issue: CPU Usage During a Garbage Collection Is Too High

垃圾回收期间 CPU 使用率会很高。如果一个显着 垃圾回收所花费的处理时间量， 收集过于频繁或收集持续时间过长。一个 托管堆上的对象分配率增加导致 垃圾收集更频繁地发生。减少分配 rate 减少垃圾收集的频率。

您可以使用 Allocated Bytes/second 来监控分配率 性能计数器。如需更多信息，请参阅Performance Counters in the .NET Framework。

然而，这并没有评论 17% 的 CPU 利用率是否很高，因为它不应该。它确实提供了一个建议，即我们研究每秒分配性能指标和% Time 计数器。