平均负载
通过执行top或者uptime命令，可以了解系统的负载情况，如图所示：
每列输出的含义：
第一行包括：当前时间、系统运行时间、正在登陆的用户数
top - 15:57:46 up 6l days, 21:26, sl user
load average：三个数字分别表示 过去1分钟、5分钟、15分钟的平均负载
cpu使用率
CPU 使用率，是单位时间内 CPU 繁忙情况的统计，跟平均负载并不一定完全对应。 比如：
- CPU 密集型进程，使用大量 CPU 会导致平均负载升高，此时这两者是一致的；
- I/O 密集型进程，等待 I/O 也会导致平均负载升高，但 CPU 使用率不一定很高；
- 大量等待 CPU 的进程调度也会导致平均负载升高，此时的 CPU 使用率也会比较高。
平均负载的含义
平均负载是指单位时间内，系统处于可运行状态和不可中断状态的平均进程数，它不仅包括了正在使用 CPU 的进程，还包括等待 CPU 和等待I/O 的进程。也就是平均活跃进程数，它和 CPU 使用率并没有直接关系。
- 可运行状态的进程
正在使用 CPU 或者正在等待 CPU 的进程，也就是我们常用ps 命令看到的，处于 R 状态（Running 或 Runnable） 的进程 - 不可中断状态的进程
正处于内核态关键流程中的进程，并且这些流程是不可打断的， 比如最常见的是等待硬件设备的 I/O 响应，也就是我们在 ps 命令中看到的 D 状态（Uninterruptible Sleep，也称为 Disk Sleep）的进程。不可中断状态实际上是系统对进程和硬件设备的一种保护机制。
平均负载多少合适
最理想的负载就是每个cpu上都刚好运行一个进程，这样每个cpu都得到了充分利用。所以在评判平均负载时，首先你要知道系统有几个 CPU，可通过以下命令查询
# 关于 grep 和 wc 的用法请查询它们的手册或者网络搜索 grep 'model name' /proc/cpuinfo | wc -l 复制代码
当平均负载为2时，意味着什么呢?
- 在只有 2 个 CPU 的系统上，意味着所有的 CPU 都刚好被完全占用。
- 在 4 个 CPU 的系统上，意味着 CPU 有 50% 的空闲。
- 而在只有 1 个 CPU 的系统中，则意味着有一半的进程竞争不到 CPU。
当平均负载比 CPU 个数还大的时候，系统就已经出现了过载。
load average变化举例说明
如果 1 分钟的值远小于 15 分钟的值，就说明系统最近 1 分钟的负载在减少，而过去15 分钟内却有很大的负载。
如果 1 分钟的值远大于 15 分钟的值，就说明最近 1 分钟的负载在增加，这种增加有可能只是临时性的，也有可能还会持续增加下去，所以就需要持续观察。一旦 1分钟的平均负载接近或超过了 CPU 的个数，就意味着系统正在发生过载的问题，这时就得分析调查是哪里导致的问题，并要想办法优化了。
一般情况下，当 平均负载高于 CPU 数量 70% 的时候，就应该分析排查负载高的问题了
但 70% 这个数字并不是绝对的，最推荐的方法，还是把系统的平均负载监控起来，然后根据更多的历史数据，判断负载的变化趋势。当发现负载有明显升高趋势时，比如说负载翻倍了，再去做分析和调查。
平均负载问题排查与案例假设
通过使用iostat、mpstat、pidstat工具，找出平均负载升高的根源
准备
预先安装 stress 和 sysstat 包，如 apt install stress sysstat
- stress: 一个 Linux 系统压力测试工具，可以用作异常进程模拟平均负载升高的场景。
- sysstat： 包含了常用的 Linux 性能工具，用来监控和分析系统的性能。案例会用到这个包的两个命令
mpstat和pidstat。
- mpstat 一个常用的多核 CPU 性能分析工具，用来实时查看每个 CPU 的性能指标，以及所有 CPU 的平均指标。
- pidstat 一个常用的进程性能分析工具，用来实时查看进程的 CPU、内存、I/O 以及上下文切换等性能指标。
场景一：CPU 密集型进程
- 在第一个终端运行
stress --cpu 1 --timeout 600命令，模拟一个 CPU 使用率 100% 的场景 （不想模拟的可以忽略）： - 在第二个终端运行
watch -d uptime查看平均负载的变化情况 （-d 参数表示高亮显示变化的区域） - 在第三个终端运行
mpstat -P ALL 5查看 CPU 使用率的变化情况 （-P ALL 表示监控所有 CPU，后面数字 5 表示间隔 5 秒后输出一组数据）
从 [2] 可以看到，1 分钟的平均负载会慢慢增加到 1.00，而从 [3] 中还可以看到，正好有一个 CPU 的使用率为 100%，但它的 iowait 只有 0。这说明，平均负载的升高正是由于 CPU 使用率为 100% 。
- 使用
pidstat -u 5 1来查找哪个进程导致了 CPU 使用率为 100% （间隔 5 秒后输出一组数据） 
从这里可以明显看到，stress 进程的 CPU 使用率为 100%。
场景二：I/O 密集型进程
- 运行
stress -i 1 --timeout 600命令，但这次模拟 I/O 压力，即不停地执行 sync - 在第二个终端运行
watch -d uptime查看平均负载的变化情况 （-d 参数表示高亮显示变化的区域） - 在第三个终端运行
mpstat -P ALL 5 1查看 CPU 使用率的变化情况 （-P ALL 表示监控所有 CPU，后面数字 5 表示间隔 5 秒后输出一组数据） 
从 [3] 可以看到，1 分钟的平均负载会慢慢增加到 1.06，其中一个CPU的系统的CPU使用率升高到了 23.87，而 iowait 高达 67.53%。这说明，平均负载的升高是由于 iowait 的升高。
- 使用
pidstat -u 5 1来查找哪个进程导致 iowait 这么高 （间隔 5 秒后输出一组数据） 
可以发现，还是 stress 进程导致的。
场景三：大量进程的场景
- 使用
stress -c 8 --timeout 600，这次模拟的是 8 个进程（于系统只有 2 个 CPU，系统的 CPU 处于严重过载状态）
top -17:45:28 up 203 days, 6:28, 2 users, load average: 6.44, 1.93，日.72 Tasks: 112 total, 10 running, 102 sleeping, 0 stopped, 0 zombie 8Cpu0 :99.3 us， 0.7 sy. 0.0 ni, 0.0 id. 0.0 wa， 0.0 hi, 0.0 si， 0.0 st sCpul :99.3 us， 0.7 sy, 0.0 ni, 0.0 10. 0.0 wa, 0.0 ni. 0.0 si, 0.e st KiB Mem : 3880520 total, 212180 free, 1577304 used, 2091036 buff/cache KiB Swap: 0 total， 0 free, 0 used. 1991108
- 在第二个终端运行
mpstat -P ALL 5 1查看 CPU 使用率的变化情况 （-P ALL 表示监控所有 CPU，后面数字 5 表示间隔 5 秒后输出一组数据） 
- 运行
pidstat -u 5 1来看一下进程的情况 （间隔 5 秒后输出一组数据） 
可以看出，8 个进程在争抢 2 个 CPU， 每个进程等待 CPU 的时间（也就是代码块中的
%wait列）高达 75%。 这些超出 CPU 计算能力的进程，最终导致 CPU 过载。
总结
平均负载提供了一个快速查看系统整体性能的手段，反映了整体的负载情况。但只看平均负载本身，我们并不能直接发现到底是哪里出现了瓶颈。
在理解平均负载时，要注意：
- 平均负载高有可能是 CPU 密集型进程导致的；
- 平均负载高并不一定代表 CPU 使用率高，还有可能是 I/O 更繁忙了；
- 当发现负载高的时候，可以使用
mpstat、pidstat等工具，辅助分析负载的来源。
其他
pidstat没有展示%wait
升级systat到 11.5.5版本及以上
# 通过git下载源码 git clone git://github.com/sysstat/sysstat # 系统配置sysstat cd sysstat/ ./configure # 编译和安装 make & make install # 验证是否安装成功 mpstat -V # 解决 /usr/bin/mpstat: No such file or directory cp pidstat /usr/bin/ cp mpstat /usr/bin/
