原文是性能优化大神Brendan Gregg的一篇17年的博客”CPU Utilization is Wrong”[1]，写的很有参考价值，我翻译一下。Youtube上也有与之对应的一个presentation： 我们大家用的“CPU占用率”这个指标存在很大的误导性，而且这种误导近年来越来越严重。什么是CPU占用率，它是指你的处理器到底多忙吗？不，那并不是它所能反映出的。是的，我正要讨论%CPU这个大家都处都在用的性能指标(包括每一种的性能检测软件，包括top工具)。 你以为90%的CPU占用率是这样时， 其实它有可能是这样的： Stalled指的是处理器不能继续执行指令，这基本是由于CPU在等待内存IO。上边我所画的busy和stalled的比例正是我在真实的生产环境所见的。所以，很有可能你在内存stall时，并没有察觉到。 对我们来说这意味这什么？明白了我们的CPU有多少被stall可以让我们直接将性能优化的努力放到减少不必要的代码和内存IO。能搞清楚CPU占用率中有多少比例的stall成分，任何关注CPU性能的人(尤其当程序运行在是根据CPU来自动扩展的云环境中时)都能获得好处。 到底什么是CPU占用率 CPU占用率这个指标其实就是“非空闲时间”，即CPU没有在跑idle线程。OS内核经常会在上下文切换时进行追踪操作，如果非空闲线程开始跑并在100毫秒后停下来，那么内核认为CPU被全部占用。 这个指标和分时系统一样古老。阿波罗登月舱的指挥计算机(分时系统的先驱)把它的idle线程称为”哑任务(dummy job)”，工程师们通过追踪运行哑任务和其他运行真实任务的cycles来得到这一重要的计算机占用率指标。(就像我以前所写一样。) 那么问题出在哪呢？ 当今，CPU比主存更快，因此“等待内存”成为了“CPU占用率”的主要部分。当你在top工具中看到高的%CPU时，你可能会认为处理器(在散热器和风扇下的CPU封装)是瓶颈，不过其实都是那些DRAM内存的问题。 这种情况越来越糟，一直以来，处理器时钟的增速都要大于DRAM访问延迟的增速(“CPU-DRAM鸿沟”，译注：也叫“内存墙”)。这种局面持续到2005年的3 GHz处理器，从那以后，处理器往多核、超线程、多socket发展，这些都提升了对内存子系统的需求。处理器厂商尝试用更智能的CPU cache、更快的内存总线和互联网络来解决这些问题。但是我们仍然经常面临stall问题。 怎么知道CPU正在干什么 通过使用性能监测计数器(Performance Monitoring Counter, 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 […]