linux 平均负载 load average 的含义

load average 的含义

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

一般的进程需要消耗 CPU、内存、磁盘I/O、网络I/O等资源，在这种情况下，平均负载就不是单独指的CPU使用情况。即内存、磁盘、网络等因素也可以影响系统的平均负载值。不过影响最大的是 CPU 使用率、CPU 等待和磁盘I/O。

一个机器的负载情况通常是通过 CPU 核数来判断的。当平均负载比 CPU 核数还大的时候，系统已经出现了过载。

如在单核处理器中，平均负载值为 1 或者小于 1 的时候，系统处理进程会非常轻松，即负载很低。当达到 3 的时候，就会显得很忙，达到 5 或者 8 的时候就不能很好的处理进程了（其中 5 和 8 目前还是个争议的阈值，为了保守起见，建议选择低的）。

查看load average 数据

下面几个命令都可以看到 load average

# top 
# uptime 
# w

截图如下：

top 命令:
[外链图片转存失败(img-dAH7LTps-1568527428654)(/uploads/linux_load/load01.png)]

uptime 命令:

w 命令:

这里的 load average 的三个值分别指系统在最后 1/5/15 分钟 的平均负载值。

根据经验：我们应该把重点放在5/15分钟的平均负载，因为 1 分钟的平均负载太频繁，一瞬间的高并发就会导致该值的大幅度改变。

平均负载与 CPU 使用率

在日常使用中，我们经常容易把平均负载和 CPU 使用率混淆，这里我们做下区分。

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

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

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

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

平均负载案例分析

机器是一个 16 核 CPU 的。

这里会用到 2 个工具，stress 和 sysstat。

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

sysstat 是一个 Linux 性能工具，用来监控和分析系统的性能，以下案例中会用到这个包的 2 个命令 mpstat 和 pidstat。

• mpstat 是一个常用的多核 CPU 性能分析工具，用来实时查看每个 CPU 的性能指标，以及所有 CPU 的平均指标。
• pidstat 是一个常用的进程性能分析工具，用来实时查看进程的 CPU、内存、I/O 以及上下文切换等性能指标。

场景1：CPU密集型进程

我们打开终端一运行 stree 命令，模拟一个 CPU 使用率 100% 的场景

[root@localhost ~]# stress --cpu 1 --timeout 600
stress: info: [5399] dispatching hogs: 1 cpu, 0 io, 0 vm, 0 hdd

我们打开终端二，查看 CPU 负载的上升状态

[root@localhost ~]# uptime
 01:50:42 up 1 day,  1:42,  3 users,  load average: 0.68, 0.22, 0.11
[root@localhost ~]# uptime
 01:50:45 up 1 day,  1:42,  3 users,  load average: 0.71, 0.23, 0.12
[root@localhost ~]# uptime
 01:51:10 up 1 day,  1:43,  3 users,  load average: 0.81, 0.29, 0.14
[root@localhost ~]# uptime
 01:54:58 up 1 day,  1:47,  4 users,  load average: 1.03, 0.68, 0.33

# 一段时间后，我们发现1分钟的平均 load 值超过了1，为啥？ 设备上还有些其他进程运行啊。

打开终端三，查看 CPU 使用状态

[root@localhost ~]# mpstat -P ALL 5
Linux 3.10.0-514.16.1.el7.x86_64 (localhost.localdomain)    11/24/2018  _x86_64_    (16 CPU)

01:53:08 AM  CPU    %usr   %nice    %sys %iowait    %irq   %soft  %steal  %guest  %gnice   %idle
01:53:13 AM  all    6.24    0.00    0.01    0.00    0.00    0.00    0.01    0.00    0.00   93.73
01:53:13 AM    0    0.00    0.00    0.00    0.00    0.00    0.00    0.20    0.00    0.00   99.80
01:53:13 AM    1    0.00    0.00    0.00    0.00    0.00    0.00    0.00    0.00    0.00  100.00
01:53:13 AM    2    0.20    0.00    0.00    0.00    0.00    0.00    0.00    0.00    0.00   99.80
01:53:13 AM    3    0.00    0.00    0.00    0.00    0.00    0.00    0.00    0.00    0.00  100.00
01:53:13 AM    4    0.00    0.00    0.20    0.00    0.00    0.00    0.00    0.00    0.00   99.80
01:53:13 AM    5    0.00    0.00    0.00    0.00    0.00    0.00    0.00    0.00    0.00  100.00
01:53:13 AM    6    0.00    0.00    0.20    0.00    0.00    0.00    0.00    0.00    0.00   99.80
01:53:13 AM    7    0.00    0.00    0.00    0.00    0.00    0.00    0.00    0.00    0.00  100.00
01:53:13 AM    8    0.20    0.00    0.00    0.00    0.00    0.00    0.00    0.00    0.00   99.80
01:53:13 AM    9    0.00    0.00    0.00    0.00    0.00    0.00    0.00    0.00    0.00  100.00
01:53:13 AM   10    0.00    0.00    0.00    0.00    0.00    0.00    0.00    0.00    0.00  100.00
01:53:13 AM   11    0.00    0.00    0.00    0.00    0.00    0.00    0.00    0.00    0.00  100.00
01:53:13 AM   12    0.00    0.00    0.00    0.00    0.00    0.00    0.00    0.00    0.00  100.00
01:53:13 AM   13    0.00    0.00    0.00    0.00    0.00    0.00    0.00    0.00    0.00  100.00
01:53:13 AM   14    0.00    0.00    0.00    0.00    0.00    0.00    0.00    0.00    0.00  100.00
01:53:13 AM   15  100.00    0.00    0.00    0.00    0.00    0.00    0.00    0.00    0.00    0.00

# 这里我们可以看到，在CPU15上 CPU的使用率一直处于100%状态，使用这个工具可以持续看到状态的变化。

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

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

[root@localhost ~]# pidstat -u 5 1
Linux 3.10.0-514.16.1.el7.x86_64 (localhost.localdomain)    11/24/2018  _x86_64_    (16 CPU)

02:00:20 AM   UID       PID    %usr %system  %guest    %CPU   CPU  Command
02:00:25 AM     0      8451  100.00    0.00    0.00  100.00     2  stress
02:00:25 AM     0      8456    0.00    0.20    0.00    0.20     3  pidstat
02:00:25 AM     0      8457    0.20    0.20    0.00    0.40    15  client

Average:      UID       PID    %usr %system  %guest    %CPU   CPU  Command
Average:        0      8451  100.00    0.00    0.00  100.00     -  stress
Average:        0      8456    0.00    0.20    0.00    0.20     -  pidstat
Average:        0      8457    0.20    0.20    0.00    0.40     -  client

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

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

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

打开终端一，执行 stress

[root@localhost ~]# stress -i 1 --timeout 3600
stress: info: [8817] dispatching hogs: 0 cpu, 1 io, 0 vm, 0 hdd

打开终端二

[root@localhost ~]# uptime
 02:02:36 up 1 day,  1:54,  4 users,  load average: 0.83, 0.85, 0.56
[root@localhost ~]# uptime
 02:05:27 up 1 day,  1:57,  4 users,  load average: 0.99, 0.92, 0.63

# 这里，也会看到，load会不断的升高

打开终端三

[root@localhost ~]# mpstat -P ALL 5
Linux 3.10.0-514.16.1.el7.x86_64 (localhost.localdomain)    11/24/2018  _x86_64_    (16 CPU)

Average:     CPU    %usr   %nice    %sys %iowait    %irq   %soft  %steal  %guest  %gnice   %idle
Average:     all    0.05    0.00    5.93    0.34    0.00    0.00    0.05    0.00    0.00   93.63
Average:       0    0.16    0.00    0.48    0.00    0.00    0.00    0.14    0.00    0.00   99.22
Average:       1    0.03    0.00    0.09    0.01    0.00    0.00    0.03    0.00    0.00   99.84
Average:       2    0.03    0.00    0.09    0.00    0.00    0.00    0.01    0.00    0.00   99.88
Average:       3    0.09    0.00    0.23    0.00    0.00    0.00    0.03    0.00    0.00   99.65
Average:       4    0.13    0.00    0.53    0.00    0.00    0.00    0.05    0.00    0.00   99.29
Average:       5    0.02    0.00    0.05    0.00    0.00    0.00    0.05    0.00    0.00   99.88
Average:       6    0.02    0.00    0.35    0.00    0.00    0.00    0.08    0.00    0.00   99.56
Average:       7    0.02    0.00    0.04    0.00    0.00    0.00    0.03    0.00    0.00   99.90
Average:       8    0.02    0.00    0.14    0.00    0.00    0.00    0.04    0.00    0.00   99.80
Average:       9    0.10    0.00    0.28    0.00    0.00    0.00    0.03    0.00    0.00   99.59
Average:      10    0.09    0.00    0.34    0.00    0.00    0.00    0.05    0.00    0.00   99.52
Average:      11    0.01    0.00    0.06    0.00    0.00    0.00    0.03    0.00    0.00   99.90
Average:      12    0.03    0.00   33.73    1.96    0.00    0.00    0.05    0.00    0.00   64.23
Average:      13    0.02    0.00    0.04    0.00    0.00    0.00    0.02    0.00    0.00   99.92
Average:      14    0.03    0.00    2.43    0.12    0.00    0.00    0.04    0.00    0.00   97.37
Average:      15    0.04    0.00   56.38    3.30    0.00    0.00    0.17    0.00    0.00   40.12

# 这里看到，CPU 的 use 使用不是很高，反而 sys 使用的比较高，分布在了 2 个 CPU 上，约等于 100%
# 同时可以看到 iowait 的值也升高了一些，由于我的设备全是 ssd 磁盘，所以这个 io 的性能可能会稍微好一些。

从以上操作中，我们看到 1 分钟的平均负载会慢慢的增加，其中一个 CPU 的系统 CPU 使用率提升到了 56 ，同时 iowait 也提升到了 3，这说明平均负载的升高是由于系统资源使用和 iowait 导致。

这里更新 sysstat 包的版本

[root@localhost ~]# wget http://pagesperso-orange.fr/sebastien.godard/sysstat-12.1.1-1.x86_64.rpm
[root@localhost ~]# rpm -Uvh sysstat-12.1.1-1.x86_64.rpm

那么到底是哪个进程，导致系统 CPU 使用率特别高，及 CPU 的等待 wait 情况

[root@localhost ~]# pidstat -u 5 1
Linux 3.10.0-514.16.1.el7.x86_64 (localhost.localdomain)    11/24/2018  _x86_64_    (16 CPU)

02:34:53 AM   UID       PID    %usr %system  %guest   %wait    %CPU   CPU  Command
02:34:58 AM     0       730    0.00    0.20    0.00    0.00    0.20    12  xfsaild/vda6
02:34:58 AM     0      1471    0.00    0.20    0.00    0.00    0.20    10  kworker/10:2
02:34:58 AM     0      3042    0.00    0.40    0.00    0.00    0.40     7  kworker/7:1H
02:34:58 AM     0     11617    0.00    1.59    0.00    0.00    1.59     2  kworker/u32:1
02:34:58 AM     0     15272    0.00   91.43    0.00    0.40   91.43     7  stress
02:34:58 AM     0     15273    0.00    0.20    0.00    0.00    0.20    14  kworker/u32:0
02:34:58 AM     0     15274    0.20    0.40    0.00    0.00    0.60     5  pidstat

# %wait：表示等待运行时任务占用 CPU 百分比。

通过以上的信息，可以很清晰的看到，是由于 stress 进程出现了大量的系统使用。

场景三：大量进程的场景

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

我们打开终端一：使用 stress 模拟 24 个进程

[root@localhost ~]# stress -c 24 --timeout 3600
stress: info: [11726] dispatching hogs: 24 cpu, 0 io, 0 vm, 0 hdd

打开终端二：看下当前的负载值

[root@localhost ~]# uptime
 02:20:36 up 1 day,  2:12,  4 users,  load average: 17.22, 5.98, 2.61
[root@localhost ~]# uptime
 02:20:52 up 1 day,  2:13,  4 users,  load average: 18.72, 6.86, 2.95
[root@localhost ~]# uptime
 02:24:03 up 1 day,  2:16,  4 users,  load average: 23.77, 14.94, 6.85

打开终端三：看下进程的资源使用信息

[root@localhost ~]# pidstat -u 5 1
Linux 3.10.0-514.16.1.el7.x86_64 (localhost.localdomain)    11/24/2018  _x86_64_    (16 CPU)

02:28:14 AM   UID       PID    %usr %system  %guest   %wait    %CPU   CPU  Command
02:28:19 AM     0        43    0.00    0.20    0.00    0.00    0.20     7  ksoftirqd/7
02:28:19 AM     0      2292    0.20    0.00    0.00    0.00    0.20    11  dstat
02:28:19 AM     0     11727   48.81    0.00    0.00   44.05   48.81     5  stress
02:28:19 AM     0     11728   44.64    0.00    0.00    0.00   44.64    12  stress
02:28:19 AM     0     11729   41.27    0.00    0.00   49.60   41.27    11  stress
02:28:19 AM     0     11730   46.03    0.00    0.00   41.27   46.03     2  stress
02:28:19 AM     0     11731   59.92    0.00    0.00   30.16   59.92    15  stress
02:28:19 AM     0     11732   47.62    0.00    0.00   25.60   47.62    13  stress
02:28:19 AM     0     11733   65.67    0.00    0.00   22.02   65.67     2  stress
02:28:19 AM     0     11734   41.67    0.00    0.00   50.40   41.67    10  stress
02:28:19 AM     0     11735   54.17    0.00    0.00   32.34   54.17    15  stress
02:28:19 AM     0     11736   42.06    0.00    0.00   50.20   42.06     6  stress
02:28:19 AM     0     11737   35.91    0.00    0.00   29.96   35.91     3  stress
02:28:19 AM     0     11738   50.20    0.00    0.00    5.16   50.20    10  stress
02:28:19 AM     0     11739   42.06    0.00    0.00   49.60   42.06     6  stress
02:28:19 AM     0     11740   58.73    0.00    0.00   34.92   58.73     4  stress
02:28:19 AM     0     11741   46.63    0.00    0.00   13.49   46.63     1  stress
02:28:19 AM     0     11742   43.45    0.00    0.00   50.79   43.45    14  stress
02:28:19 AM     0     11743   44.05    0.00    0.00   45.24   44.05     7  stress
02:28:19 AM     0     11744   56.55    0.00    0.00   12.70   56.55     0  stress
02:28:19 AM     0     11745   46.23    0.00    0.00   49.80   46.23     5  stress
02:28:19 AM     0     11746   49.40    0.00    0.00   41.27   49.40    11  stress
02:28:19 AM     0     11747   43.65    0.00    0.00   49.40   43.65    14  stress
02:28:19 AM     0     11748   59.33    0.00    0.00    0.99   59.33     8  stress
02:28:19 AM     0     11749   46.43    0.00    0.00   45.24   46.43     4  stress
02:28:19 AM     0     11750   51.19    0.00    0.00   24.60   51.19     9  stress
02:28:19 AM     0     14276    0.00    0.40    0.00    0.20    0.40    10  pidstat

我们发现，运行的 24 个 stress 进程，出现了资源争抢的问题，既然出现了资源争抢，就会出现等待时间 wait。

注意事项

1、iowait 不等于 cpu wait。

2、iowait 多少算高。

一般 iowait 达 30% 就算高了，需要关注。
使用：iostat -x 1 10
其中如果 %util 到 70%，那么磁盘IO 就很频繁了，需要重点关注。

参考文章

1、如何理解linux的平均负载？

---