到底怎么理解“平均负载” 笔记

uptime 介绍

平均负载可以通过linux的 uptime命令查看首先，我们介绍一下uptime命令的输出内容

$ uptime
 16:43:48 up 30 days, 17:36,  2 users,  load average: 0.03, 0.03, 0.05

16:43:48: 当前时间
up 30 days, 17:36：系统运行的时间
2 users：当前系统登录用户数
load average: 0.03, 0.03, 0.05：分别是一分钟，五分钟，15分钟的平均负载

首先我们可以看到过去一分钟平均负载为0.03，有人会认为这个不就是单位时间内的CPU使用率吗？上面的0.03就代表cpu的使用率为3%，其实并不是的

平均负载介绍

平均负载是指定时间单位内，系统处于 可运行状态 和 不可中断状态 的平均进程数，也就是平均活跃进程数，它和CPU使用率并没有直接性关系，比如：在单核CPU情况下，也会出现uptime返回值为2情况，难道CPU使用量200%吗？其实不是的

• 可运行状态：正在使用CPU或者正在等待CPU的进程，也就是我们常用的ps命令看到，处于R状态（Running或Runnable）的进程

• 不可中断状态 ：正在处于内核关键流程中的进程，并且这些进程不可打断，比如等待硬件的I/O响应，也就是我们在ps中看到处于D状态（Uninterruptible Sleep，也称为 Disk Sleep）的进程

比如当进程想磁盘读写数据时，为了保证数据的一致性，在得到磁盘回复前，它是不能被其他进程或者中断打断的，不可中断状态实际上是系统对进程和硬件设备的一种保护机制

平均负载为多少时候合理

查看cpu核数

$ grep "model name" /proc/cpuinfo  | wc -l
1

平均负载最理想的情况就是等于CPU核数

问题：平均负载三个数值到底该参考哪个一个：
回答：三个不通时间间隔的平均值，提供了 系统负载趋势 的数据来源，让我们能更全面的，好比分析一个地区的季节，需要早上，中午，晚上分别知道温度，才可以判断季节

例子：

• 如果1分钟，5分钟，15分钟的三个值基本相同，或者相差不大，那么说明当前系统平均负载很平稳
• 但如果1分钟的值远低于15分钟的值，说明系统1分钟的负载在减少，而过去15分钟内却很大的负载
• 返回来，如果1分钟的远高于15分钟的值，代表最近1分钟的负载在增加，可能是临时性，也可能是持续性增加下去，需要持续观察，一点1分钟的平均负载超过了CPU核数，意味着存在过载问题，这时候得分析哪里导致过载

在分析系统平均负载的时候，推荐把平均负载监控起来，这样可以获取更多的历史数据，能跟清晰的分析系统负载升高或者降低的原因

平均负载与CPU使用率

平均负载：单位时间内处于 可运行状态 和 不可中断状态 的进程数

CPU使用率：单位时间内CPU繁忙情况的统计

所以CPU使用率和平均负载不一定是完全对应的

比如：

• CPU密集型进程，使用CPU会导致平均和CPU使用率同时升高
• I/O密集型进程，等待I/O也会导致平均负载升高，但是CPU使用率不一样升高
• 大量等待CPU的进程调度也会导致平均负载升高，此时的CPU使用率也会比较高，才会导致CPU进程等待调度

案例

机器配置：2C，8G内存
安装包：stress，stress-ng，sysstat
操作用户：root

• sysstat：linux性能分析工具
• stress：linux系统压力测试工具

场景一：CPU密集型进程

开启三个终端监控主机状态

1. 首先我们模拟CPU使用率100%的场景

stress --cpu 1 --timeout 600

2. 第二个终端执行uptime查看负载

watch -n 2 uptime
Every 2.0s: uptime                                                             Thu Dec  5 17:33:21 2019

 17:33:21 up 26 min,  6 users,  load average: 0.82, 0.44, 0.25

平均

3. 第三个终端执行mstat命令监控cpu使用率

# mpstat -P ALL 1
Linux 3.10.0-693.el7.x86_64 (localhost)     2019年12月05日     _x86_64_    (2 CPU)

17时33分51秒  CPU    %usr   %nice    %sys %iowait    %irq   %soft  %steal  %guest  %gnice   %idle
17时33分52秒  all   50.00    0.00    0.00    0.00    0.00    0.00    0.00    0.00    0.00   50.00
17时33分52秒    0  100.00    0.00    0.00    0.00    0.00    0.00    0.00    0.00    0.00    0.00
17时33分52秒    1    0.00    0.00    0.00    0.00    0.00    0.00    0.00    0.00    0.00  100.00

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

1. 首先运行stress-ng命令，模拟I/O压力

stress-ng -i 1 --hdd 1 --timeout 600

2. 监控uptime变化

watch -n 1 uptime
 17:57:20 up 30 days, 18:49,  4 users,  load average: 3.14, 1.99, 1.01

3. 用mpstat命令监控cpu的iowait

mpstat -P ALL 1
17时56分56秒  CPU    %usr   %nice    %sys %iowait    %irq   %soft  %steal  %guest  %gnice   %idle
17时56分57秒  all    0.00    0.00    2.02   97.98    0.00    0.00    0.00    0.00    0.00    0.00
17时56分57秒    0    0.00    0.00    2.02   97.98    0.00    0.00    0.00    0.00    0.00    0.00

4. 通过pidstat查看导致iowait高的进程

 pidstat -d 1
Linux 3.10.0-693.2.2.el7.x86_64 (iz2zeab8t820b32tt9i96gz)   2019年12月05日     _x86_64_    (1 CPU)

18时00分34秒   UID       PID   kB_rd/s   kB_wr/s kB_ccwr/s  Command
18时00分35秒     0       257      0.00  84480.85      0.00  jbd2/vda1-8
18时00分35秒     0      3865      0.00 115272.34      0.00  stress-ng-hdd

平均时间:   UID       PID   kB_rd/s   kB_wr/s kB_ccwr/s  Command
平均时间:     0       257      0.00  84480.85      0.00  jbd2/vda1-8
平均时间:     0      3865      0.00 115272.34      0.00  stress-ng-hdd

可以看出只有stress-ng-hdd 进程io操作高

场景三：大量进程的场景

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

1. 使用stress模拟8个进程

$ stress -c 4 --timeout 600

2. 使用uptime监控负载

watch -n 1 uptime
Every 1.0s: uptime                                                             Thu Dec  5 18:15:48 2019

 18:15:48 up 30 days, 19:08,  4 users,  load average: 4.41, 1.71, 1.01

3. 使用pidstat查找占用cpu进程

pidstat 需要升级到11.5.5以上，才有wait内容，这里的wait是：等待运行时任务花费的CPU百分比

[root@iz2zeab8t820b32tt9i96gz ~]# pidstat -u 1  2
Linux 3.10.0-693.2.2.el7.x86_64 (iz2zeab8t820b32tt9i96gz)   2019年12月05日     _x86_64_    (1 CPU)

18时22分59秒   UID       PID    %usr %system  %guest   %wait    %CPU   CPU  Command
18时23分00秒     0       781    0.00    0.98    0.00    0.98    0.98     0  aliyun-service
18时23分00秒     0      4218   24.51    0.00    0.00   74.51   24.51     0  stress
18时23分00秒     0      4219   24.51    0.00    0.00   73.53   24.51     0  stress
18时23分00秒     0      4220   24.51    0.00    0.00   78.43   24.51     0  stress
18时23分00秒     0      4221   24.51    0.00    0.00   73.53   24.51     0  stress

18时23分00秒   UID       PID    %usr %system  %guest   %wait    %CPU   CPU  Command
18时23分01秒     0      4218   25.00    0.00    0.00   76.00   25.00     0  stress
18时23分01秒     0      4219   25.00    0.00    0.00   75.00   25.00     0  stress
18时23分01秒     0      4220   25.00    0.00    0.00   75.00   25.00     0  stress
18时23分01秒     0      4221   25.00    0.00    0.00   76.00   25.00     0  stress

平均时间:   UID       PID    %usr %system  %guest   %wait    %CPU   CPU  Command
平均时间:     0       781    0.00    0.50    0.00    0.50    0.50     -  aliyun-service
平均时间:     0      4218   24.75    0.00    0.00   75.25   24.75     -  stress
平均时间:     0      4219   24.75    0.00    0.00   74.26   24.75     -  stress
平均时间:     0      4220   24.75    0.00    0.00   76.73   24.75     -  stress
平均时间:     0      4221   24.75    0.00    0.00   74.75   24.75     -  stress

可以明显看到有四个stress进程正在抢占cpu

总结

• 平均负载高可能是CPU密集型进程导致的；
• 平均负载高不一定是CPU使用率高导致的，还可能是I/O更繁忙导致iowait导致的
• 当发现负载高的时候，你可以使用mpstat，pidstat 工具分析
• 注意：tcp和pidstat中现实的wait代表意思不同，前者是：等待I / O完成的时间（针对io密集场景），后者是：等待运行时任务花费的CPU百分比（针对大量进程场景）

推荐命令

htop看负载，因为它更直接（在F2配置中勾选所有开关项，打开颜色区分功能），不同的负载会用不同的颜色标识。比如cpu密集型的应用，它的负载颜色是绿色偏高，iowait的操作，它的负载颜色是红色偏高等等，根据这些指标再用htop的sort就很容易定位到有问题的进程。还有个更好用的atop命令，好像是基于sar的统计生成的报告，直接就把有问题的进程标红了，更直观