文章指出，CPU利用率指标并不准确，无法线性反映系统性能。作者通过压力测试发现，系统报告的CPU利用率与实际工作负载不成正比，表明仅依赖CPU利用率来判断服务器性能存在误导性。

标题：CPU利用率是个谎言

在工作中，我经常处理大量服务器，而每个人都想知道他们的服务器是否接近满负荷运行。这似乎很简单，只需打开top或其他系统监控工具，查看网络、内存和CPU的利用率，哪个数值最高就说明你离极限有多近。

例如，一台机器的CPU利用率为50%，理论上它还能再做一倍的工作。然而，当人们实际尝试根据这些数字进行预测时，发现CPU利用率并不完全呈线性增长。但问题到底有多严重？

为了回答这个问题，我进行了一系列压力测试，监控了它们完成的工作量和系统报告的CPU利用率，并将结果绘制成图表。

测试设置： 我使用了一台运行Ubuntu的台式机，搭载了Ryzen 9 5900X（12核/24线程）处理器，并启用了Precision Boost Overdrive（即Turbo模式）。我编写了一个脚本，循环运行stress-ng，首先使用24个工作者，尝试让每个工作者的利用率从1%到100%不等，然后使用1到24个工作者，全部以100%的利用率运行。测试使用了不同的压力测试方法，并测量了可以完成的操作数量（“Bogo ops”）。

测试结果： 在基本的CPU测试中，当系统报告CPU利用率为50%时，实际上完成了60-65%的最大工作量。在64位整数运算测试中，情况更糟，报告为“50%利用率”时，实际完成了65-85%的最大工作量。而在矩阵运算测试中，报告为“50%利用率”时，实际完成了80%到100%的最大工作量。

原因分析： 这种现象的主要原因是超线程技术：这台机器（以及大多数机器）的一半“核心”与其他核心共享资源。如果在这台机器上运行12个工作者，它们会被调度到各自的物理核心上，没有资源竞争；但一旦超过12个，每个额外的工作者都会与其他工作者共享资源。在某些情况下（如通用CPU基准测试），这会使性能略有下降；而在其他情况下（如依赖SIMD的矩阵运算），则没有可用的资源可以共享。

此外，Turbo模式也在产生影响。该处理器在低利用率时以4.9 GHz运行，但随着更多核心的激活，频率逐渐降至4.3 GHz。由于CPU利用率是根据繁忙周期/总周期计算的，分母随着分子的增加而减小，这进一步解释了为什么实际CPU利用率增长速度快于线性。

这重要吗？ 如果你假设CPU利用率会线性增长，那么你可能会遇到麻烦。如果你高效地使用CPU（运行在“50%”利用率以上），报告的利用率会被低估，有时甚至严重低估。需要注意的是，我只展示了一款处理器的结果，而不同处理器（尤其是AMD和Intel）的超线程性能和Turbo行为可能会有很大差异。

解决方案： 最好的方法是运行基准测试并监控实际完成的工作量： 1. 基准测试服务器在出现错误或不可接受的延迟之前可以完成多少工作。 2. 报告服务器当前完成的工作量。 3. 比较这两个指标，而不是依赖CPU利用率。

总之，CPU利用率并不是一个可靠的指标，尤其是在高负载情况下，它可能会严重低估系统的实际工作能力。

主要观点总结：

1. 超线程技术的实际效果与误解

   • 超线程技术（Hyperthreading）在实际应用中并不总是带来性能提升，有时甚至需要关闭以优化性能。
   • 引用：
     • "How many times has hyperthreading been an actual performance benefit in processors?" (hinkley)
     • "you can't count the hyperthreads as double the performance, typically they are actually in practice only going to bring 15-30%" (PaulKeeble)

2. CPU利用率的复杂性与误解

   • CPU利用率虽然是一个明确的指标，但人们常常错误地将其与系统容量模型直接关联，忽略了非线性因素如内存带宽、缓存争用等。
   • 引用：
     • "Utilization is not a lie, it is a measurement of a well-defined quantity, but people make assumptions to extrapolate capacity models from it" (ot)
     • "Anytime CPU% goes over 50-60% suddenly it'll spike to 100% rather quickly" (N_Lens)

3. 基准测试工具的局限性

   • 使用如stress-ng等工具进行基准测试可能无法反映真实生产环境中的性能表现，建议使用实际应用如Memcached或Postgres进行测试。
   • 引用：
     • "Uses stress-ng for benchmarking, even though the stress-ng documentation says it is not suitable for benchmarking" (CCs)
     • "Yeah and those tests don't even trigger some memory or cache contention" (gbin)

4. 系统性能的非线性与突发行为

   • 系统性能在接近饱和时会出现非线性变化，突发行为在短时间内可能对性能产生重大影响，而长时间的平均值无法捕捉这些细节。
   • 引用：
     • "the derivatives close to saturation explode, so any nondeterministic noise is extremely amplified" (ot)
     • "Stress-ng is nicely linear until 100%, memcached will have a hockey stick curve at the end" (CCs)

5. 管理层的误解与沟通挑战

   • 技术团队与管理层之间在系统性能理解上存在鸿沟，技术解释常常被误解或忽视。
   • 引用：
     • "I once tried to explain to a manager that a server at 60% utilization had zero room left, and they looked at me like I had two heads" (judge123)
     • "Tried to explain this in a job interview 5 years ago. They thought I was a bullshitter" (kristopolous)

总结：

评论主要围绕超线程技术的实际效果、CPU利用率的复杂性、基准测试工具的局限性、系统性能的非线性行为以及技术沟通的挑战展开。尽管超线程技术在某些情况下能带来性能提升，但其效果有限且可能增加延迟。CPU利用率虽然是一个明确的指标，但其与系统容量的关系复杂，受多种因素影响。基准测试工具如stress-ng可能无法准确反映真实生产环境中的性能表现，建议使用实际应用进行测试。此外，技术团队与管理层之间的沟通障碍也常常导致误解。