评价CPU负载用average LOAD一定没问题吗??

评价CPU负载用average LOAD一定没问题吗??

我们可以很方便的使用uptime命令来获得Load average的数据。

评价CPU负载用average LOAD一定没问题吗??

以前我也是用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的含义,我们再去使用这个指标的时候不仅不会产生误解,甚至还能从这个指标的异常判断出一些系统可能存在的隐患。
老白曾经多次提过,准确的指标是自动化运维的基石,准确的理解指标的真正含义,才能真这个的发挥指标的作用。

评价CPU负载用average LOAD一定没问题吗??》来自互联网,仅为收藏学习,如侵权请联系删除。本文URL:https://www.hashtobe.com/976.html