海门市城乡建设局网站,深圳专业做网站专业,小红书推广价目表,深圳网站开发外包哪家好来源#xff1a;内核月谈, 原文链接#xff1a;http://www.brendangregg.com/blog/2017-05-09/cpu-utilization-is-wrong.html本文中若有任何疏漏错误#xff0c;责任在于编译者。有任何建议和意见#xff0c;请回复内核月谈微信公众号#xff0c;或通过 caspar at linux.… 来源内核月谈, 原文链接http://www.brendangregg.com/blog/2017-05-09/cpu-utilization-is-wrong.html本文中若有任何疏漏错误责任在于编译者。有任何建议和意见请回复内核月谈微信公众号或通过 caspar at linux.alibaba.com 反馈。导读本文翻译自 Brendan Gregg 去年的一篇博客文章 “CPU Utilization is Wrong”从标题就能想到这篇文章将会引起争议。文章一上来就说我们“人人皆用、处处使用每个性能监控工具里都在用”的 top 命令里的 “%CPU” 指标是不对的其并非用于衡量 CPU 的繁忙程度的正确指标作者谴责了一下众人(或许也包括你我)的这一行为是具有很大的误导性(deeply misleading)的而且这种情况还在连年恶化。对于这么大一顶帽子让我们暂且按下躁动的心听听作者是怎么深入阐释他的观点的。1. 引言可能你认为的 90% CPU 利用率意味着这样的情形而实际却可能是这样的CPU 并非 90% 的时间都在忙着很大一部分时间在等待或者说“停顿(Stalled)”了。这种情况表示处理器流水线停顿一般由资源竞争、数据依赖等原因造成。多数情况下表现为等待访存操作其中又以读操作为主。在停顿周期内不能执行指令这意味着你的程序不往前走。值得注意的是图中 “Stalled” 状态所占的比例是作者依据生产环境中的典型场景计算而来具有普遍现实意义。因此大多时候 CPU 处于停顿状态而你却不知道因为 CPU 利用率这个指标没有告诉你真相。通过进一步分析 CPU 停顿的原因可以指导代码优化提高执行效率这是我们深入理解CPU微架构的动力之一。2. CPU 利用率的真实含义是什么我们通常所说的CPU利用率是指 “non-idle time”即CPU不执行 idle thread 的时间。操作系统内核会在上下文切换时记录CPU的运行时间。假设一个 non-idle thread 开始运行100ms 后结束内核会认为这段时间内 CPU 利用率为 100%。这种度量方式源于分时复用系统。早在阿波罗登月舱的导航计算机中idle thread 当时被叫做 “DUMMY JOB”工程师通过比对运行 “DUMMY JOB” 和 “实际任务” 的时间来衡量导航系统的利用率。那么这个所谓“利用率”的问题在哪儿呢当今时代CPU 执行速度远远大于内存访问速度等待内存的时间成为占用 CPU 时间的主要部分。当你在 top 中看到很高的 “%CPU”你可能认为处理器是瓶颈但实际上却是内存。在过去很长一段时间内CPU 频率增长的速度大于 DRAM 访存延时降低的速度CPU DRAM gap直到2005年前后处理器厂商们才开始放弃“频率路线”转向多核、超线程技术再加上多处理器架构这些都导致访存需求急剧上升。尽管厂商通过增大 cache 容量、优化 cache 策略、提升总线带宽来试图缓解访存瓶颈但我们的程序仍深受 CPU stall 困扰。3. 如何真正辨别 CPU 在做些什么在 PMC(Performance Monitoring Counters) 的帮助下我们能看到更多的 CPU 运行状态信息。下图中perf 采集了10秒内全部 CPU 的运行状态。这里我们重点关注的核心度量指标是 IPC(instructions per cycle)它表示平均每个 CPU cycle 执行的指令数量很显然该数值越大性能越好。上图中 IPC 为 0.78看起来还不错是不是 78% busy 呢现代处理器一般有多条流水线运行 perf 的那台机器IPC 的理论值可达到 4.0。如果我们从 IPC的角度来看这台机器只运行到其处理器最高速度的 19.5%0.78 / 4.0)。幸运的是在处理器内部有很多 PMU event可用来帮助我们分析造成 CPU stall 的原因。用好 PMU 需要我们熟悉处理器微架构可以参考 Intel SDM。4. 最佳实践是什么如果 IPC 1.0, 很可能是 Memory stall 占主导可从软件和硬件两个方面考虑这个问题。软件方面减少不必要的访存操作提升 cache 命中率尽量访问本地节点内存硬件方面增加 cache 容量加快访存速度提升总线带宽。如果IPC 1.0, 很可能是计算密集型的程序。可以试图减少执行指令的数量消除不必要的工作。火焰图CPU flame graphs非常适用于分析这类问题。硬件方面尝试超频、使用更多的 core 或 hyperthread。作者根据PMU相关的工作经验设定了1.0这个阈值用于区分访存密集型(memory-bound)和计算密集型(cpu-bound)程序。读者可以根据自己的实际工作平台合理调整这个阈值。5. 性能工具应该告诉我们什么作者认为性能工具中使用 %CPU 时都应该附带上 IPC或者将 %CPU 拆分为指令执行消耗 cycle(%INS) 和 stalled 的 cycle(%STL)。对应到 top在 Linux 系统有一个能够显示每个处理器 IPC 的工具 tiptop:6. 其他可能让 CPU 利用率引起误解的因素除了访存导致的 stall 容易让人误解 CPU 利用率外还有其他一些因素温度原因导致处理器 stallTurboboost 干扰了时钟速率内核使得时钟速率加快平均带来的问题1分钟利用率平均 80%掩盖了中间 100% 部分自旋锁: CPU 一直在被使用同时 IPC 也很高但是应用逻辑上并没有任何进展。7. 更新CPU 利用率真的错了吗?这篇文章引起了大量留言http://www.brendangregg.com/blog/2017-05-09/cpu-utilization-is-wrong.html 的留言栏;https://news.ycombinator.com/item?id14301739https://www.reddit.com/r/programming/comments/6a6v8g/cpu_utilization_is_wrong/总结下作者的回答是这里讨论的并不是 iowait (那是磁盘IO)而且如果你已经确认是访存密集型是有些处理办法参考上面。那么 CPU 利用率指标是确确实实错误的还是只是容易误导如作者前面所说他认为许多人把高 CPU 利用率理解为瓶颈在 CPU 上这一行为才是错误的其实单看 CPU 利用率并不清楚瓶颈在何处很多时候瓶颈是在外部。这个指标技术上看是否正确如果 CPU stall 的周期并不能被其他地方使用它们是不是也就因此是“忙于等待“听起来有点矛盾在有些情况确实如此你可以说 CPU 利用率作为操作系统级别的指标技术上看是对的但是容易产生误导。从另一个角度来说有超线程的情况下那些 stalled 的周期是可以被其他线程使用的这时 “%CPU” 可能会将可用的周期统计为正在使用这种情况是错误的。这篇文章作者想关注的是解释清楚这个问题并给出解决方法建议但没错CPU 利用率这个指标本身也是存在一些问题的。当你可能会说利用率作为一个指标已经不对Andrian Cockcroft之前讨论已经指出过 (http://www.hpts.ws/papers/2007/Cockcroft_HPTS-Useless.pdf )。8. 结论CPU 利用率已经开始成为一个容易误导的指标它包含访存导致的等待周期这样会影响一些新应用。也许 “%CPU” 应该重命名为 “%CYC”cycles的缩写。要清楚知道 “%CPU” 的含义需要使用其他指标进行辅助其中就包括每周期指令数(IPC)。IPC 1.0 多半意味着访存密集型IPC 1.0 多半意味着计算密集型。作者之前的文章中涵盖有 IPC 说明以及用于测量 IPC 的 Performance Monitoring CountersPMCs的介绍。所有的性能监控产品如果展示 “%CPU”都应该同时展示 PMC 指标用于解释其真实意义不要误导用户。比如可以把 “%CPU” 和 “IPC” 一起放或者说指令执行消耗周期和 stalled 周期。有这些指标之后开发者和操作者就能够知道该如何更好地对应用和系统进行调优。
