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

最新推荐文章于 2025-09-16 10:26:38 发布

原创最新推荐文章于 2025-09-16 10:26:38 发布 · 450 阅读

0 ·

CC 4.0 BY-SA版权

文章标签：

#python #linux #java #大数据 #人工智能

本文详细介绍了Linux系统中的平均负载和CPU使用率的区别，以及如何通过top、uptime、iostat、mpstat和pidstat等工具进行系统性能分析。平均负载不仅包括CPU使用中的进程，还包括等待I/O的进程，它反映了系统整体的负载情况。当平均负载超过CPU数量的70%时，可能需要进行问题排查。通过案例分析了CPU密集型、I/O密集型和大量进程场景下的平均负载变化，并提供了排查方法。

theme: cyanosis

「本文已参与好文召集令活动，点击查看：后端、大前端双赛道投稿，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 过载。