【系统平均负载导读】何为系统平均负载？假设一台云服务主机，突然之间响应用户请求的时间变长了，那么这个时候应该如何去排查？带着这个问题，我们对“平均负载”展开深入的探讨和研究。
何为Linux系统的平均负载？单位时间内，系统中处于可运行状态和不可中断状态的进程数，和CPU的使用率是不同的概念，下文将详细介绍CPU使用率的问题。
那何为可运行状态的进程？正在使用CPU或者等待CPU资源的进程称为可运行状态的进程。
不可中断的进程呢？正在处于内核态关键流程的进程，比如在等待IO响应的进程，就是不可中断的。用ps命令看进程信息时，进程状态为D的进程即是不可中断的进程。
那这些进程加起来的总数刚好等于系统CPU的核数，那就是最理想化的状态，每个CPU都得到了利用，如果这些进程的数量超过了CPU的核数，就是过载了，至少在同一时刻，有些进程是没法得到CPU资源的。
以笔者的Linux主机为例，笔者的CPU核数是4，可以通过如下的指令查看CPU的核数。
grep 'model name' /proc/cpuinfo | wc -l
那再看看我Linux主机的平均负载，可以通过如下的指令：
watch -d uptime
每隔2s更新一次平均负载信息，比如上图中load average后面跟着便是平均负载的信息，为啥有3个？他们分别是过去 1 分钟、5 分钟、15 分钟的平均负载值，也就是说我的主机，从过去15分钟到最近的一分钟内，平均负载是在降低的，而且平均负载远小于CPU的核数。
所以观察平均负载要结合这三个值来综合分析，看平均负载是呈现上升的趋势还是下降的趋势，那假如在单核的主机上，load average后面的值分别是1.73，0.60，7.98，那说明在最近一分钟内，系统有73%的过载，在过去5分钟的时间点，系统有40%空闲，在过去15分钟，系统有698%的过载。
平均负载过高，CPU的使用率会升高吗？
了解这个问题前，先普及下CPU使用率，何为CPU使用率？单位时间内CPU繁忙情况的统计。
1、CPU密集型进程，使用大量CPU会导致平均负载升高，此时这两者是一致的。此时平均负载和CPU使用率可以画上等号。
2、I/O 密集型进程，等待I/O也会导致平均负载升高，但 CPU 使用率不一定很高。
3、系统存在大量等待CPU的进程(Runnable状态的进程)也会导致平均负载升高，此时CPU使用率和平均负载可以画上等号。
如何排查平均负载过高的问题？
笔者在自己的主机上使用stress命令模拟一个CPU使用率100%的场景。
stress --cpu 1 --timeout 600
随后我们新开启三个终端，分别查看下系统的平均负载、系统的CPU使用率、哪个进程导致了 CPU 使用率为 100%。
可以很明显地看到系统的平均负载呈现出上升的趋势。
那如何查看系统的CPU使用率呢？首先为大家介绍一个命令mpstat，它是一个多核 CPU 性能分析工具，用来实时查看每个CPU的性能指标，以及所有 CPU 的平均指标。比如，输入如下指令：
// 监控所有CPU，后面数字5表示间隔5秒后输出一组数据mpstat -P ALL 5
可以从上图看到核1的CPU使用率为100%，在等待系统IO的占比iowait却为0，这说明平均负载的升高正是由于CPU使用率为100%导致的。
那如何排查是哪个进程导致了CPU使用率到100%吗？此时可以在第四个终端用pidstat指令去排查，何为pidstat？pidstat是一个常用的进程性能分析工具，用来实时查看进程的 CPU、内存、I/O 以及上下文切换等性能指标。输入如下指令：
//每间隔5s，输出一次数据pidstat -u 5 1
很明显此时CPU使用率最高的进程就是我们用stress命令模拟的进程。
通过上述的示例，我们模拟了CPU使用率增高导致平均负载变高的场景，那如果是IO变高，平均负载会是怎样？
继续使用stress命令模拟I/O压力，即不停地执行 sync：
$ stress -i 1 --timeout 600那看看平均负载：
看看进程CPU使用率：
还是可以很清晰看到stress模拟的进程CPU使用率达到了73.21%。
最后再模拟下大量进程的场景，比如我在系统上用stress开启了8个进程，那么此时CPU使用率、平均负载又是怎样的？
// 开启8个进程
stress -c 8 --timeout 600看看平均负载：
此时可以看到系统在最近一分钟内负载已经超过了CPU的核数，148%过载了。
查看进程的情况：
CPU占用率过高的进程全部都是stress模拟出来的进程。
结论：
1、平均负载高可能是CPU密集型进程导致的。
2、平均负载高并不一定代表CPU使用率高，还有可能是I/O繁忙导致的。
3、负载高时，可使用mpstat、pidstat等工具，辅助分析负载的来源。
