一篇了解 Linux 平均负载的文章，带有故障排除工具！

ntkadmins 主要 09-09 775 0

一篇了解 Linux 平均负载的文章，带有故障排除工具！
什么是平均负载
平均负载对我们来说可能是熟悉和陌生，但是我们问什么是平均负载，但大多数人回答说平均负载不是单位时间的CPU使用率？事实上，情况并非如此。如果可以，您可以管理正常运行时间以了解有关平均负载的更多信息。

简单的说，平均负载是指单位时间内系统处于可运行状态和不可中断状态的平均进程数，即平均活动进程数，与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和等待。输入输出过程。

CPU使用率是单位时间内CPU繁忙度的统计数据，并不一定与平均负载相对应。例如：

CPU密集型进程，使用大量CPU会导致平均负载增加，此时两者是一样的
I/O 密集型进程，等待 I/O 也会增加平均负载，但 CPU 使用率不一定高
大量等待CPU的进程调度也会导致平均负载增加，此时CPU使用率会很高

平均负载情况

这里需要安装几个工具sysstat,stress,stress-ng

这里Centos的sysstat版本会比较老，最好升级到最新版本。手动rpm安装或源码安装

场景一，CPU 密集型

1. 运行一个stress命令来模拟一个100%的CPU使用场景

$压力--cpu1--timeout600

2.打开第二个终端，uptime查看平均负载变化

$观看-d 正常运行时间
09：40：35向上 80天，18：</span >41,2用户，负载平均值：1.62 , 1.10, 0.87

3.打开第三个终端，mpstat查看CPU使用率的变化

$mpstat-PALL520< /跨度>
10：06：37AM CPU %usr %nice %sys< /span>%iowait%irq%soft</span > %steal %guest %gnice class="hljs-string">%idle
10：06：42AM全部 31.50 0. 00 0.35 0. 00 0.00 0.000。00 0.00 0.00< /span> 68.15
10：06：42 AM  0 1.20 0。 00 0.80 0. 00 0.00 0.00 0。00  0。</spa n>00 0.00 98.00
10：06：42 AM  1 7.21 0。 00 0.40 0. 00 0.00 0.00 0。00  0。</spa n>00 0.00 92.38
10：06:42 AM 2 100.00 0.00< /span> 0.00 0.00 0。00 0< /span>.00 0.00 0.00 0。< /span>00 0.00
10：06：42 AM  3 17.43 0。 00 0.20 0. 00 0.00 0.00 0。00  0。</spa n>00 0.00 82.36
# -P ALL 表示监控CPU，间隔数字5 表示间隔5秒输出一次数据

从第二个终端可以看到，1分钟平均使用量增加到1.62，从第三个终端我们可以看到一个CPU使用率100%，但iowait为0，说明平均使用率的正式版本由CPU使用100%

那我们查看是那个过程导致了CPU使用率我们100%呢？可以使用pidstat来查看：

#每5秒输出一次数据
$ pidstat -u 5 1 
10:08:41 AM UID PID %usr %system %guest %wait %CPU CPU 命令
10:08:46 AM 0 1 0.20 0.00 0.00 0.00 0.20 0 systemd
10:08:46 AM 0 599 0.00 1.00 0.00 0.20 1.00 0 systemd-journal
10:08:46 AM 0 1043 0.60 0.00 0.00 0.00 0.60 0 rsyslogd
10:08:46 AM 0 6863 100.00 0.00 0.00 0.00 100.00 3 压力
10:08:46 AM 0 7303 0.20 0.20 0.00 0.00 0.40 2 pidstat

从这里我们看到的是压力过程导致的。

场景二、I/O密集型剧情

1、我们使用stress-ng命令，但我们模拟I/O压力，既继续执行同步：

#--hdd表示读写临时文件
#-i 生成几个worker循环调用sync()产生io压力
$ stress-ng -i  4 --hdd 1 --timeout 600

2、开启第二个终端运行uptime查看平均使用情况

$ watch -d 正常运行时间
10：30：57 up  98 天， 19：</span >39, 3 用户， 负载 平均值： 1.71, 0.75,< /span> 0.69

3、开启第三个终端运行mpstat查看CPU使用率

$ mpstat -P ALL 5 20< /跨度>
10：32:09 AM CPU %usr %nice %sys % iowait %irq %soft %steal< /span> %guest %gnice %idle</span >
10：32：14 AM 全部 6.80 0. 00 33.75 26.16 0。00  0.39 0 .00 0.00 0 .00 32.90
10：32：14 AM  0 4.03 0。 00 69.57 19.91 0.00 <spanclass="hljs-number">0 .00 0< span class="hljs-number">.00 0.00 0。 00 6.49
10：32：14 AM  1 25.32 0。 00 9.49 0.00 0 .00 0。 95 0.00 0. 00 0.00 64.24</span >
10：32：14 AM  2 0。24 0.00 10.87 63.04 0 .00 0。 48 0.00 0.00 0.00  25.36
10：32：14 AM  3 1.42 0。 00 36.93 14.20 0。00  0.28 0 .00 0.00 0 .00 47.16

从这里可以看到，1分钟平均负载会逐渐增加到1.71，其中一个CPU的系统CPU使用率升到63.04。这说明，平均负载的升高是由于iowait升高。

那我们到底是哪个过程的导致呢？我们使用pidstat来查看：

$ pidstat -u 5 1
平均值： UID PID %usr %system %guest %wait %CPU CPU 命令
平均值： 0 1 0.00 0.19 0.00 0.00 0.19 - systemd</span >
平均值： 010 0.00 0.19 0.00 1.56 0.19 - rcu_sched</span >
平均值： 0 599 0.58 1.75 0.00 0.39 2.33 - systemd-journal< /跨度>
平均值： 0 1043 0.19 0.19 0.00 0.00 0.39 - rsyslogd</span >
平均值： 0 6934 0.00 1.56 0.00 1.17 1.56 - kworker/2： 0-events_power_efficient
平均值： 0 7383 0.00 0.39 0.00 0.78 0.39 - kworker/1： 0-events_power_efficient
平均值： 0 9411 0.00 0.19 0.00 0.58 0.19 - el7.elrepo.x86_64(k8s-m1)  07/11/2019 _x86_64__x86_64_< /span> span class="hljs-string">(4 CPU)

10:57:33AMUID class="hljs-string">PID %usr%system%guest%wait%CPUCPU Command
10:57:38AM0< span class="hljs-number">0 span class="hljs-number">10.200.000.00 0.00 0.20< /span> 1  systemd
10:57:38AM0< span class="hljs-number">0 span class="hljs-number">5990.000.990.000.200.99< /span>2  systemd-journal
10:57:38AM0< span class="hljs-number">0 span class="hljs-number">10430.600.200.00 0.00 0.79< /span> 1  rsyslogd
10:57:38AM0< span class="hljs-number">0 span class="hljs-number">1292751.590.000.00 48.21 51.59< /span> 0  压力
10:57:38AM0< span class="hljs-number">0 span class="hljs-number">1292844.640.000.00 54.96 44.64< /span> 0 压力
10:57:38 AM 0 < span class="hljs-number">12929 45.44 0.00 0.00 54.56 45.44 2  压力
10:57:38 AM 0 < span class="hljs-number">12930 45.44 0.00 0.00 54.37 45.44 2  压力
10:57:38 AM 0 < span class="hljs-number">12931 51.59 0.00 0.00 48.21 51.59 3  压力
10:57:38 AM 0 < span class="hljs-number">12932 48.41 0.00 0.00 51.19 48.41 1  压力
10:57:38 AM 0 < span class="hljs-number">12933 45.24 0.00 0.00 54.37 45.24< /span> 3 压力
10:57:38 AM 0 < span class="hljs-number">12934 48.81 0.00 0.00 50.99 48.81 1  压力
10:57:38 AM 0 < span class="hljs-number">13083 0.00 0.40 0.00 0.20 0.40 0  pidstat