什么是平均负载
平均负载可以对于我们来说及熟悉又陌生，但我们问平均负载是什么，但大部分人都回答说平均负载不就是单位时间内CPU使用率吗？其实并不是这样的，如果可以的话，可以 man uptime 来了解一下平均负载的详细信息。
简单的说平均负载是指单位时间内，系统处于可运行状态和不可中断状态的平均进程数，也就是说平均活跃进程数，它和CPU使用率并没有直接关系。这里解释一下可运行状态和不可中断这两个词。
文章图片
可运行状态：
指正在使用CPU或者正在等待CPU的进程，我们使用ps命令查看处于R状态的进程
不可中断状态：
进程则是正处于内核态关键流程中的进程，并且这些流程是不可中断的。例如：常见的等待硬件设备I/O的响应，也就是我们在ps命令查看处于D状态的进程
比如，当一个进程向磁盘读写数据时，为了保证数据的一致性，在得到磁盘回复前，它是不能被其他进程中断或者打断的，这个时候的进程处于不可中断状态，如果此时的进程被打断了，就容易出现磁盘数据和进程数据不一致的问题。
所以，不可中断状态实际上是系统进程和硬件设备的一种保护机制。
因此，你可以简单理解为，平均负载就是平均活跃进程数。平均活跃进程数，直观上的理解就是单位时间内的活跃进程数，但它实际上是活跃进程数的指数衰减平均值。既然是平均活跃进程数，那么理想状态，就是每个CPU上都刚好运行着一个进程，这样每个CPU都会得到充分的利用。例如平均负载为2时，意味着什么呢？
在只有2个CPU的系统上，意味着所有的CPU刚好被完全占用
在4个CPU的系统上，意味着CPU有50%的空闲
而在只有1个CPU的系统上，则意味着有一半的进程竞争不到CPU
平均负载和CPU使用率
现实工作中，我们经常容易把平均负载和CPU使用率混淆，所以在这里，我也做一个分区。
可能你会疑惑，既然平均负载代表的是活跃进程数，那平均负载高了，不就意味着CPU使用率高吗？
我们还是要回到平均负载的含义上来，平均负载是指单位时间内，处于可运行状态和不可中断状态的进程数，所以，它不仅包括了正常使用CPU的进程，还包括了等待CPU和等待I/O的进程。
而CPU使用率，是单位时间内CPU的繁忙情况的统计，跟平均负载并不一定完全对应，例如：
CPU密集型进程，使用大量CPU会导致平均负载升高，此时这两者是一致的
I/O密集型进程，等待I/O也会导致平均负载升高，但CPU使用率不一定很高
大量等待CPU的进程调度也会导致平均负载升高，此时的CPU使用率会很高
平均负载案例
这里我们需要安装几个工具sysstat、stress、stress-ng
这里Centos的sysstat版本会老一点，最好升级到最新版本。手动rpm安装或者源码安装
场景一、CPU密集型
1、运行一个stress命令，模拟一个CPU使用率100%场景
$ stress --cpu1--timeout600
2、开启第二个终端，uptime查看平均负载的变化情况
$ watch -d uptime
09:40:35up80days,18:41,2users, load average:1.62,1.10,0.87
3、开启第三个终端，mpstat 查看CPU使用率的变化情况
$ mpstat -P ALL520
10:06:37AM CPU %usr %nice %sys %iowait %irq %soft %steal %guest %gnice %idle
10:06:42AM all31.500.000.350.000.000.000.000.000.0068.15
10:06:42AM01.200.000.800.000.000.000.000.000.0098.00
10:06:42AM17.210.000.400.000.000.000.000.000.0092.38
10:06:42AM2100.000.000.000.000.000.000.000.000.000.00
10:06:42AM317.430.000.200.000.000.000.000.000.0082.36
# -P ALL 表示监控所有CPU，后面数字5 表示间隔5秒输出一次数据
从第二个终端可以看到，1分钟平均负载增加到1.62，从第三个终端我们可以看到有一个CPU使用率100%，但iowait为0，这说明平均负载的升高正式由CPU使用率为100%
那我们查看是那个进程导致了CPU使用率为100%呢？我们可以使用pidstat来查看：
#每5秒输出一次数据
$ pidstat -u 51
10:08:41AM UID PID %usr %system %guest %wait %CPU CPU Command
10:08:46AM010.200.000.000.000.200systemd
10:08:46AM05990.001.000.000.201.000systemd-journal
10:08:46AM010430.600.000.000.000.600rsyslogd
10:08:46AM06863100.000.000.000.00100.003stress
10:08:46AM073030.200.200.000.000.402pidstat
从这里我们可以看到是stress这个进程导致的。
场景二、I/O密集型进程
1、我们使用stress-ng命令，但这次模拟I/O压力，既不停执行sync:
#--hdd表示读写临时文件
#-i 生成几个worker循环调用sync()产生io压力
$ stress-ng -i 4--hdd1--timeout600
2、开启第二个终端运行uptime查看平均负载情况
$ watch -d uptime
10:30:57up98days,19:39,3users, load average:1.71,0.75,0.69
3、开启第三个终端运行mpstat查看CPU使用率
$ mpstat -P ALL520
10:32:09AM CPU %usr %nice %sys %iowait %irq %soft %steal %guest %gnice %idle
10:32:14AM all6.800.0033.7526.160.000.390.000.000.0032.90
10:32:14AM04.030.0069.5719.910.000.000.000.000.006.49
10:32:14AM125.320.009.490.000.000.950.000.000.0064.24
10:32:14AM20.240.0010.8763.040.000.480.000.000.0025.36
10:32:14AM31.420.0036.9314.200.000.280.000.000.0047.16
从这里可以看到，1分钟平均负载会慢慢增加到1.71，其中一个CPU的系统CPU使用率升到63.04。这说明，平均负载的升高是由于iowait升高。
那么我们到底是哪个进程导致的呢？我们使用pidstat来查看：
$ pidstat -u51
Average: UID PID %usr %system %guest %wait %CPU CPU Command
Average: 010.000.190.000.000.19- systemd
Average: 0100.000.190.001.560.19- rcu_sched
Average: 05990.581.750.000.392.33- systemd-journal
Average: 010430.190.190.000.000.39- rsyslogd
Average: 069340.001.560.001.171.56- kworker/2:0-events_power_efficient
Average: 073830.000.390.000.780.39- kworker/1:0-events_power_efficient
【linux负载工具,一文理解 Linux 平均负载，附排查工具】Average: 094110.000.190.000.580.19- kworker/0:0-events
Average: 096620.0097.670.000.1997.67- kworker/u8:0+flush-253:0
Average: 0107930.000.970.001.560.97- kworker/3:2-mm_percpu_wq
Average: 0110620.0021.790.000.1921.79- stress-ng-hdd
Average: 0110630.001.950.001.361.95- stress-ng-io
Average: 0110640.002.720.000.392.72- stress-ng-io
Average: 0110650.001.360.001.751.36- stress-ng-io
Average: 0110660.002.720.000.582.72- stress-ng-io
可以发现是stress-ng导致的
场景三、大量进程的场景
当系统中运行进程超出CPU运行能力时，就会出现等待CPU的进程。
比如：我们使用stress,但这次模拟8个进程：
$ stress -c8--timeout600
我们的系统只有4颗CPU，这时候要运行8个进程，是明显不够的，系统的CPU后严重过载,这时候负载值达到了4点多：
$ uptime
10:56:22up98days,20:05,3users, load average:4.52,2.82,2.67
接着我们运行pidstat来查看一下进程的情况：
$ pidstat -u51
Linux 5.0.5-1.el7.elrepo.x86_64 (k8s-m1)07/11/2019_x86_64_ (4CPU)
10:57:33AM UID PID %usr %system %guest %wait %CPU CPU Command
10:57:38AM010.200.000.000.000.201systemd
10:57:38AM05990.000.990.000.200.992systemd-journal
10:57:38AM010430.600.200.000.000.791rsyslogd
10:57:38AM01292751.590.000.0048.2151.590stress
10:57:38AM01292844.640.000.0054.9644.640stress
10:57:38AM01292945.440.000.0054.5645.442stress
10:57:38AM01293045.440.000.0054.3745.442stress
10:57:38AM01293151.590.000.0048.2151.593stress
10:57:38AM01293248.410.000.0051.1948.411stress
10:57:38AM01293345.240.000.0054.3745.243stress
10:57:38AM01293448.810.000.0050.9948.811stress
10:57:38AM0130830.000.400.000.200.400pidstat
可以看出，8个进程抢占4颗CPU，每个进程等到CPU时间(%wait)高达50%，这些都超出CPU计算能力的进程，最终导致CPU过载。
【编辑推荐】
【责任编辑：张燕妮 TEL：(010)68476606】
点赞 0
