评价CPU负载用average LOAD一定没问题吗??
原创
白鳝
白鳝的洞穴
白鳝的洞穴
老白个人交流平台,系统优化、Oracle和架构及驴行天下
2021年02月19日 00:11
昨天刚刚讲过“运维人员应该多学习一些理论知识”,实际上很多理论知识的学习并不是看几本书或者上几堂课就可以解决的。很多知识必须是深入研究后才能获得真知的。一些似是而非的知识可能会影响我们对真知的理解。
早期大家都是通过cpu usage%来评价CPU负载的,随着CPU技术的发展,我们发现有时候cpu usage% 达到100%也不一定说明CPU存在瓶颈了。这些年来,做运维的人更多的会使用load来评估CPU的负载。从Oracle 11g开始,AWR报告也提供了关于CPU load的信息。
我们可以很方便的使用uptime命令来获得Load average的数据。
以前我也是用AWR中的LOAD来初步判断服务器的负载的。不过有一次一个朋友让我看一份AWR报告,这份报告中CPU使用率不高,但是LOAD却很高。当时那个朋友很不理解,在他一贯的认知中,load一般来说是和CPU使用率紧密关联的。后来通过分析我们发现在他的系统中的NFS文件系统出现问题了,因此有不少处于D状态的进程HANG死,从uptime中可以看到load确实比较高,不过实际上CPU很空闲。
除了这种情况外,有时候我们也会发现似乎load average的值和我们从vmstat 看到的r队列的数据会略有不同。下面是一个例子。
从1秒钟监视一次的vmstat命令上看,r队列的深度平均下来应该不到40,而从uptime上我们看到了一个很高的值。
而有的时候,我们看到实际当前的r队列很高,但是最近1分钟的平均负载又偏小。这是怎么回事呢?如果你遇到了这个问题,但是觉得无法理解,那么就说明你还没有真正理解load average的计算方法。load average 中的三个值分别是最近1分钟,5分钟和15分钟的平均值。字面上的意思就是这样的,实际上真的如此吗?
首先我们来理解一下uptime中的1分钟平均负载的含义,从字面的理解我们肯定很容易理解为最近1分钟的负载。实际上并不是这样的,根据https://en.wikipedia.org/wiki/Load_(computing)上的描述,uptime在统计最近1分钟负载的时候,还考虑了衰减的问题。在1分钟平均值中,1-1/e的权重是最近1分钟的LOAD统计值(大约是63%),还有另外37%的权重是系统启动以来(不包含最近1分钟)的LOAD的平均值。 5分钟与15分钟的average load值也是类似的。因此,如果我们的系统是一个在一天内负载变化很大的系统,那么从uptime中看到的average load有可能是偏低的,并不能十分精准的反映出实际的当前负载。
如果是这样,那么为什么我们有时候看到的average load会高于实际的runable队列深度呢?这种现象只会在LINUX上看到,在其他的UNIX系统上是看不到这种情况的。其他的LINUX系统在统计LOAD的时候只统计R状态的线程,而LINUX上会将状态为R和D的进程累加后统计为LOAD。D状态的进程是处于非阻断等待状态,大部分情况是在等待磁盘IO,网络IO等。Linux的开发者认为,D状态是十分短暂的,处于D状态的进程一旦完成IO后,马上就会转换为R状态,因此把D状态的进程也统计为LOAD似乎也是合理的。
确实是这样的,IO子系统处于正常状态的时候,D状态的进程很快会转变为R状态,因此LOAD的统计不会出现太大的问题。不过当我们的IO子系统出现问题的时候,比如我们的系统中的IO负载很高,IO相应速度比较慢,那么处于D状态的线程数量就会比较多,D状态的进程转换为R状态也就会比较慢,这个时候我们看到系统的LOAD就会高于实际的CPU使用情况情况,这张情况下,我们会看到CPU的使用率里WIO的比例会比较高。我曾经遇到过一个系统,CPU使用率并不高,但是LOAD特别高,客户也觉得十分奇怪。后来发现这个系统中的NFS文件系统出了问题,很多进程都处于D状态僵死了。这时候我们看到的现象就是load average比实际的CPU使用情况要高很多。在我们遇到物理IO性能较差的时候,也会看到类似的现象,实际上linux系统下,把r队列和b队列的值相加,作为load指标,而在其他的UNIX系统下,不存在这个问题。因此在LINUX下,我们如果发现LOAD比较高的时候,不要只是去分析CPU的使用情况,还需要排除是IO阻塞引起的LOAD变大的问题,这样才不会出现明显的偏差。
从上面老白的分析可以看出,如果我们不能真正的理解average load,那么这个指标可能会给我们带来很多的误解,但是一旦我们真的理解了average load的含义,我们再去使用这个指标的时候不仅不会产生误解,甚至还能从这个指标的异常判断出一些系统可能存在的隐患。
老白曾经多次提过,准确的指标是自动化运维的基石,准确的理解指标的真正含义,才能真这个的发挥指标的作用。
预览时标签不可点
关闭
更多
名称已清空
微信扫一扫赞赏作者
喜欢作者
其它金额
文章
暂无文章
喜欢作者
其它金额
¥
最低赞赏 ¥0
确定
返回
其它金额
更多
赞赏金额
¥
最低赞赏 ¥0
1
2
3
4
5
6
7
8
9
0
.
系统健康管理专辑
90
系统运维
68
操作系统分析系列
24
系统健康管理专辑 · 目录
上一篇
运维人员应该多学习一些理论知识
下一篇
运维与运维服务的数字化
关闭
更多
搜索「」网络结果
暂无留言
已无更多数据
发消息
写留言:
关闭
写留言
提交
更多
表情
微信扫一扫
关注该公众号
继续滑动看下一个
轻触阅读原文
白鳝的洞穴
向上滑动看下一个
当前内容可能存在未经审核的第三方商业营销信息,请确认是否继续访问。
继续访问
取消
微信公众平台广告规范指引
知道了
微信扫一扫
使用小程序
取消
允许
取消
允许
×
分析
:
,
,
,
,
,
,
,
,
,
,
,
,
。
视频
小程序
赞
,轻点两下取消赞
在看
,轻点两下取消在看
分享
留言
收藏
听过
白鳝的洞穴
评价CPU负载用average LOAD一定没问题吗??
,
,
关闭
选择留言身份
更多
关闭
更多
投诉已提交
请选择补充原因