CPU利用率错误

　　我们都用于 CPU 利用率的指标具有严重的误导性，并且每年都在恶化。什么是 CPU 利用率？您的处理器有多忙？不，这不是它衡量的。是的，我说的是每个人到处使用的＂%CPU＂指标。在每个性能监控产品中。在顶部（1）。
　　您可能认为 90% 的 CPU 利用率意味着：
　　它的真正含义：
　　停止表示处理器没有按照指令向前推进，通常是因为它正在等待内存 I/O。 我上面绘制的比率（在忙碌和停滞之间）是我在生产中通常看到的。很有可能，你大多停滞不前，但不知道。
　　这对你意味着什么？了解 CPU 的停滞程度可以在减少代码或减少内存 I/O 之间指导性能调整工作。 任何关注 CPU 性能的人，尤其是在基于 CPU 自动扩展的云上，都会从了解其 %CPU 的停滞组件中受益。什么是真正的 CPU 利用率？
　　我们称之为 CPU 利用率的指标实际上是＂非空闲时间＂：CPU 未运行空闲线程的时间。您的操作系统内核（无论它是什么）通常会在上下文切换期间跟踪这一点。如果非空闲线程开始运行，然后在 100 毫秒后停止，则内核认为 CPU 在整个时间都已利用。
　　这个指标与分时系统一样古老。阿波罗登月舱制导计算机（开创性的分时系统）将其空闲线程称为＂虚拟作业＂，工程师跟踪运行它的周期与实际任务作为重要的计算机利用率指标。（我之前写过这个。
　　那么这有什么问题呢？
　　如今，CPU已经变得比主内存快得多，并且等待内存主导了仍然称为＂CPU利用率＂的内容。当您在top（1）中看到高%CPU时，您可能会认为处理器是瓶颈 - 散热器和风扇下方的CPU封装 - 而实际上它是DRAM的那些组。
　　这种情况越来越糟。长期以来，处理器制造商扩展其时钟速度的速度比DRAM扩展其访问延迟（＂CPU DRAM差距＂）的速度更快。这种情况在2005年左右通过3 GHz处理器趋于平稳，从那时起，处理器已经使用更多的内核和超线程以及多插槽配置进行扩展，所有这些都对内存子系统提出了更高的要求。处理器制造商试图通过更大、更智能的 CPU 缓存以及更快的内存总线和互连来减少这种内存瓶颈。但我们通常仍然停滞不前。如何判断CPU到底在做什么
　　通过使用性能监视计数器 （PMC）：可以使用 Linux perf 和其他工具读取的硬件计数器。例如，测量整个系统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%)          stalled-cycles-frontend            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
　　这里的关键指标是每个周期的指令数（每个周期的指令数：IPC），它平均显示每个CPU时钟周期我们完成了多少条指令。越高越好（简化）。上面 0.78 的例子听起来还不错（78% 忙？），直到你意识到这个处理器的最高速度是 4.0 的 IPC。这也称为 4 宽，指的是指令获取/解码路径。这意味着，CPU可以在每个时钟周期内停用（完成）四条指令。因此，在 4 宽系统上的 IPC 为 0.78，意味着 CPU 以 19.5% 的最高速度运行。较新的英特尔处理器可能会移动到 5 宽。
　　还有数百个 PMC 可用于进一步挖掘：直接按不同类型的测量停滞周期。在云中
　　如果您处于虚拟环境中，则可能无法访问 PMC，具体取决于虚拟机管理程序是否支持来宾的 PMC。我最近发布了关于 EC2 的 PMC：测量 IPC 的文章，展示了 PMC 现在如何可用于基于 AWS EC2 Xen 的云上的专用主机类型。解释和可操作项目
　　如果您的 IPC < 1.0，则可能会内存停止，软件调整策略包括减少内存 I/O，以及改进 CPU 缓存和内存局部性，尤其是在 NUMA 系统上。硬件调整包括使用具有更大 CPU 缓存以及更快的内存、总线和互连的处理器。
　　如果您的 IPC > 1.0，则您可能受到指令限制。寻找减少代码执行的方法：消除不必要的工作、缓存操作等。 CPU 火焰图是进行此调查的绝佳工具。对于硬件调整，请尝试更快的时钟速率和更多的内核/超线程。
　　对于我的上述规则，我以 1.0 的 IPC 拆分。我从哪里得到的？我根据我之前与 PMC 的合作编造了它。下面介绍如何获取针对系统和运行时自定义的值：编写两个虚拟工作负载，一个受 CPU 限制，一个受内存限制。测量他们的IPC，然后计算他们的中点。性能监控产品应告诉您哪些信息
　　每个性能工具都应显示 IPC 和 %CPU。或者将 %CPU 分解为指令停用周期和停止周期，例如 %INS 和 %STL。
　　至于 top（1），Linux 有 tiptop（1），它按进程显示 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 CPU 利用率具有误导性的其他原因
　　不仅仅是内存停滞周期使 CPU 利用率具有误导性。其他因素包括：温度跳闸使处理器停止。涡轮增压改变时钟速率。内核随速度步长改变时钟速率。平均值的问题：80% 在 1 分钟内利用率，隐藏 100% 的爆发。旋转锁：CPU 已利用，并且具有高 IPC，但应用没有进行逻辑向前推进。更新：CPU 利用率实际上是错误的吗？
　　这篇文章有数百条评论，在这里（下面）和其他地方（1，2）。感谢大家抽出宝贵时间和对这个话题的兴趣。总结一下我的回答：我根本不是在谈论 iowait（那是磁盘 I/O），如果你知道自己是内存绑定的，还有一些可操作的项目（见上文）。
　　但是，CPU利用率实际上是错误的，还是只是具有深刻的误导性？我认为很多人将高%CPU解释为处理单元是瓶颈，这是错误的（正如我之前所说）。在这一点上，你还不知道，它通常是外部的东西。该指标在技术上是否正确？如果 CPU 停滞周期不能被其他任何东西使用，那么它们不是因此被＂利用等待＂（这听起来像是矛盾的）吗？在某些情况下，是的，您可以说 %CPU 作为操作系统级别的指标在技术上是正确的，但具有严重的误导性。但是，对于超线程，这些停止的周期现在可以由另一个线程使用，因此 %CPU 可能会将实际可用的周期计为已利用的周期。这是不对的。在这篇文章中，我想专注于解释问题和建议的解决方案，但是是的，这个指标也存在技术问题。
　　你可能会说，利用率作为一个指标已经被打破了，正如Adrian Cockcroft之前所讨论的那样。结论
　　CPU 利用率已成为一个极具误导性的指标：它包括主内存上等待的周期，这可能会主导现代工作负载。也许 %CPU 应该重命名为 %CYC，简称周期。您可以通过使用其他指标（包括每个周期的指令数 （IPC））来了解 %CPU 的真正含义。IPC < 1.0 可能意味着内存绑定，IPC > 1.0 可能意味着指令绑定。我在上一篇文章中介绍了IPC，包括对测量IPC所需的性能监控计数器（PMC）的介绍。
　　显示 %CPU 的性能监控产品（即全部）也应显示 PMC 指标来解释这意味着什么，而不是误导最终用户。例如，它们可以显示带 IPC 的 %CPU，和/或指令停用周期与停止周期。有了这些指标，开发人员和运营商可以选择如何更好地调整他们的应用程序和系统。