CPU 利用率的错误理解

翻译自：CPU 利用率错误 (brendangregg.com) by Brendan Gregg

1. CPU 利用率错误

我们都使用的CPU利用率指标具有很大的误导性，并且每年都在恶化。什么是CPU利用率？你的处理器有多忙？不，这不是它衡量的。是的，我说的是每个人都在使用的“%CPU”指标。在每个性能监控产品中都存在，例如top的第一行。

您可能认为90%的CPU利用率意味着：

它的真正含义：

停滞"stalled"意味着处理器没有在指令上取得进展，通常是因为它正在等待内存输入/输出。我在上面画的比率（繁忙和停滞之间）是我在生产中通常看到的。很有可能，你大部分都停滞了，但不知道。

这对您意味着什么？了解CPU stalled 的程度可以在减少代码或减少内存I/O之间指导性能调整工作。任何关注CPU性能的人，尤其是在基于CPU自动扩展的云上，都将受益于了解其%CPU的stalled组件。

2.什么是CPU利用率？

我们称之为CPU利用率的指标实际上是“非空闲时间”：CPU没有运行空闲线程的时间。

您的操作系统内核（无论是什么）通常会在上下文切换期间跟踪这一点。如果一个非空闲线程开始运行，然后在100毫秒后停止，内核会认为CPU在整个时间内都在使用。

这个指标和分时系统一样古老。Apollo登月舱制导计算机（一个开创性的分时系统）将其空闲线程称为“DUMMY JOB”，工程师跟踪运行它的周期与实际任务，作为一个重要的计算机利用率指标。

那么这有什么问题呢？

如今，CPU已经变得比内存（ main memory）快得多，等待内存仍然主导着所谓的“CPU利用率”。

当你看到top首行中的高CPU时，你可能会认为处理器是瓶颈，而实际上是DRAM的逻辑Bank(when it's really those banks of DRAM)。

这种情况一直在恶化。长期以来，处理器制造商扩展时钟速度的速度比DRAM扩展访问延迟的速度要快（“CPU DRAM差距”）。这种情况在2005年左右随着3 GHz处理器而趋于平稳，从那以后，处理器扩展使用了更多的内核和超线程，加上多插槽配置，所有这些都对内存子系统提出了更多的需求。处理器制造商试图通过更大、更智能的CPU缓存以及更快的内存总线和互连来减少这种内存瓶颈。但我们通常仍然停滞不前。

3.如何判断CPU真正在做什么

通过使用性能监控计数器（PMC）：可以使用Linux perf和其他工具读取的硬件计数器。例如，测量整个系统10秒：

perf stat -a -- sleep 10

# perf stat -a -- sleep 10

 Performance counter stats for 'system wide':

     641398.723351      task-clock (msec)         #   64.116 CPUs utilized            (100.00%)
           379,651      context-switches          #    0.592 K/sec                    (100.00%)
            51,546      cpu-migrations            #    0.080 K/sec                    (100.00%)
        13,423,039      page-faults               #    0.021 M/sec                  
 1,433,972,173,374      cycles                    #    2.236 GHz                      (75.02%)
   <not supported>      stalled-cycles-frontend  
   <not supported>      stalled-cycles-backend   
 1,118,336,816,068      instructions              #    0.78  insns per cycle          (75.01%)
   249,644,142,804      branches                  #  389.218 M/sec                    (75.01%)
     7,791,449,769      branch-misses             #    3.12% of all branches          (75.01%)

      10.003794539 seconds time elapsed

这里的关键指标是每个周期的指令数（insns per cycle: IPC），它显示了平均每个CPU时钟周期我们完成了多少条指令。越高越好。上面0.78的例子听起来不错（78% 繁忙？）直到你意识到这个处理器的最高速度是4.0的IPC。这也被称为4-wide(可以在一个时钟周期内"射"出四个"内部指令"到执行机构)，指的是指令获取/解码路径。这意味着，CPU可以在每个时钟周期停用（完成）四条指令。因此，在4-wide系统上0.78的IPC意味着CPU以其最高速度的19.5%运行。较新的Intel处理器可能会转向5宽。

还有数百个PMC可用于进一步挖掘：通过不同类型直接测量停滞循环。

在云服务器中：
如果您在虚拟环境中，您可能无法访问PMC，这取决于虚拟机管理程序是否支持你使用它们。我最近发布了关于EC2的PMC：测量IPC，展示了PMC现在如何可用于基于AWS EC2 Xen的云上的专用主机类型。

4.解释和可操作的项目

如果您的IPC<1.0，您可能会出现内存停滞(memory stalled)，软件调整策略包括减少内存I/O，改善CPU缓存和内存局部性(memory locality)，尤其是在NUMA系统上。硬件调整包括使用具有更大CPU缓存和更快内存、总线和互连的处理器。

如果您的IPC是>1.0，您可能是指令绑定。寻找减少代码执行的方法：消除不必要的工作、缓存操作等。CPU火焰图是此调查的绝佳工具。对于硬件调整，尝试更快的时钟速率和更多的内核/超线程。

对于我的上述规则，我在IPC为1.0的情况下进行了拆分。我从哪里得到的？我根据我之前的工作编造了它。以下是如何获得为您的系统和运行时自定义的值：编写两个虚拟工作负载，一个受CPU限制，一个受内存限制。测量他们的IPC，然后计算他们的中点。

5.哪些性能监控产品应该告诉你

每个性能工具都应该显示IPC和%CPU。或者将%CPU分解为指令停用周期与停顿周期，例如%INS和%STL。

至于top命令，还有用于Linux的tiptop，它按进程显示IPC：

tiptop -                  [root]
Tasks:  96 total,   3 displayed                               screen  0: default

  PID [ %CPU] %SYS    P   Mcycle   Minstr   IPC  %MISS  %BMIS  %BUS COMMAND
 3897   35.3  28.5    4   274.06   178.23  0.65   0.06   0.00   0.0 java
 1319+   5.5   2.6    6    87.32   125.55  1.44   0.34   0.26   0.0 nm-applet
  900    0.9   0.0    6    25.91    55.55  2.14   0.12   0.21   0.0 dbus-daemo

6.CPU利用率具有误导性的其他原因

不仅仅是内存停滞周期使 CPU 利用率具有误导性。其他因素包括：

• • 温度过载使处理器停止。
  • 涡轮增压改变时钟速率。
  • 内核随速度步长改变时钟速率。
  • 平均值的问题：80% 在 1 分钟内利用率，隐藏 100% 的爆发。
  • 旋转锁：CPU 已利用，并且具有高 IPC，但应用没有进行逻辑向前推进。

7.CPU利用率真的是错误的吗？

这篇文章有数百条评论，在这里（下面）和其他地方（1，2）。感谢大家抽出宝贵时间和对这个话题的兴趣。总结一下我的回答：我根本不是在谈论 iowait（那是磁盘 I/O），如果你知道自己是内存绑定的，还有一些可操作的项目

但是CPU利用率实际上是错误的，还是只是严重误导？我认为许多人将高%CPU解释为处理单元是瓶颈，这是错误的（正如我之前所说）。在这一点上，你还不知道，它通常是外部的东西。指标在技术上是正确的吗？如果CPU stalled周期不能被其他任何东西使用，那么它们不是因此被“利用等待”（这听起来像是矛盾的）吗？在某些情况下，是的，你可以说%CPU作为操作系统级别的指标在技术上是正确的，但具有很大的误导性。然而，对于超线程，这些stalled周期现在可以被另一个线程使用，因此%CPU可能会将实际可用的周期计为已使用周期。那是错误的。在这篇文章中，我想关注解释问题和建议的解决方案，但是是的，这个指标也有技术问题。

正如Adrian Cockcroft之前讨论的那样，你可能只是说利用率作为一个指标已经被打破了。

8.结论

CPU利用率已经成为一个非常误导人的指标：

它包括等待主内存的周期，这可能会主导现代工作负载。也许%CPU应该重命名为%CYC，周期的缩写。

您可以通过使用其他指标（包括每个周期的指令（IPC））来弄清楚%CPU的真正含义。IPC<1.0可能意味着内存限制，IPC>1.0可能意味着指令限制。我在上一篇文章中介绍了IPC，包括对测量它所需的性能监控计数器（PMC）的介绍。

显示 %CPU 的性能监控产品（即全部）也应显示 PMC 指标来解释这意味着什么，而不是误导最终用户。例如，它们可以显示带 IPC 的 %CPU，和/或指令停用周期与停止周期。有了这些指标，开发人员和运营商可以选择如何更好地调整他们的应用程序和系统。