翻译蒋迪我们平时使用的CPU利用率方法是极具误导性的，并且一年更甚一年。我认为需要人将高CPU利用率视为处理单元的瓶颈的事儿，是错的。在超线程中，怠速周期可以被其他线程使用，所以%CPU的算法也会将其算在内，而实际上并没有利用。结论CPU利用率已成为一个极具误导性的指标：它算进了等待主存的周期，而这类周期在现代的CPU负载中占据不少。比如，它们可以一起显示%CPU和IPC，或者指令周期与怠速周期。
翻译 蒋迪
我们平时使用的CPU利用率方法是极具误导性的，并且一年更甚一年。那么什么是CPU利用率？是你的CPU到底有多忙，是像“% CPU”这样到处在用的指标所显示的那样吗？
在top命令里，你看到90%的CPU利用率是这样：
然而它真正想表达的是这个意思：
Stall(这里译作“怠速”)是说这个处理器没有在跑指令，比如在等待内存I/O的时候。我上图所画的比例（“忙”与“怠速”之间）是我在真实生产环境中遇到的，并且你的CPU也很可能是处于“怠速”状态。
这些对你有什么意义呢？理解CPU怠速多少，会直接影响到你在减少代码或者减少内存I/O的调优工作。
那么真正的CPU利用率怎么算呢？平时的CPU利用都是非空闲时间，即CPU不运行idle线程（比如Windows里的空闲进程）的时间。你的操作系统那会平时会在上下文切换的时候跟踪它，但是假如一个非idle线程开始运行100毫秒后停止，那内核会认为后面这段时间CPU也在这个非idle线程上。
使得这个%CPU指标错误的理由除了CPU在内存的怠速周期外，还有如下因素：
温度也能使CPU进入怠速；
Turboboost（睿频）引起时钟频率变化；
SpeedStep引起时钟频率变化；
一分钟内的80%的平均利用率并不能表示100%的突发利用率（类似网络QoS）；
自旋锁：CPU在很严肃地瞎忙；
自这篇文章发布以后，留言讨论非常激烈，已经有了上百条了。首先谢谢你们对这话题感兴趣并花时间阅读，但我在这里还是要统一回复：我对disk的iowait并不关心（译者注：PC CPU不能直接操作外部存储），并且文中也已经给出了内存操作密集型的对应调优措施。
然而，CPU利用率到底是从本质上错了还是仅仅是有误导性了？我认为需要人将高CPU利用率视为处理单元的瓶颈的事儿，是错的。那么这个指标的计算方法从技术上讲正确吗？如果CPU在怠速期间不能被其他任何进程使用，那么这不就是所谓的“使用等待”（听起来有点矛盾）。某些情况下，%CPU作为一个操作系统层面的指标是技术正确但是容易误导人的。在超线程中，怠速周期可以被其他线程使用，所以%CPU的算法也会将其算在内，而实际上并没有利用。那样是不对的，这篇文章中我强调的是解释问题并提出对策，并且，这个指标也有技术上的问题。
结论CPU利用率已成为一个极具误导性的指标：它算进了等待主存的周期，而这类周期在现代的CPU负载中占据不少。如果使用额外指标，你就能搞清楚%CPU到底意味着什么，包括每CPU周期执行指令数（IPC）。IPC < 1.0可能意味着你的应用是内存密集型，而IPC > 1.0则可能是指令密集型。我在之前的一篇文章，显示%CPU的性能监控产品也应该显示PMC测量指标，并给予充分解释，这样才不会误导用户。比如，它们可以一起显示%CPU和IPC，或者指令周期与怠速周期。有了这些指标，开发或管理人员才能在应用和操作系统中选择正确的调优方式。
译者的话本文翻译自Brendan Gregg的博客文章《CPU Utilization is Wrong》，原文链接为http://www.brendangregg.com/blog/2017-05-09/cpu-utilization-is-wrong.html，就是那本《性能之巅（中译）》的作者，调试工具dtrace的作者，现就职于NetFlix。
PS：为什么要翻译这个文章呢？因为很多时候总感觉PC的这个CPU利用率的百分比显示没能真实反应我的CPU到底忙不忙，在学校的时候用单片机也是算idle，但到了PC后隐约感觉这么算不对，看了BG的文章后才恍然大悟。另外这篇文章之前已经被翻译过，但作者又有更新，也挺有意思的，我就重新翻了一遍，并加了一些弹幕。
译者介绍：云技术社区专家 蒋迪蒋迪，资深虚拟化基础设施工程师，《KVM私有云架构设计与实践》作者，云技术社区专家，擅长KVM云平台架构解析与虚拟化POC，具有一线开发与交付经验。
云技术社区介绍：云技术社区成立于2014年，国内最大的云技术交流平台，分享在云计算/虚拟化项目实施中的资讯、经验和技术，坚持干货。
,
