java - oracle java官方文档中处理器吞吐量的数字是多少

Question

“Java 平台，标准版 HotSpot 虚拟机垃圾收集调整指南”，解释 its figure 1-1像下面这样

The red line is an application spending only 1% of the time in garbage collection on a uniprocessor system. This translates to more than a 20% loss in throughput on systems with 32 processors.

我不明白这些数字的真正含义。
这是否意味着，在gc时间固定的情况下，GC会因为暂停而影响CPU的吞吐量？

Answer 1

以下是您在其中找到此图表的文档中的说明文本:

The graph in Figure 1-1 models an ideal system that's perfectly scalable with the exception of garbage collection. The red line is an application spending only 1% of the time in garbage collection on a uniprocessor system. This translates to more than a 20% loss in throughput on systems with 32 processors. The magenta line shows that for an application at 10% of the time in garbage collection (not considered an outrageous amount of time in garbage collection in uniprocessor applications), more than 75% of throughput is lost when scaling up to 32 processors.

图表下方的链接显示:

The graph models an ideal system that's perfectly scalable with the exception of garbage collection (GC). It plots the number of processors (x-axis) against throughput (y-axis). It contains six plotted lines labeled 1% GC, 2% GC, 3% GC, 10% GC, 20% GC, and 30% GC. Each line represents the changing throughput for an application that spends the specified percentage of time used for garbage collection on a uniprocessor system versus on a multiprocessor system. The graph is described in the text that precedes it.

<小时/>

所以...

1. 这是一个模型，而不是实际测量性能的图表。
2. 该模型是理想化的。它假设应用程序是完全可扩展的(除了 GC)。
3. 它说明了当您不使垃圾收集可扩展时会发生什么；例如如果只有一个 GC 线程并且它不与应用程序线程并行操作。
4. 1% GC、2% GC 等线代表单处理器系统上不同模型的 GC 负载。因此，1% 线代表在单处理器系统上运行的应用程序的情况，其中应用程序线程生成可以使用 1% 的可用 CPU 来收集的 GC 负载。
5. 吞吐量代表繁忙应用程序正在完成的有用(应用程序)工作；即*未用于垃圾收集或等待 GC 完成的时间(GC 开销)。
6. 吞吐量以具有给定处理器数量的系统上可用 CPU 时间的百分比来衡量。

因此，例如，在 30% GC 级别下，32 核系统的吞吐量将大约是硬件理论吞吐量的 1/10。它将浪费大约 9/10 的可用 CPU 时间来等待垃圾收集完成!