基础：什么是平均负载

uptime

每次发现系统变慢时，我们通常做的第一件事情，就是执行top或者uptime命令，来了解系统的负载情况，比如：

oceanstar@oceanstar:~$ uptime
 22:59:50 up 3 min,  1 user,  load average: 0.96, 0.95, 0.42

• 当前时间 ： 22:59:50
• 系统已运行的时间： up 3 min
• 当前在线用户： 1 user
• 平均负载： 0.96, 0.95, 0.42，最近1分钟、5分钟、15分钟系统的平均负载( load average)

平均负载可以说是最常见，也是最重要的系统指标。那么什么是平均负载呢？

什么是平均负载

平均负载，是指单位时间内，系统处于可运行状态和不可中断状态的平均进程树，也就是平均活跃进程数，他和CPU使用率并没有直接关系

• 所谓可运行状态的进程，是指正在使用CPU和正在等待CPU的进程，也就是ps命令看到的，处于R状态(Running、Runnable)的进程
• 所谓不可中断状态的进程，是指正处于内核态关键流程，并且这些流程是不可打断的
  • 比如最常见的是等待硬件设备的IO响应，也就是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
4

有了CPU个数，我们就能判断出，当平均负载比CPU个数大的时候，系统已经出现了过载

第二个问题：平均负载有三个值，到底应该参考哪一个呢？

实际上，都要看。打个⽐⽅，就像初秋时北京的天⽓，如果只看中午的温度，你可能以为还在7⽉份的⼤夏天呢。但如果你结合了早上、中午、晚上三个时间点的温度来看，基本就可以全⽅位了解这⼀天的天⽓情况了

这上不同时间间隔的平均值，可以让我们分析系统负载趋势：

• 如果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%这个数字并不是绝对的，最推荐的⽅法，还是把系统的平均负载监控起来，然后根据更多的历史数据，判断负载的变化
趋势。当发现负载有明显升⾼趋势时，⽐如说负载翻倍了，你再去做分析和调查。

平均负载 VS CPU使用率

• 平均负载是指单位时间内，出于可运行状态和不可中断状态的进程数。所以，它不仅包括正在使用CPU的进程，还包括等待CPU和等待IO的进程
• CPU使用率，是指单位时间内CPU繁忙时间的统计，跟平均负载不一定完全对应，比如：
  • CPU密集型进程，使用大量CPU会导致平均负载升高，此时这两者是一致的
  • IO密集型进程，等待IO也会导致平均负载升高，但CPU使用率不一定很高
  • 大量等待CPU的进程调度也会导致平均负载升高，此时的CPU使用率也会比较高

案例

下⾯，我们以三个示例分别来看这三种情况，并⽤ iostat、mpstat、pidstat 等⼯具，找出平均负载升⾼的根源。

准备

• 机器配置：4 CPU，8GB 内存
• 预先安装 stress 和 sysstat 包，如 apt install stress sysstat。
  • stress：是一个Linyx系统压力测试工具，这里我们用作异常进程模拟平均负载升高的场景
  • sysstat包含了常用的Linux性能⼯具，⽤来监控和分析系统的性能。我们的案例会⽤到这个包的两个命令 mpstat 和pidstat。
    • mpstat 是⼀个常⽤的多核 CPU 性能分析⼯具，⽤来实时查看每个 CPU 的性能指标，以及所有CPU的平均指标。
    • pidstat是⼀个常⽤的进程性能分析⼯具，⽤来实时查看进程的 CPU、内存、I/O 以及上下⽂切换等性能指标

此外，每个场景都需要你开三个终端，登录到同⼀台 Linux 机器中。

另外要注意，下⾯的所有命令，我们都是默认以 root ⽤户运⾏。

如果上⾯的要求都已经完成了，你可以先⽤ uptime 命令，看⼀下测试前的平均负载情况：

$ uptime
... load average: 0.04, 0.02, 0.00

场景一：CPU密集型进程

⾸先，我们在第⼀个终端运⾏ stress 命令，模拟⼀个 CPU 使⽤率 100% 的场景：

# --cpu 1： 指的是测试1个cpu --- 产生1个进程 每个进程都反复不停的计算随机数的平方根
# -t --timeout 600 ： 指定运行600秒后停止
# stress测试cpu，是在用户态将cpu 耗尽。
$ stress --cpu 1 --timeout 600
stress: info: [3629] dispatching hogs: 1 cpu, 0 io, 0 vm, 0 hdd

接着，在第⼆个终端运⾏uptime查看平均负载的变化情况：

# -d 参数表示⾼亮显示变化的区域
$ watch -d uptime
..., load average: 1.00, 0.75, 0.39

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

# -P ALL 表示监控所有CPU，后⾯数字5表示间隔5秒后输出⼀组数据
$ mpstat -P ALL 5
Linux 5.8.0-48-generic (oceanstar) 	2021年10月20日 	_x86_64_	(4 CPU)

23时58分58秒  CPU    %usr   %nice    %sys %iowait    %irq   %soft  %steal  %guest  %gnice   %idle
23时59分03秒  all   25.15    0.00    0.00    0.00    0.00    0.05    0.00    0.00    0.00   74.80
23时59分03秒    0    0.00    0.00    0.00    0.00    0.00    0.20    0.00    0.00    0.00   99.80
23时59分03秒    1  100.00    0.00    0.00    0.00    0.00    0.00    0.00    0.00    0.00    0.00
23时59分03秒    2    0.80    0.00    0.00    0.00    0.00    0.00    0.00    0.00    0.00   99.20
23时59分03秒    3    0.00    0.00    0.00    0.00    0.00    0.00    0.00    0.00    0.00  100.00

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

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

# 间隔5s后输出一组数据，-u表示CPU指标
$ pidstat -u 5 1
Linux 5.8.0-48-generic (oceanstar) 	2021年10月21日 	_x86_64_	(4 CPU)

19时28分26秒   UID       PID    %usr %system  %guest   %wait    %CPU   CPU  Command
19时28分31秒     0       679    0.00    0.20    0.00    0.00    0.20     3  vmtoolsd
19时28分31秒  1000      2187    0.40    1.00    0.00    0.40    1.40     3  Xorg
19时28分31秒  1000      2318    1.20    0.80    0.00    0.20    2.00     1  gnome-shell
19时28分31秒  1000      2659    0.60    0.20    0.00    0.20    0.80     3  gnome-terminal-
19时28分31秒     0      8133    0.20    0.00    0.00    0.00    0.20     1  mpstat
19时28分31秒     0      8153  100.00    0.00    0.00    0.00  100.00     2  stress
19时28分31秒  1000      8231    0.00    0.20    0.00    0.00    0.20     0  pidstat

平均时间:   UID       PID    %usr %system  %guest   %wait    %CPU   CPU  Command
平均时间:     0       679    0.00    0.20    0.00    0.00    0.20     -  vmtoolsd
平均时间:  1000      2187    0.40    1.00    0.00    0.40    1.40     -  Xorg
平均时间:  1000      2318    1.20    0.80    0.00    0.20    2.00     -  gnome-shell
平均时间:  1000      2659    0.60    0.20    0.00    0.20    0.80     -  gnome-terminal-
平均时间:     0      8133    0.20    0.00    0.00    0.00    0.20     -  mpstat
平均时间:     0      8153  100.00    0.00    0.00    0.00  100.00     -  stress
平均时间:  1000      8231    0.00    0.20    0.00    0.00    0.20     -  pidstat

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

场景二：IO密集型进行

首先开始运行stress命令，但这次模拟IO压力，即不停的执行sync：

$ stress -i 1 --timeout 600
stress: info: [8830] dispatching hogs: 0 cpu, 1 io, 0 vm, 0 hdd

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

$ watch -d uptime
 load average: 1.06, 0.90, 0.64

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

# -P ALL 表示监控所有CPU，后⾯数字5表示间隔5秒后输出⼀组数据
$ mpstat -P ALL 5
19时38分29秒  CPU    %usr   %nice    %sys %iowait    %irq   %soft  %steal  %guest  %gnice   %idle
19时38分34秒  all    1.30    0.00   24.96    0.00    0.00    0.00    0.00    0.00    0.00   73.73
19时38分34秒    0    0.00    0.00    0.20    0.00    0.00    0.00    0.00    0.00    0.00   99.80
19时38分34秒    1    0.81    0.00    0.81    0.00    0.00    0.00    0.00    0.00    0.00   98.39
19时38分34秒    2    3.41    0.00   96.39    0.00    0.00    0.00    0.00    0.00    0.00    0.20
19时38分34秒    3    1.00    0.00    2.40    0.00    0.00    0.00    0.00    0.00    0.00   96.61

从这⾥可以看到，1 分钟的平均负载会慢慢增加到 1.06，其中⼀个 CPU 的系统CPU使⽤率升⾼到了 96.39 ，疑惑：为什么这里的iowait还是0，感觉这次CPU的升高是由于系统调用引起的？？？？？？？？

回答：

• iowait无法升高的问题：是因为stress使用的是sync()系统调用，它的作用是刷新缓冲区内存到磁盘中。对于新安装的虚拟机，缓冲区可能比较小，无法产生大的IO压力，这样大部分就是系统调用的消耗了，所以你会看到只有系统CPU使用率升高。
• 解决方法：使用stress的下一代stress-ng，它支持更丰富的选项，比如stress-ng -i --hdd 1 --tiimeout 600 （–hdd表示读写临时文件）

看一下到底是哪个进程导致了CPU使用率急剧上升：

# 间隔5s后输出一组数据，-u表示CPU指标
$ pidstat -u 5 1
Linux 5.8.0-48-generic (oceanstar) 	2021年10月21日 	_x86_64_	(4 CPU)

19时41分28秒   UID       PID    %usr %system  %guest   %wait    %CPU   CPU  Command
19时41分33秒     0       679    0.20    0.00    0.00    0.00    0.20     3  vmtoolsd
19时41分33秒  1000      2187    0.00    0.40    0.00    0.00    0.40     0  Xorg
19时41分33秒  1000      2318    0.40    0.40    0.00    0.40    0.80     1  gnome-shell
19时41分33秒  1000      2470    0.00    0.20    0.00    0.00    0.20     3  vmtoolsd
19时41分33秒  1000      2659    0.00    0.20    0.00    0.20    0.20     0  gnome-terminal-
19时41分33秒     0      2898    0.00    0.20    0.00    0.00    0.20     2  kworker/2:1-events
19时41分33秒     0      8831    3.59   96.21    0.00    0.00   99.80     2  stress
19时41分33秒  1000      9422    0.00    0.20    0.00    0.00    0.20     1  pidstat

平均时间:   UID       PID    %usr %system  %guest   %wait    %CPU   CPU  Command
平均时间:     0       679    0.20    0.00    0.00    0.00    0.20     -  vmtoolsd
平均时间:  1000      2187    0.00    0.40    0.00    0.00    0.40     -  Xorg
平均时间:  1000      2318    0.40    0.40    0.00    0.40    0.80     -  gnome-shell
平均时间:  1000      2470    0.00    0.20    0.00    0.00    0.20     -  vmtoolsd
平均时间:  1000      2659    0.00    0.20    0.00    0.20    0.20     -  gnome-terminal-
平均时间:     0      2898    0.00    0.20    0.00    0.00    0.20     -  kworker/2:1-events
平均时间:     0      8831    3.59   96.21    0.00    0.00   99.80     -  stress
平均时间:  1000      9422    0.00    0.20    0.00    0.00    0.20     -  pidstat

从上面可以看到，还是因为stress

场景三：大量进程的场景

当系统中运行进程超出CPU运行能力时，就会出现等待CPU的进程。

首先开始运行stress命令，但这次模拟了16个进程：

$ stress -c 16 --timeout 600
stress: info: [10197] dispatching hogs: 16 cpu, 0 io, 0 vm, 0 hdd

由于系统只有4个CPU，明显比16个进程要少得多。因此，系统的CPU处于严重过载的状态（6.67）：

$ uptime
 19:50:26 up  1:47,  1 user,  load average: 6.67, 2.08, 1.13

# mpstat -P ALL 5
Linux 5.8.0-48-generic (oceanstar) 	2021年10月21日 	_x86_64_	(4 CPU)

19时51分03秒  CPU    %usr   %nice    %sys %iowait    %irq   %soft  %steal  %guest  %gnice   %idle
19时51分08秒  all   98.88    0.00    1.02    0.00    0.00    0.10    0.00    0.00    0.00    0.00
19时51分08秒    0   98.38    0.00    1.62    0.00    0.00    0.00    0.00    0.00    0.00    0.00
19时51分08秒    1   98.98    0.00    0.82    0.00    0.00    0.20    0.00    0.00    0.00    0.00
19时51分08秒    2   99.19    0.00    0.81    0.00    0.00    0.00    0.00    0.00    0.00    0.00
19时51分08秒    3   98.99    0.00    0.81    0.00    0.00    0.20    0.00    0.00    0.00    0.00

接在运行pidstat查看进程的情况：

# 间隔5s后输出一组数据，-u表示CPU指标
$ pidstat -u 5 1
Linux 5.8.0-48-generic (oceanstar) 	2021年10月21日 	_x86_64_	(4 CPU)

19时51分46秒   UID       PID    %usr %system  %guest   %wait    %CPU   CPU  Command
19时51分51秒     0        11    0.00    0.20    0.00    0.00    0.20     0  rcu_sched
19时51分51秒     0       679    0.20    0.00    0.00    0.00    0.20     1  vmtoolsd
19时51分51秒  1000      2187    0.80    4.38    0.00    0.60    5.18     3  Xorg
19时51分51秒  1000      2318    0.40    0.80    0.00    1.99    1.20     3  gnome-shell
19时51分51秒  1000      2659    0.60    3.59    0.00    0.00    4.18     0  gnome-terminal-
19时51分51秒     0     10198   23.90    0.00    0.00   75.90   23.90     1  stress
19时51分51秒     0     10199   23.90    0.20    0.00   76.10   24.10     0  stress
19时51分51秒     0     10200   23.51    0.40    0.00   75.70   23.90     0  stress
19时51分51秒     0     10201   23.51    0.20    0.00   75.90   23.71     2  stress
19时51分51秒     0     10202   25.30    0.40    0.00   74.30   25.70     3  stress
19时51分51秒     0     10203   31.08    0.20    0.00   68.33   31.27     1  stress
19时51分51秒     0     10204   22.71    0.00    0.00   76.69   22.71     1  stress
19时51分51秒     0     10205   23.11    0.80    0.00   76.10   23.90     0  stress
19时51分51秒     0     10206   28.49    0.40    0.00   70.72   28.88     3  stress
19时51分51秒     0     10207   22.31    0.20    0.00   77.49   22.51     1  stress
19时51分51秒     0     10208   22.51    0.40    0.00   77.49   22.91     3  stress
19时51分51秒     0     10209   23.90    0.20    0.00   76.10   24.10     3  stress
19时51分51秒     0     10210   22.71    0.40    0.00   76.89   23.11     2  stress
19时51分51秒     0     10211   22.31    0.00    0.00   77.49   22.31     2  stress
19时51分51秒     0     10212   22.11    0.40    0.00   77.29   22.51     0  stress
19时51分51秒     0     10213   22.71    0.00    0.00   77.29   22.71     2  stress
19时51分51秒  1000     10219    0.00    0.20    0.00    0.00    0.20     1  pidstat

可以看出，16个进程在争抢4个CPU，每个进程等待CPU的时间(%wait列)高达75%。这些超出CPU计算能力的进程，最终导致CPU过载

pidstat输出中没有%wait的问题：

• 因为centos默认的sysstat稍微有点老，源码或者RPM升级到11.5.5版本之后就可以看到了。
• 而unbuntu中的包一般都比较新，没有这个问题

mpstat无法观测的问题：

• 案例中是等待5s后输出1次结果就停止了，更好的做法是持续监控一段时间，比如持续观测20次： mpstat -P ALL 5 20

总结

平均负载提供了一个快速查看系统整体性能的手段，反映了整体的负载情况。但只看平均负载本身，我们并不能直接发现，到底是哪里出了问题。所以，在理解平均负载时，也要注意：

• 平均负载高有可能是CPU密集型进程导致的
• 平均负载高并不一定代码CPU使用率高，还可能是IO更繁忙了
• 当发现负载高的时候，你可以使用mpstat、pidstat等工具，辅助分析负载的来源

其他

mpstat

语法：

mpstat [-P {cpu|ALL}] [internal [count]]

其中，各参数含义如下：

参数	含义
-P {cpu l ALL}	表示监控哪个CPU， cpu在[0,cpu个数-1]中取值
internal	相邻的两次采样的间隔时间
count	采样的次数，count只能和delay一起使用

输出参数含义

参数	释义	从/proc/stat获得数据
CPU	处理器ID
%usr	在internal时间段里，用户态的CPU时间（%），不包含 nice值为负进程	usr/total*100
%nice	在internal时间段里，nice值为负进程的CPU时间（%）	nice/total*100
%sys	在internal时间段里，核心时间（%）	system/total*100
%iowait	在internal时间段里，硬盘IO等待时间（%）	iowait/total*100
%irq	在internal时间段里，硬中断时间（%）	irq/total*100
%soft	在internal时间段里，软中断时间（%）	softirq/total*100
%steal	显示虚拟机管理器在服务另一个虚拟处理器时虚拟CPU处在非自愿等待下花费时间的百分比	steal/total*100
%guest	显示运行虚拟处理器时CPU花费时间的百分比	guest/total*100
%gnice		gnice/total*100
%idle	在internal时间段里，CPU除去等待磁盘IO操作外的因为任何原因而空闲的时间闲置时间（%）	idle/total*100

CPU总的工作时间：

total_cur = user + system + nice + idle + iowait + irq + softirq

total_pre = pre_user + pre_system + pre_nice + pre_idle + pre_iowait + pre_irq + pre_softirq

user = user_cur – user_pre

total = total_cur - total_pre

其中_cur 表示当前值，_pre表示interval时间前的值。上表中的所有值可取到两位小数点。

实例

直接使用mpstat命令：

mpstat   #当mpstat不带参数时，输出为从系统启动以来的平均值。

mpstat -P ALL 5 2   #表示每5秒产生一个报告，总共产生2个

上图表示每5秒产生了2个关于处理器的统计数据报告，一共产生2个interval 的信息，然后再给出这2个interval的平均信息。默认时，输出是按照CPU 号排序。第一个行给出了从系统引导以来的所有活跃数据。接下来每行对应一个处理器的活跃状态。