Linux系统篇—CPU平均负载介绍与案例假设

「本文已参与好文召集令活动，点击查看：后端、大前端双赛道投稿，2万元奖池等你挑战！」

平均负载

通过执行top或者uptime命令，可以了解系统的负载情况，如图所示：

每列输出的含义：

第一行包括：当前时间、系统运行时间、正在登陆的用户数

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 处于严重过载状态）
在第二个终端运行 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/

关注＋点赞👍收藏❤️不迷路

文章每周持续更新，可以微信搜索「十分钟学编程」第一时间阅读和催更，如果这个文章写得还不错，觉得有点东西的话
各位的支持和认可，就是我创作的最大动力，我们下篇文章见！