Linux 性能优化 - 平均负载
如何理解平均负载
定义
平均负载是指单位时间内，系统处于可运行状态和不可中断状态的平均进程数 ，也就是平均活跃进程数，它和 CPU 使用率并没有直接关系。
运行状态的进程，是指正在使用 CPU 或者正在等待 CPU 的进程，也就是我们常用 ps 命令看到的，处于 R 状态（Running 或 Runnable）的进程。
不可中断状态的进程则是正处于内核态关键流程中的进程，并且这些流程是不可打断的，比如最常见的是等待硬件设备的 I/O 响应，也就是我们在 ps 命令中看到的 D 状态（Uninterruptible Sleep，也称为 Disk Sleep）的进程。
比如，当一个进程向磁盘读写数据时，为了保证数据的一致性，在得到磁盘回复前，它是不能被其他进程或者中断打断的，这个时候的进程就处于不可中断状态。如果此时的进程被打断了，就容易出现磁盘数据与进程数据不一致的问题。不可中断状态实际上是系统对进程和硬件设备的一种保护机制。
简单理解，平均负载其实就是平均活跃进程数。平均活跃进程数，直观上的理解就是单位时间内的活跃进程数。
案例
查看平均负载可以使用 top 或者 uptime 命令
$ uptime
02:34:03 up 2 days, 20:14, 1 user, load average: 0.63, 0.83, 0.88
依次是过去 1 分钟、5 分钟、15 分钟的平均负载（Load Average）
当平均负载为 2 时，意味着什么呢？
- 在只有 2 个 CPU 的系统上，意味着所有的 CPU 都刚好被完全占用。
- 在 4 个 CPU 的系统上，意味着 CPU 有 50% 的空闲。
- 而在只有 1 个 CPU 的系统中，则意味着有一半的进程竞争不到 CPU。
平均负载的合理值
平均负载最理想的情况是等于 CPU 个数，首先要知道系统有几个 CPU。可以通过 top 命令或者从文件 /proc/cpuinfo 中读取，比如：
$ grep 'model name' /proc/cpuinfo | wc -l
2
当平均负载比 CPU 个数大的时候，说明系统已经出现了过载。
假设在1 个 cpu的系统上面，平均负载为 1.73，0.60，7.98，说明在过去 1 分钟内，系统有 73% 的超载，而在 15 分钟内，有 698% 的超载，从整体趋势来看，系统的负载在降低。
当平均负载高于 CPU 数量 70% 的时候，就应该分析排查负载高的问题了。一旦负载过高，就可能导致进程响应变慢，进而影响服务的正常功能。
推荐方法把系统的平均负载监控起来，根据更多的历史数据，判断负载的变化趋势。当发现负载有明显升高趋势时，进行分析和调查。
那些因素会导致平均负载的变化
平均负载是指单位时间内，处于可运行状态和不可中断状态的进程数。所以，它不仅包括了正在使用 CPU 的进程，还包括等待 CPU的进程 和等待 I/O 的进程。
平均负载和cpu使用率的关系
- CPU 密集型进程，使用大量 CPU 会导致平均负载升高，此时这两者是一致的；
- I/O 密集型进程，等待 I/O 也会导致平均负载升高，但 CPU 使用率不一定很高；
- 大量等待 CPU 的进程调度也会导致平均负载升高，此时的 CPU 使用率也会比较高。
案例分析
使用工具 stress、mpstat、pidstat
stress 是一个 Linux 系统压力测试工具，这里我们用作异常进程模拟平均负载升高的场景。
mpstat 是一个常用的多核 CPU 性能分析工具，用来实时查看每个 CPU 的性能指标，以及所有 CPU 的平均指标。
pidstat 是一个常用的进程性能分析工具，用来实时查看进程的 CPU、内存、I/O 以及上下文切换等性能指标。
安装
yum install stress sysstat
场景一：CPU 密集型进程
1、模拟一个 CPU 使用率 100% 的场景
$ stress --cpu 1 --timeout 600
2、监听平均负载的变化情况
# -d 参数表示高亮显示变化的区域
$ watch -d uptime
..., load average: 1.00, 0.75, 0.39
3、查看 CPU 使用率的变化情况
# -P ALL 表示监控所有CPU，后面数字5表示间隔5秒后输出一组数据
$ mpstat -P ALL 5
Linux 3.10.0-1127.19.1.el7.x86_64 (node1) 06/20/2023 _x86_64_ (2 CPU)
04:11:12 PM CPU %usr %nice %sys %iowait %irq %soft %steal %guest %gnice %idle
04:11:17 PM all 50.80 0.00 0.70 0.00 0.00 0.00 0.00 0.00 0.00 48.50
04:11:17 PM 0 100.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00
04:11:17 PM 1 1.60 0.00 1.40 0.00 0.00 0.00 0.00 0.00 0.00 96.99
CPU 的使用率为 100%，但它的 iowait 只有 0。这说明，平均负载的升高正是由于 CPU 使用率为 100% 。
4、使用 pidstat 查看进程的cpu使用率
# 间隔5秒后输出一组数据
$ pidstat -u 5 1
05:54:37 PM UID PID %usr %system %guest %wait %CPU CPU Command
05:54:42 PM 0 34118 99.80 0.00 0.00 0.00 99.80 1 stress
Average: UID PID %usr %system %guest %wait %CPU CPU Command
Average: 0 34118 99.80 0.00 0.00 0.00 99.80 - stress
从这里可以明显看到，stress 进程的 CPU 使用率为 100%。
场景二：I/O 密集型进程
1、模拟 I/O 压力
$ stress-ng -i 1 --hdd 1 --timeout 600
为什么不使用stress做测试
stress使用的是 sync() 系统调用，它的作用是刷新缓冲区内存到磁盘中。对于新安装的虚拟机，缓冲区可能比较小，无法产生大的IO压力，这样大部分就都是系统调用的消耗了。所以，你会看到只有系统CPU使用率升高。解决方法是使用stress的下一代stress-ng，它支持更丰富的选项，比如 stress-ng -i 1 --hdd 1 --timeout 600（–hdd表示读写临时文件）。Centos7.x stress-ng的安装与使用
https://youle.zhipin.com/articles/ac080b5ef91d0493qxB72tu6Eg~~.html
2、监听平均负载的变化情况
$ watch -d uptime
..., load average: 1.58, 1.16, 0.50
3、查看 CPU 使用率的变化情况
$ mpstat -P ALL 5
Linux 3.10.0-1127.19.1.el7.x86_64 (node1) 06/20/2023 _x86_64_ (2 CPU)
05:27:00 PM CPU %usr %nice %sys %iowait %irq %soft %steal %guest %gnice %idle
05:27:05 PM all 1.22 0.00 14.49 74.06 0.00 0.41 0.00 0.00 0.00 9.83
05:27:05 PM 0 1.43 0.00 9.41 85.07 0.00 0.82 0.00 0.00 0.00 3.27
05:27:05 PM 1 0.80 0.00 19.44 63.13 0.00 0.20 0.00 0.00 0.00 16.43
CPU 使用率升高到了 14.49，而 iowait 高达 74.06%。这说明，平均负载的升高是由于 iowait 的升高。
4、使用 pidstat 查看进程的cpu使用率
# 间隔5秒后输出一组数据
$ pidstat -u 5 1
05:49:28 PM UID PID %usr %system %guest %wait %CPU CPU Command
05:49:33 PM 0 32992 0.20 19.96 0.00 1.00 20.16 1 stress-ng-hdd
Average: UID PID %usr %system %guest %wait %CPU CPU Command
Average: 0 32992 0.20 19.96 0.00 1.00 20.16 - stress-ng-hdd
可以使用 -d 参数，显示各个进程的IO使用情况
$ pidstat -d 5 1
05:49:12 PM UID PID kB_rd/s kB_wr/s kB_ccwr/s iodelay Command
05:49:17 PM 0 32992 0.00 175090.84 0.00 404 stress-ng-hdd
Average: UID PID kB_rd/s kB_wr/s kB_ccwr/s iodelay Command
Average: 0 32992 0.00 175090.84 0.00 404 stress-ng-hdd
可以发现，还是 stress 进程导致的。
场景三：大量进程的场景
当系统中运行进程超出 CPU 运行能力时，就会出现等待 CPU 的进程。
1、模拟8个进程
$ stress -c 8 --timeout 600
2、监听平均负载的变化情况
$ uptime
10:35:49 up 442 days, 15:23, 3 users, load average: 7.87, 3.96, 1.59
3、查看 CPU 使用率的变化情况
$ pidstat -u 5 1
Linux 3.10.0-1127.19.1.el7.x86_64 (node1) 06/21/2023 _x86_64_ (2 CPU)
10:36:28 AM UID PID %usr %system %guest %wait %CPU CPU Command
10:36:33 AM 0 1045 0.20 0.00 0.00 1.00 0.20 0 barad_agent
10:36:33 AM 0 1046 0.20 0.80 0.00 0.00 1.00 0 barad_agent
10:36:33 AM 0 34827 0.20 0.20 0.00 0.00 0.40 0 YDService
10:36:33 AM 0 50456 24.70 0.00 0.00 75.50 24.70 1 stress
10:36:33 AM 0 50457 24.90 0.00 0.00 75.10 24.90 1 stress
10:36:33 AM 0 50458 24.50 0.00 0.00 74.70 24.50 1 stress
10:36:33 AM 0 50459 24.70 0.00 0.00 75.50 24.70 0 stress
10:36:33 AM 0 50460 24.70 0.00 0.00 75.50 24.70 0 stress
10:36:33 AM 0 50461 24.70 0.00 0.00 75.50 24.70 0 stress
10:36:33 AM 0 50462 24.30 0.00 0.00 74.90 24.30 0 stress
10:36:33 AM 0 50463 24.70 0.00 0.00 75.10 24.70 1 stress
10:36:33 AM 0 50648 0.00 0.20 0.00 0.00 0.20 0 pidstat
可以看出，8 个进程在争抢 2 个 CPU，每个进程等待 CPU 的时间（也就是代码块中的 %wait 列）高达 75%。这些超出 CPU 计算能力的进程，最终导致 CPU 过载。
总结
1、平均负载是指单位时间内，系统处于可运行状态和不可中断状态的平均进程数 ，也就是平均活跃进程数，它和 CPU 使用率并没有直接关系。
2、平均活跃进程数包括正在使用 CPU 的进程、 等待 CPU的进程 和 等待 I/O 的进程。它们都会导致平均负载指标的变化。