服务器性能分析之 load average

我们通常判断一个系统的负载使用 top 等命令，它分别记录了1分钟、5分钟、15分钟的系统平均负载。

可以使用的命令：top  uptime  w  /proc/loadavg

load 简单说就是当前CPU需要干多少活，专业点说就是在特定时间间隔内运行队列（正在CPU运行或等待运行的进程）的平均进程数。

 

那么在队列中都有哪些进程呢？满足以下三个条件的进程都会进入队列中：

 - 它没有在等待I/O操作结果

 - 它没有主动进入等待状态，也就是没有调用wait 

 - 没有被停止

 

负载的呈现类似这样： load average: 0.09  0.05  0.01

三个数字分别代表不同时间段的系统平均负载，当然，它们数字越低越好，说明系统目前处理起来完全没有压力，而数字越大说明负载越高，这也可能是服务器某些地方出现问题的信号。

那么空间多大算正常，多少又算是不正常呢？

这个我们一般根据你系统的CPU核心数来对比，通常它的数字值不大于核心数就说明很正常。网上有一个行车道的例子描述的很好，这里也引用一下。

 

这里以单核CPU为例，一个单核的CPU相当于一条单向行车道。你现在需要收取这条道路上的过桥费，你首先要了解一些信息，比如车辆的载重、以及还有多少车辆在等待过桥等。如果处理完一辆车，你就会通知后面的车辆通过。如果车辆众多，那么就要告诉他们需要等待一会。

因此，需要一些数字来表示车流情况，例如：

0.00 表示目前路上没有车辆。实际上这种情况与 0.00 到 1.00 之间是相同的，总之是很畅通，过往车辆不用丝毫等待。

1.00 表示刚好在这条路的随范围内，这种情况不算很糟糕，只是车流会有些堵，但这种情况一直持续可能会造成交通越来越慢。

1.00 以上，就说明这条路已经超出负荷，交通严重的拥堵。那情况有多糟糕？例如 2.00 说明车流已经超出了路所能随的一倍，将有一倍多余的车正在焦急地等待。3.00 的话就更糟，说明还有超出负载2倍多的车辆正在等待。

这就与负载情况类似。一辆汽车的过桥时间好比是处理器处理某线程的实际时间。unix 系统定义的进程运行时长为所有处理器内核的处理时间加上线程在队列中等待的时长。

理想状态下，都希望负载平均值小于 1，当然不排除部分峰值会大于1，但若长此以往保持这个状态，就说有问题了。一般会把告警值设在 0.70 。

如果你的负载长时间负载在0.70以上，那么你需要在情况变的更糟之前，排查问题了。

平时我们以哪个数值为准？其实应该重点看15分钟负载或5分钟负载。坦白说，如果1分钟的平均负载超过1.00，那么仍可以认定服务器是正常的。但是如果15分钟的负载仍然保持在 1.00 的话，那就应该注意了。

系统是以处理器的核心数来计算负载值的，在多核处理器中，你的系统均值，不应该高于你处理器核心的总数量 。

 

一般我们总认为负载高了，说明CPU忙不过来了，进程等待的太多，需要升级CPU来解决问题。其实load值过高也不一定是CPU资源紧张导致的，我们还需要结合vmstat 等工具来确认和判断负载过高的系统瓶颈到底在哪，是CPU不足还是磁盘IO问题？还是内存不足？

vmstat  输出 ：

[root@ghqmailbf1 ~]# vmstat -n 2
procs -----------memory----------          ---swap-- -----io----   --system--      -----cpu------
r b     swpd free      buff      cache           si so         bi bo      in     cs        us sy id wa st
0 0    7168 144600 275412 23516712    0 0           1 45      0      0          1  1  98 0 0
2 0    7168 151380 275420 23518184    0 0           0 432    9385 7004     2  1  97 0 0
2 0    7168 141920 275424 23520196    0 0           2 998    9065 10732   3  1  96 0 0

procs 列：

r 表示运行和等待CPU时间片的进程数，如果长期大于1，说明CPU不足，要加CPU

b 表示在等待资源的进程数，比如正在等待I/O，内存交换等

memory 列：

swpd 正在使用的虚拟内存大小

free 空闲内存大小

buff 已使用的buff 大小，对块设备的读写进行缓冲

cache 已用的cache 大小，文件系统的cache

swap 列：

si 每秒从交换区写到内存的大小（kb/s）

so 每秒从内存写到交换区的大小

IO 列：

bi 每秒读取磁盘的块数

bo 每秒写入磁盘的块数

system 列：（这两个值越大，会看到消耗的cpu时间越多）

in 每秒中断数，包括时钟中断

cs 每秒上下文切换   

cpu列（以百分比表示）：

us 用户进程执行消耗的cpu时间（user time），值比较高时，说明用户进程消耗的cpu时间多，如果长时间超过50%，那么我们就该考虑优化程序算法或其他措施了

sy 系统进程消耗cpu时间（sys time），值过高时，说明系统内核消耗的cpu时间多，应该检查原因

id 空闲时间（包括IO等待时间）

wa 等待IO时间，过高时，说明IO等待比较严重，这可能是由于磁盘大量随机访问造成的，也有可能是磁盘的带宽出现瓶颈

 

问题定位：

如果pros 的 r 长时间大于CPU核心数，说明有很多进程在等待CPU，或者cpu 的id 长时间少于40%，说明CPU的负荷很重

如果 si  so 长期不等于0，说明内存不足

iowait 升高说明有许多进程因为等待I/O而休眠的数量更多，或者因为等待I/O休眠的时间更长。但IOwait升高并不能确定IO瓶颈，在I/O完全一样的情况下，CPU忙闲状态的变化就能够影响 %iowait 的大小，在CPU繁忙期间发生的I/O，无论有多少，%iowait 的值都是不受影响的（因为 %iowait 的第一个前提条件就是CPU必须空闲）；当CPU繁忙程度下降时，有一部分I/O落入了CPU空闲的时间段内，这就导致了 %iowait 升高，可见，I/O并没有变化，%iowait 却升高了，原因仅仅是CPU的空闲时间增加了，请记住，系统中有成百上千的进程数，任何一个进程都可以引起CPU和I/O的变化，因为 %iowait、%idle、%user、%system 等这些指标都是全局性的，并不是特指某个进程。

如果看到 %iowait 升高，还需检查I/O量有没有明显增加，avserv/avwait/avque等指标有没有明显增大，应用有没有感觉变慢，如果都没有，就没什么好担心的。