如何分析系统平均负载过高？

前言

我相信你应该用过uptime命令查询系统负载的情况，或者在各种监控终端上看到过系统load这一项，但是每次问别人到底什么是系统load？系统load到达多少算过高？又有哪些原因会造成系统load过载？我发现很少有人能回答清楚，大多数都觉得系统load过载就表示CPU使用率过载、然而实际上并不完全这样的，本文就来仔细分析一下到底有哪些原因会造成系统load过载！

uptime命令

还是先来看看uptime命令，

通过uptime命令可以观察到 load average（平均负载），三个数字分别表示过去1分钟、5分钟、15分钟的系统平均负载。

平均负载

提到平均负载，大多数人都认为就是系统单位时间内CPU的使用率，比如上面的0.02就表示过去5分钟系统CPU使用率为2%，很明显这样的理解是不正确的，不要以为负载和CPU使用率有什么关系。

我们可以通过man uptime介绍，来看看官方对于平均负载的定义是怎样的。

其中如下这段定义表明了什么是平均负载

System load averages is the average number of processes that are either in a  runnable  or  uninterruptable  state

System load averages是处于可运行或不可中断状态的进程的平均数。

那什么是可运行和不可中断呢？这里需要解释一下。

所谓可运行是指正在使用 CPU 或者正在等待 CPU 的进程，也就是我们常用 ps 命令看到的，处于 R 状态（Running 或 Runnable）的进程。

不可中断是处于不间断状态的进程，此流程是不可打断的，比如最常见的是等待磁盘设备的 I/O 响应，也就是我们在 ps 命令中看到的 D 状态（Uninterruptible Sleep，也称为 Disk Sleep）的进程。

所以，平均负载更准确的定义应该是单位时间内活跃进程数的指数衰减平均值。

平均负载到底是多少才合理

既然我们知道平均负载实际就是活跃的进程数，那最理想的状态下应该就是每颗CPU上刚好运行一个进程，这样才能充分的利用CPU，比如平均负载如果为2时，如果只有1颗CPU，则表示有一半的进程争抢不到CPU，如果有2颗CPU，则表示每颗CPU都得到了100%的利用，如果有4颗CPU，则表示CPU利用率只有50%。

一般情况下，当平均负载高于CPU数量70%时，就应该需要排查负载高的原因了，当然70%是一个经验值，冗余30%也是为了应对一些突发状况，或者系统短时高峰的场景，为了确保系统的稳定性，我们应当持续观察系统每天的负载情况，对负载进行实时监控，当持续出现负载异常时能够自动告警。

平均负载和CPU的关系

前面已经做过说明，平均负载高不一定就会带来CPU使用率高，因为平均负载表示的含义是，可运行或不可中断状态的进程，如果负载高是因为可运行进程造成的，那就会造成CPU使用率也高，但如果负载高是因为不可中断进程造成的，那CPU使用率是不会很高的。

CPU与进程1比1，CPU使用率高导致负载变高

使用stress来模拟平均负载高的情况

运行命令

stress --cpu 1

负载变高

CPU达到100%

I/O高，导致负载高

使用stress-ng，模拟I/O压力导致负载高的场景

运行命令

stress-ng -i 4 --hdd 1 --timeout 600

负载变高

CPU使用率并不高，但是iowait变的很高

进程数超过CPU数，导致负载高

运用命令

 stress -c 8

负载变高

单个CPU使用率并不高

大多数都消耗在wait上，也就是等待CPU的时间上