1、平均负载基础
1.1、系统变慢时的排查方法
每次发现系统变慢时，我们通常做的第一件事，就是执行top或者uptime命令，来了解系统的负载情况。比如像下面这样，我在命令行里输入了uptime命令，系统也随即给出了结果。
]# uptime
19:24:53 up 12:05, 2 users, load average: 0.70, 0.01, 0.05
最后三个数字依次则是过去1分钟、5分钟、15分钟的平均负载(Load Average)。
1.2、什么是平均负载
1.2.1、平均负载理解
平均负载是单位时间内的CPU使用率吗;
上面的0.70，就代表CPU使用率是70%。其实不是
那如何理解平均负载: 平均负载是指单位时间内，系统处于"可运行状态"和"不可中断状态"的平均进程数，也就是平均活跃进程数;
或者简单理解"平均负载"是"单位时间内的活跃进程数";
平均负载与CPU 使用率并没有直接关系。
1.2.2、可运行状态
可运行状态进程:
指正在使用CPU 或者正在等待CPU 的进程，也就是我们ps命令看到处于R状态的进程
1.2.3、不可中断状态
不可中断进程:
系统中最常见的是等待硬件设备的I/o响应，通过 ps命令中看到D (Disk sleep)的进程。
例如︰当一个进程向磁盘读写数据时，为了保证数据的一致性，在得到磁盘回复前，它是不能被其他进程或者中断打断的，这个时候的进程就处于不可中断状态。如果此时的进程被打断了，就容易出现磁盘数据与进程数据不一致的问题;
所以，不可中断状态实际上是系统对进程和硬件设备的一种保护机制;
1.3、平均负载合理设定
1.3.1、平均负载分析
理想的状态是每个CPU上都刚好运行着一个进程，这样每个CPu都得到了充分利用。所以在评判平均负载时，首先你要知道系统有几个CPU通过top命令获取，或/proc/ cpuinfo
示例:假设现在在4、2、1核的CPU上，如果平均负载为2时，意味着什么？
在4个CPu的系统上，意味着CPU有50%的空闲;
在2个CPU的系统上，意味着所有的CPU都刚好被完全占用;
在1个CPu的系统上，意味着有一半的进程竞争不到CPU ;
1.3.2、平均负载三大指标
实际上，平均负载中的三个指标我们其实都需要关注。(就好比一天的天气要结合起来看)
1、1分钟、5分钟、15分钟的三个值基本相同，或者相差不大，那就说明系统负载很平稳;·1分钟的值小于15分钟的值，说明系统最近1分钟的负载在减少，而过去15分钟内却有很大的负载。
2、如果1分钟的值远大于15分钟的值，就说明最近1分钟的负载在增加，这种增加有可能只是临时性的，也有可能还会持续上升，所以就需要持续观察。
3、一旦1分钟的平均负载接近或超过了CPU的个数，就意味着系统正在发生过载的问题，这时就得分析问题，并要想办法优化了。
例如:
假设我们在有2个CPU系统上看到平均负载为2.73，6.90，12.98
-那么说明在过去1分钟内，系统有136% 的超载（2.73/2=136%)。而在过去5分钟内，有 345%的超载(6.90/2=345%)
-而在过去15分钟内，有649%的超载(12.98/2=649%)。但从整体趋势来看，系统的负载是在逐步的降低。
1.3.3、何时需要关注平均负载
1、当平均负载高于CPU 数量70%的时候，你就应该分析排查负载高的问题了。一旦负载过高，就可能导致进程响应变慢，进而影响服务的正常功能。
2、但70%这个数字并不是绝对的，最推荐的方法，还是把系统的平均负载监控起米，然后根据更多的历史数据，判断负载的变化趋势。
3、当发现负载有明显升高趋势时，比如说负载翻倍了，你再去做分析和调查。
1.3.4、平均负载与CPU使用率
在实际工作中，我们经常容易把平均负载和CPU使用率混淆，所以在这里，我也做一个区分;
既然平均负载代表的是活跃进程数，那平均负载高了，不就意味着CPU使用率高吗
我们回到平均负载的含义上来，平均负载是指单位时间内，处于可运行状态和不可中断状态的进程数;
所以，它不仅包括了正在使用CPU的进程，还包括等待CPU和等待I/O的进程;
而CPU使用率，是单位时间内CPU繁忙情况的统计，跟平均负载并不一定完全对应。
比如:
CPU密集型进程，使用大量CPU计算会导致平均负载升高，此时这两者是一致的
I/O密集型进程，等待I/O也会导致平均负载升高，但CPU使用率不一定很高;大量的CPU进程调度也会导致平均负载升高，此时的CPU使用率也会比较高;
2、实战-平均负载案例分析
2.1、使用到的工具
2.1.1、stress
curl -o stress-1.0.2-1.el7.rf.x86_64.rpm http://www.rpmfind.net/linux/dag/redhat/el7/en/x86_64/dag/RPMS/stress-1.0.2-1.el7.rf.x86_64.rpm
yum localinstall stress-1.0.2-1.el7.rf.x86_64.rpm
stress是Linux系统压力测试工具，这里我们用作异常进程模拟平均负载升高的场景
2.1.2、mpstat
yum install sysstat -y
mpstat是多核CPU性能分析工具，用来实时查看每个CPU的性能指标，及所有CPU的平均指标;
2.1.3、pidstat
yum install sysstat -y
pidstat是一个常用的进程性能分析工具，用来实时查看进程的CPU、Mem、I/0等性能指标;
2.2、示例1-stress-CPU密集型进程
2.2.1、第一个终端运行stress命令，模拟一个CPU使用率100%的场景
]# stress --cpu 1 --timeout 600
2.2.2、第二个终端运行uptime查看平均负载的变化情况
]# watch -d uptime
Every 2.0s: uptime Sat Apr 22 21:41:23 2023
21:41:23 up 14:22, 3 users, load average: 1.29, 0.48, 0.22
2.2.3、第三个终端运行mpstat查看CPU使用率的变化情况
#-P ALL 表示监控所有CPU，后面数字5表示间隔5秒后输出一组数据
]# mpstat -P ALL 5
Linux 3.10.0-1160.el7.x86_64 (192.168.10.35) 04/22/2023 _x86_64_ (1 CPU)
09:42:16 PM CPU %usr %nice %sys %iowait %irq %soft %steal %guest %gnice %idle
09:42:21 PM all 100.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00
09:42:21 PM 0 100.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00
# 单核CPU，所以只有一个ALL和0
2.2.4、查看是哪个程序占用的CPU较高
从终端二中可以看到，1分钟的平均负载会慢慢增加到1.00 ，而从终端三中还可以看到，正好有一个CPU的使用率为100%，但它的iowait为0。这说明，平均负载的升高正是由于CPU使用率为100%。那么，到底是哪个进程导致了CPU使用率为100%呢?可以使用pidstat来查询
]# pidstat -u 5 3
Linux 3.10.0-1160.el7.x86_64 (192.168.10.35) 04/22/2023 _x86_64_ (1 CPU)
09:51:53 PM UID PID %usr %system %guest %CPU CPU Command
09:51:58 PM 0 5376 100.00 0.00 0.00 100.00 0 stress
2.3、示例2-stress-I/O密集型进程
2.3.1、在第一个终端运行stress命令，但这次模拟I/o压力，即不停地执行sync
stress --io 1 --timeout 600s
2.3.2、在第二个终端运行uptime查看平均负载的变化情况
]# watch -d uptime
Every 2.0s: uptime Sun Apr 23 00:34:49 2023
00:34:49 up 17:15, 2 users, load average: 1.18, 0.30, 0.14
2.3.3、最后第三个终端运行mpstat查看CPU使用率的变化情况
# 显示所有CPU 的指标，并在间隔5秒输出一组数据
~]# mpstat -P ALL 5
Linux 3.10.0-1160.el7.x86_64 (192.168.10.35) 04/23/2023 _x86_64_ (1 CPU)
12:36:08 AM CPU %usr %nice %sys %iowait %irq %soft %steal %guest %gnice %idle
12:36:13 AM all 0.59 0.00 99.41 0.00 0.00 0.00 0.00 0.00 0.00 0.00
12:36:13 AM 0 0.59 0.00 99.41 0.00 0.00 0.00 0.00 0.00 0.00 0.00
# 会发现cpu的与内核打交道的sys占用非常高
2.3.4、导致iowait高，我们需要用pidstat来查询
~]# pidstat -u 5 1
Linux 3.10.0-1160.el7.x86_64 (192.168.10.35) 04/23/2023 _x86_64_ (1 CPU)
02:21:40 AM UID PID %usr %system %guest %CPU CPU Command
02:21:45 AM 0 6072 0.60 84.80 0.00 85.40 0 stress
2.4、示例3-stress-大量的进程
2.4.1、在第一个终端使用stress ，但这次模拟的是4个进程
stress -c 4 --timeout 600
2.4.2、由于系统只有1个CPU，明显比4个进程要少得多，因而，系统的cPu处于严重过载状态
]# watch -d uptime
Every 2.0s: uptime Sun Apr 23 02:24:37 2023
02:24:37 up 19:05, 3 users, load average: 3.16, 1.62, 0.68
2.4.3、通过pidstat查询是哪个进程的过载
最后通过pidstat查询进程的情况∶可以看出4个进程在争抢1个CPU 每个进程等待CPU的时间（也就是代码块中的 %wait列)高达75%。这些超出CPU计算能力的进程，最终导致CPU过载。
]# pidstat -u 5 1
Linux 3.10.0-1160.el7.x86_64 (192.168.10.35) 04/23/2023 _x86_64_ (1 CPU)
02:25:41 AM UID PID %usr %system %guest %CPU CPU Command
02:25:46 AM 0 6077 25.15 0.00 0.00 25.15 0 stress
02:25:46 AM 0 6078 24.75 0.00 0.00 24.75 0 stress
02:25:46 AM 0 6079 24.95 0.00 0.00 24.95 0 stress
02:25:46 AM 0 6080 24.75 0.00 0.00 24.75 0 stress
3、总结
分析完这三个案例，我再来归纳一下平均负载与CPU平均负载提供了一个快速查看系统整体性能的手段，反映了整体的负载情况。
但只有平均贝载本身，我们并不能直接发现，到底是哪里出现了瓶颈。所以，在理解平均负载时，
也要注意:
1、平均负载高有可能是CPU密集型进程导致的;
2、平均负载高并不一定代表CPU使用率高，还有可能是IO更繁忙了;
当发现负载高的时候，你可以使用mpstat、 pidstat等工具，辅助分析负载的来源
浙公网安备 33010602011771号