1、平均负载和cpu利用率的理解

平均负载

每次发现系统变慢时，通常做的第一件事，就是执行 top 或者 uptime 命令，来了解系统的负载情况。比如像下面这样，在命令行里输入了 uptime 命令，系统也随即给出了结果。

最后三个数字含义依次则是过去 1 分钟、5 分钟、15 分钟的平均负载（Load Average）。

平均负载？有人会说，平均负载不就是单位时间内的 CPU 使用率吗？上面的 11.9，就代表CPU 使用率是 1190%。其实并不是这样，可以通过执行 man uptime 命令，来了解平均负载的详细解释。

uptime  gives  a one line display of the following information.  The current time, how long the system has been running, how many users are currently logged on, and the system load averages for the
       past 1, 5, and 15 minutes.

       This is the same information contained in the header line displayed by w(1).

       System load averages is the average number of processes that are either in a runnable or uninterruptable state.  A process in a runnable state is either using the CPU or waiting to use the CPU.   A
       process in uninterruptable state is waiting for some I/O access, eg waiting for disk.  The averages are taken over the three time intervals.  Load averages are not normalized for the number of CPUs
       in a system, so a load average of 1 means a single CPU system is loaded all the time while on a 4 CPU system it means it was idle 75% of the time.

简单理解，平均负载是指单位时间内，系统处于可运行状态和不可中断状态的平均进程数，也就是平均活跃进程数，它和 CPU 使用率并没有直接关系。这里先理解下，可运行状态和不可中断状态。

• 可运行状态进程：是指正在使用 CPU 或者正在等待 CPU 的进程，也就是ps 命令看到的，处于 R 状态（Running 或 Runnable）的进程。
• 不可中断状态进程：是正处于内核态关键流程中的进程，并且这些流程是不可打断的。比如最常见的是等待硬件设备的 I/O 响应，也就是我们在 ps 命令中看到的 D 状态（Uninterruptible Sleep，也称为 Disk Sleep）的进程。

比如，当一个进程向磁盘读写数据时，为了保证数据的一致性，在得到磁盘回复前，它是不能被其他进程或者中断打断的，这个时候的进程就处于不可中断状态。如果此时的进程被打断了，就容易出现磁盘数据与进程数据不一致的问题。

所以，不可中断状态实际上是系统对进程和硬件设备的一种保护机制。

因此，可以简单理解为，平均负载其实就是平均活跃进程数。平均活跃进程数，直观上的理解就是单位时间内的活跃进程数，但它实际上是活跃进程数的指数衰减平均值。这个“指数衰减平均”的详细含义你不用计较，这只是系统的一种更快速的计算方式，直接当成活跃进程数的平均值也没问题。

既然平均的是活跃进程数，那么最理想的，就是每个 CPU 上都刚好运行着一个进程，这样每个 CPU 都得到了充分利用。比如当平均负载为 2 时，意味着什么呢？

• 在只有 2 个 CPU 的系统上，意味着所有的 CPU 都刚好被完全占用。
• 在 4 个 CPU 的系统上，意味着 CPU 有 50% 的空闲。
• 而在只有 1 个 CPU 的系统中，则意味着有一半的进程竞争不到 CPU。

平均负载为多少时合理？

在 uptime 命令的结果里，那三个时间段的平均负载数，多大的时候能说明系统负载高？或是多小的时候就能说明系统负载很低呢？

平均负载最理想的情况是等于 CPU 个数。所以在评判平均负载时，首先你要知道系统有几个 CPU，这可以通过 top 命令或者从文件 /proc/cpuinfo 中读取，比如：

grep 'model name' /proc/cpuinfo | wc -l

有了 CPU 个数，我们就可以判断出，当平均负载比 CPU 个数还大的时候，系统已经出现了过载。不过，且慢，新的问题又来了。我们在例子中可以看到，平均负载有三个数值，到底该参考哪一个呢？

实际上，都要看。三个不同时间间隔的平均值，其实给我们提供了，分析系统负载趋势的数据来源，让我们能更全面、更立体地理解目前的负载状况。

• 如果 1 分钟、5 分钟、15 分钟的三个值基本相同，或者相差不大，就说明系统负载很平稳。
• 如果 1 分钟的值远小于 15 分钟的值，就说明系统最近 1 分钟的负载在减少，而过去15 分钟内却有很大的负载。
• 如果 1 分钟的值远大于 15 分钟的值，就说明最近 1 分钟的负载在增加，这种增加有可能只是临时性的，也有可能还会持续增加下去，所以就需要持续观察。一旦  1 分钟的平均负载接近或超过了 CPU 的个数，就意味着系统正在发生过载的问题，这时就得分析调查是哪里导致的问题，并要想办法优化了。

假设在一核 CPU 系统上看到平均负载为 1.73，0.60，7.98， 那么说明在过去 1 分钟内，系统有 73% 的超载，而在 15 分钟内，有 698% 的超载，从整体趋势来看，系统的负载在降低。

那么，在实际生产环境中，平均负载多高时，需要我们重点关注呢？

当平均负载高于 CPU 数量 70% 的时候，就应该分析排查负载高的问题了。一旦负载过高，就可能导致进程响应变慢，进而影响服务的正常功能。

但 70% 这个数字并不是绝对的，最推荐的方法，还是把系统的平均负载监控起来，然后根据更多的历史数据，判断负载的变化趋势。当发现负载有明显升高趋势时，比如说负载翻倍了，再去做分析和调查。

CPU使用率

现实工作中，我们经常容易把平均负载和CPU使用率混淆，所以在这里做一个区分。

可能你会疑惑，既然平均负载代表的是活跃进程数，那平均负载高了，不就意味着CPU使用率高吗？

我们还是要回到平均负载的含义上来，平均负载是指单位时间内，处于可运行状态和不可中断状态的进程数。所以，它不仅包括了正在使用CPU 的进程，还包括等待 CPU 和等待I/O 的进程。

而 CPU 使用率，是单位时间内CPU繁忙情况的统计，跟平均负载并不一定完全对应。比如：

• CPU密集型进程，使用大量CPU会导致平均负载升高，此时这两者是一致的；
• I/O密集型进程，等待I/O也会导致平均负载升高，但CPU使用率不一定很高；
• 大量等待CPU的进程调度也会导致平均负载升高，此时的CPU使用率也会比较高；

平均负载案例分析

三个示例分别来看这三种情况，并用 iostat、mpstat、pidstat 等工具，找出平均负载升高的根源。

下面的案例都是基于 Debian 11

机器配置：4CPU，16GB 内存。

预先安装 stress 和 sysstat 包，如 apt install stress sysstat

stress 是一个 Linux 系统压力测试工具，这里用作异常进程模拟平均负载升高的场景。

• sysstat 包含了常用的 Linux 性能工具，用来监控和分析系统的性能。案例会用到这个包的两个命令 mpstat 和 pidstat。
• mpstat 是一个常用的多核 CPU 性能分析工具，用来实时查看每个CPU的性能指标， 以及所有CPU的平均指标。
• pidstat 是一个常用的进程性能分析工具，用来实时查看进程的 CPU、内存、I/O 以及上下文切换等性能指标。

此外，每个场景都需要开三个终端，登录到同一台 Linux 机器中。如果上面的要求都已经完成了，你可以先用 uptime 命令，看一下测试前的平均负载情况：

 03:49:31 up  2:16,  4 users,  load average: 0.00, 0.00, 0.00

场景一：CPU 密集型进程

首先，我们在第一个终端运行 stress 命令，模拟一个 CPU 使用率 100% 的场景：

stress --cpu 1 --timeout 600接着，在第二个终端运行 uptime 查看平均负载的变化情况：

watch -d uptime

03:51:44 up  2:18,  4 users,  load average: 1.15, 0.33, 0.11

# -d 参数表示高亮显示变化的区域

最后，在第三个终端运行 mpstat 查看 CPU 使用率的变化情况：

root@debian:~# mpstat -P ALL 5
Linux 5.10.0-23-amd64 (debian) 	09/07/23 	_x86_64_	(4 CPU)

03:55:21     CPU    %usr   %nice    %sys %iowait    %irq   %soft  %steal  %guest  %gnice   %idle
03:55:26     all   12.60    0.00    0.00    0.00    0.00    0.05   12.50    0.00    0.00   74.85
03:55:26       0   50.00    0.00    0.00    0.00    0.00    0.00   50.00    0.00    0.00    0.00
03:55:26       1    0.20    0.00    0.00    0.00    0.00    0.00    0.00    0.00    0.00   99.80
03:55:26       2    0.00    0.00    0.00    0.00    0.00    0.00    0.00    0.00    0.00  100.00
03:55:26       3    0.20    0.00    0.00    0.00    0.00    0.20    0.00    0.00    0.00   99.60

从终端二中可以看到，1 分钟的平均负载会慢慢增加到 1.10，而从终端三中还可以看到， 正好有一个 CPU 的使用率为 100%，但它的 iowait 只有 0。这说明，平均负载的升高正是由于 CPU 使用率为 100% 。

那么，到底是哪个进程导致了 CPU 使用率为 100% 呢？可以使用 pidstat 来查询：

root@debian:~# pidstat -u 5 1
Linux 5.10.0-23-amd64 (debian) 	09/07/23 	_x86_64_	(4 CPU)

03:56:03      UID       PID    %usr %system  %guest   %wait    %CPU   CPU  Command
03:56:08        0        41    0.20    0.00    0.00    0.20    0.20     1  kcompactd0
03:56:08        0     11364    0.00    0.20    0.00    0.00    0.20     1  kworker/1:0-events
03:56:08        0     11928   99.60    0.20    0.00    0.00   99.80     3  stress
03:56:08        0     11996    0.00    0.20    0.00    0.00    0.20     0  pidstat

Average:      UID       PID    %usr %system  %guest   %wait    %CPU   CPU  Command
Average:        0        41    0.20    0.00    0.00    0.20    0.20     -  kcompactd0
Average:        0     11364    0.00    0.20    0.00    0.00    0.20     -  kworker/1:0-events
Average:        0     11928   99.60    0.20    0.00    0.00   99.80     -  stress
Average:        0     11996    0.00    0.20    0.00    0.00    0.20     -  pidstat

# 间隔 5 秒后输出一组数据

从这里可以明显看到，stress 进程的 CPU 使用率为 100%。

场景二：I/O 密集型进程

首先还是运行 stress 命令，但这次模拟 I/O 压力，即不停地执行 sync：

stress -i 1 --timeout 600

还是在第二个终端运行 uptime 查看平均负载的变化情况：

然后，第三个终端运行 mpstat 查看 CPU 使用率的变化情况：

# 显示所有 CPU 的指标，并在间隔 5 秒输出一组数据

^Croot@debian:~# mpstat -P ALL 5
Linux 5.10.0-23-amd64 (debian) 	09/07/23 	_x86_64_	(4 CPU)

05:32:03     CPU    %usr   %nice    %sys %iowait    %irq   %soft  %steal  %guest  %gnice   %idle
05:32:08     all    0.09    0.00    2.50   19.65    0.00    0.05   10.16    0.00    0.00   67.56
05:32:08       0    0.20    0.00    6.54   54.81    0.00    0.00    0.00    0.00    0.00   38.45
05:32:08       1    0.00    0.00    4.02   33.13    0.00    0.20    0.20    0.00    0.00   62.45
05:32:08       2    0.00    0.00    0.40    0.00    0.00    0.00    0.00    0.00    0.00   99.60
05:32:08       3    0.14    0.00    0.14    0.00    0.00    0.00   31.15    0.00    0.00   68.58

05:32:08     CPU    %usr   %nice    %sys %iowait    %irq   %soft  %steal  %guest  %gnice   %idle
05:32:13     all    0.18    0.00    2.53   19.62    0.00    0.09   10.42    0.00    0.00   67.16
05:32:13       0    0.20    0.00    1.81   16.53    0.00    0.00    0.00    0.00    0.00   81.45
05:32:13       1    0.34    0.00    7.78   59.73    0.00    0.34   15.74    0.00    0.00   16.07
05:32:13       2    0.20    0.00    0.20    0.00    0.00    0.00    0.00    0.00    0.00   99.60
05:32:13       3    0.00    0.00    0.00    0.00    0.00    0.00   21.90    0.00    0.00   78.10

从这里可以看到，1 分钟的平均负载会慢慢增加到0.8，其中一个 CPU 的系统 CPU 使用率升高到了 84%，而 iowait 高达 59.73%。这说明，平均负载的升高是由于 iowait 的升高。

那么到底是哪个进程，导致 iowait 这么高呢？我们还是用 pidstat 来查询：

# 间隔 5 秒后输出一组数据，-u 表示 CPU 指标 。
pidstat可以发现，还是 stress 进程导致的。

场景三：大量进程的场景

当系统中运行进程超出 CPU 运行能力时，就会出现等待 CPU 的进程。比如，使用 stress，但这次模拟的是 8 个进程：

由于系统只有 24个 CPU，明显比 8 个进程要少得多，因而，系统的 CPU 处于严重过载状

态，平均负载高达 7.97：

接着再运行 pidstat 来看一下进程的情况：

stress -c 8 --timeout 600

# 间隔 5 秒后输出一组数据

 可以看出，8 个进程在争抢 4 个CPU，每个进程等待 CPU 的时间（也就是代码块中的%wait 列）高达 75%。这些超出 CPU 计算能力的进程，最终导致 CPU 过载。

小结

平均负载提供了一个快速查看系统整体性能的手段，反映了整体的负载情况。但只看平均负载本身，并不能直接发现，到底是哪里出现了瓶颈。所以，在理解平均负载时，也要注意：平均负载高有可能是 CPU 密集型进程导致的；平均负载高并不一定代表 CPU 使用率高，还有可能是 I/O 更繁忙了；当发现负载高的时候，可以使用 mpstat、pidstat 等工具，辅助分析负载的来源。