震惊,用了这么多年的 CPU 利用率,其实是错的
来源:内核月谈, 原文链接:
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 利用率外,还有其他一些因素:
温度原因导致处理器 stall;
Turboboost 干扰了时钟速率;
内核使得时钟速率加快;
平均带来的问题: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?id=14301739
https://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 Counters(PMCs)的介绍。
所有的性能监控产品如果展示 “%CPU”,都应该同时展示 PMC 指标用于解释其真实意义,不要误导用户。比如,可以把 “%CPU” 和 “IPC” 一起放,或者说指令执行消耗周期和 stalled 周期。有这些指标之后,开发者和操作者就能够知道该如何更好地对应用和系统进行调优。
震惊,用了这么多年的 CPU 利用率,其实是错的相关推荐
- linux查看CPU利用率与负载,Linux CPU负载利用率统计
通常,有如下方式可以得到 cpu 利用率情况: top 命令 e.g. top -m 20 -d 1 -t User 0%, System 6%, IOW 0%, IRQ 0% User 1 + Ni ...
- linux cpu平均利用率st,理解 CPU 利用率
从 top 命令说起 在 Linux shell 上执行 top 命令,可以看到这样一行 CPU 利用率的数据: %Cpu(s): 0.1 us, 0.0 sy, 0.0 ni, 99.9 id, 0 ...
- rabbitmq beam.smp cpu利用率过高
RabbitMQ是实现了高级消息队列协议(AMQP)的开源消息代理软件(亦称面向消息的中间件).RabbitMQ服务器是用Erlang语言编写的,而集群和故障转移是构建在开放电信平台框架上的.所有主要 ...
- freeRtos学习笔记 (9) 移植和CPU利用率统计
freeRtos学习笔记 (9) 移植和CPU利用率统计 使用官方固件移植 首先准备一个能跑的裸机工程 注意,freertos需要使用systick定时器,而stm32HAL库默认使用systick作 ...
- 限定虚拟机可用的CPU利用率
Windows Server 2012姗姗来迟,最新的Hyper-V 3给我们带来更多的惊喜,后续三篇博文和大家龚广通学习虚拟机CPU竞争机制. 第一部分:分配给虚拟机的CPU资源 第二部分:限定虚拟 ...
- 2.2.3 操作系统之调度算法的评价指标(cpu利用率、系统吞吐量、周转时间、等待时间、响应时间)
文章目录 0.思维导图 1.CPU利用率 2.系统吞吐量 3.周转时间 4.等待时间 5.响应时间 0.思维导图 1.CPU利用率 2.系统吞吐量 3.周转时间 4.等待时间 5.响应时间
- Linux——top命令查看cpu利用率超过100%
top命令显示的是程序占用的cpu占用率总和,也就是说如果4核cpu那么cpu最高占用率可达400%,top里显示的是把所有使用率加起来. 运行top后按大键盘1,可以显示每个cpu的使用率 查看一下 ...
- 腾讯成本优化黑科技:整机CPU利用率最高提升至90%
腾讯TLinux团队提出了一套全新的混部方案,在不影响在线业务的前提下,对整机CPU利用率提升效果非常明显,在有的业务场景下,整机CPU利用率甚至能提升至90%. 一.前言 腾讯运营着海量的服务器 ...
- 服务器性能指标(二)——CPU利用率分析及问题排查
转载自 服务器性能指标(二)--CPU利用率分析及问题排查 平常的工作中,在衡量服务器的性能时,经常会涉及到几个指标,load.cpu.mem.qps.rt等.每个指标都有其独特的意义,很多时候在线 ...
最新文章
- nvidia 程序安装失败
- Spring AOP之异常转换
- 使用QueueUserAPC线程注入,
- [LeetCode] Max Points on a Line 题解
- springsession使用redis
- android espresso跨程序,Android Espresso:依次运行多个测试
- 仿豆丁百度文库网页版阅读器完整解决方案
- java基础案例教程前4章知识点_java学习记录4 Java基础知识点
- day32 java的多线程(2)
- linux查看磁盘io性能
- RDD、DataFrame和DataSet的区别
- php ajax可编辑表格,jquerAjax+php实现表格的增删改查(带数据库)
- 基于PC-DIMS脱机软件 的海克斯康三坐标机脱机编程软件手册。
- 原生开发什么意思_原生APP是什么?选原生开发有哪些优势?
- 汽车发展史大事件(1766-2017)
- IPhoneX全屏适配
- maya api 初接触
- 两台同一局域网下的电脑实现共享文件夹
- 思科 计算机网络 第十章测试考试答案
- 菲尔人格测试(测试一下自己的分数看看)
热门文章
- 怎么用源程序把ChemDraw结构复制到Word文档
- 通过VB向SQL Server数据库中录入数据
- PowerDesigner 把Comment写到name中 和把name写到Comment中 pd7以后版本可用
- 多域资源整合之基础准备--DNS配置
- OCP Java 自测
- 真格量化——50期权历史波动率策略
- 网络爬虫--2.HTTP和HTTPS
- xenserver 安装新硬盘_给Xenserver添加新硬盘
- 路由到另外一个页面_Nextjs使用解读一(项目搭建与路由系统)
- excel合并两列内容_还在为合并WPS表格(Excel)中两列内容而犯愁?此方法简单高效...