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

Question

作为应用程序缓慢的解释，有人报告说垃圾收集器在收集过程中占用了17％的CPU。对我而言，这个统计数据听起来毫不相关，因为17％不会太担心。此外，这是一个任意的度量标准，并没有告诉我有关进程内存构成的任何信息。

什么会比较相关数据，我会喜欢的东西：

1. 多少Gen 2件的藏品没有我们？

2. 让我看看内存转储，让我和它一起聚会回来给你。让我看看heapstat（!dumpheap -stat从psscorX），同步块等

3. 告诉我在缓慢的重周期的CPU使用率，所以我知道它不是一个I/O限制的问题，这是在哀求引入异步的成设计。

4. 我们没有多少垃圾收集有因为我们推出嫌疑人的操作和有多少人是完全收集？

5. 让我看看LOH堆碎片。

6. 告诉我非托管堆中，在这个过程中的自由空间，并通过托管堆占据的总空间。

7. 剖析代码并查看需要花费的时间。然后再进行花费最多时间的操作。

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

所以，我要求确认。

1. 是GC使用的CPU的度量标准，当它只有17％时，这是一个相关的应用问题指标？

2. 是否有预期的阈值的CPU利用率的GC通常应在以被认为是一个很好的和健康的应用程序的正常收集合适？

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

Answer 1

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

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

This link探索一个例子，其中汇集和重用对象，而不是总是分配新的对象，是一个大型的加速。 总而言之，需要说的是，程序通常会有一个以上的方式来加快速度，因此性能调整可以分阶段进行。 因此，假设你现在在内存分配上花费了100分之三十四的时间，假设你可以删除其中的30个。然后时间缩短到70秒，加速100/70 = 1.43x。 现在几乎可以肯定有其他东西（不一定是内存分配）需要20秒。这是20/100 = 20％，但在解决第一个问题之后更是如此;它是20/70 = 29％。 第一次加速比例变大了。 修复它提供了70/50 = 1.4x的加速。 如果您遇到多个问题并且一次只修复一个问题，那么它们的加速因子会一起增加，并且可能会非常显着。

Answer 2

经过一番搜索，我发现这个话题here一些信息。

看来，一个收集过程中检查CPU使用率可能会给一个一些洞察到太多或太频繁了一些藏品是否正在发生。这可能意味着对象分配速度过快和/或没有被释放，即活动时间过长（例如太多的课堂级对象），因此它将垃圾收集器的时间延长，因为没有太多收集在每个集合中。

我复制的相关片段从文章：

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

CPU使用率将是一个垃圾收集过程中的高。如果在垃圾收集中花费了大量的处理时间，则收集的数量过于频繁或收集持续时间过长。 增加分配给托管堆上的对象的分配率导致 垃圾回收发生得更频繁。减少分配率可以减少垃圾收集的频率。

您可以使用分配字节数/秒 性能计数器来监视分配率。有关更多信息，请参阅Performance Counters in the .NET Framework。

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