top、uptime命令执行后的平均负载如何理解

怎么理解平均负载

每当系统变慢的时候,我们下意识的就会想到使用top或者uptime命令来查看系统当前运行的状态,其中一个非常重要的指标便是平均负载,例如下面的一组数据

$ uptime
 10:35:11 up 9 min,  1 user,  load average: 0.03, 0.14, 0.13

前几列数据很简单,当前时间,系统运行时间,正在登陆的用户数,而最后的便是平均负载,显示的是1分钟、5分钟、15分钟的平均负载

那么到底如何理解平均负载呢?用man命令查看uptime的一些帮助信息

top、uptime命令执行后的平均负载如何理解_第1张图片

总是会有人理解为平均负载是单位时间内的CPU使用率,0.03表示单位时间内的CPU使用率是3%,但其实并不是这样的,上面的英文介绍也说了平均负载是可运行不可中断状态的平均进程数

  • 可运行状态:是指正在使用CPU或者正在等待CPU的进程,也就是ps命令看到的处于R状态的进程
  • 不可中断状态:是指正在处于内核态关键流程中的进程,并且这些进程是不可打断的,比如常见的等待硬件设备的IO操作,也就是ps命令看到的处于D状态的进程

当一个进程向磁盘读写数据的时候,为了保证数据的一致性,在得到磁盘恢复之前他是不能被其他进程或者中断打断的也就是处于不可中断状态,这其实也是一种保护机制

也就是说平均负载其实是平均活跃进程数,例如当平均负载为2时,如果是在只有2个CPU的系统上意味着所有的CPU都被占用,在4个CPU的系统上,意味着CPU有50%的空闲,在1个CPU的系统上意味着有一半的进程竞争不到CPU

那平均负载和CPU平均使用率之间有何差别呢?

平均负载的含义是处于运行状态和中断状态的平均进程数,所以包括了正在使用CPU的进程,等待CPU的进程以及等待IO的进程,而CPU平均使用率就是单位时间内CPU的繁忙情况

  • CPU密集型进程:使用大量的CPU会使平均负载升高,这时两者的含义大致相等
  • IO密集型进程:等待IO也会导致平均负载升高,但是CPU的使用率不一定升高
  • 大量等待CPU的进程也会导致平均负载升高,这时CPU的使用率也会比较高

平均负载为多少时合适

通过上面也可以知道,平均负载的值和CPU的个数息息相关,首先使用命令查看CPU的个数

$ grep 'model name' /proc/cpuinfo | wc -l
2

有了CPU的个数,通过平均负载的值与个数进行比较那么就可以判断当前系统是否过载

平均负载给了我们三个参考值,分别是1分钟、5分钟、15分钟的值,这其实是反应一个系统的负载情况的趋势

  • 如果三个数组基本相同或者相差不大,那么说明系统比较平稳的运行
  • 如果 1 分钟的值远小于 15 分钟的值,就说明系统最近 1 分钟的负载在减少,而过去
    15 分钟内却有很大的负载。
  • 如果 1 分钟的值远大于 15 分钟的值,就说明最近 1 分钟的负载在增加,这种
    增加有可能只是临时性的,也有可能还会持续增加下去,所以就需要持续观察。一旦 1
    分钟的平均负载接近或超过了 CPU 的个数,就意味着系统正在发生过载的问题,这时就
    得分析调查是哪里导致的问题,并要想办法优化了

假设我们在一个单 CPU 系统上看到平均负载为 1.73,0.60,7.98,那
么说明在过去 1 分钟内,系统有 73% 的超载,而在 15 分钟内,有 698% 的超载,从整体
趋势来看,系统的负载在降低

一般来说当平均负载超过CPU数据的70%的时候,就需要分析排查负载过高的问题了

平均负载案列分析

准备的环境是 Ubuntu 20.2 2CPU 4G内存,首先需要准备的是stress和sysstat这两个包

  • stress 是一个 Linux 系统压力测试工具,这里我们用作异常进程模拟平均负载升高的场
  • sysstat包含了常用的Linux性能工具,用来监控和分析系统的性能,本次案列会使用到mpstat和pidstat这两个工具,mpstat是一个常用的多核CPU性能分析工具,用来实时查看每个CPU的性能指标以及所有CPU的平均指标,pidstat是一个常用的进程性能分析工具,用来实时查看进程的CPU、内存、IO以及上下文切换等性能指标

场景一:CPU密集型进程

首先使用stress命令模拟一个CPU使用率到达100%的场景

gpw@gopuwe:~$ stress --cpu 1 --timeout 600

接着第二个终端运行uptime查看平均负载情况

# -d 参数表示高亮显示变化的区域
gpw@gopuwe: watch -d uptime

11:50:03 up  1:24,  3 users,  load average: 1.07, 0.79, 0.43

可以发现CPU的平均负载已经到1了,也就是有一个CPU过载

接着第三个终端运行mpstat查看每个CPU使用率的变化情况

# -P ALL 表示监控所有 CPU,后面数字 5 表示间隔 5 秒后输出一组数据
gpw@gopuwe:~$ mpstat -P ALL 5

top、uptime命令执行后的平均负载如何理解_第2张图片

可以看到有一个CPU的使用率为100%,但是它的iowait只有0,这说明平均负载的升高正是由于CPU的使用率为100%

那么最后需要定位是哪一个进程导致CPU的使用率为100%,可以使用pidstat来查询

# 间隔 5 秒后输出一组数据
gpw@gopuwe:~$ pidstat -u 5 1

image-20211128115510466

可以发现就是stress这个进程导致了CPU的使用率为100%

场景二:模拟IO密集型进程

gpw@gopuwe:~$ stress -i 1 --timeout 600

uptime下的结果

gpw@gopuwe:~$ uptime
 12:00:02 up  1:34,  3 users,  load average: 0.96, 0.80, 0.61

同样的使用mpstat监控每个CPU的运行状态可以看到iowait的数值比较大,然后使用pidstat定位出是哪一个进程的CPU占用比较大

场景三 大量进程的场景

使用stress模拟8个进程的情况,因为CPU是2个所以必然导致大量的进程处于等待状态,在这种情况下平均负载是高的

stress -c 8 --timeout 600

使用uptime查看系统的平均负载

gpw@gopuwe:~$ uptime
 22:47:16 up 12:21,  3 users,  load average: 7.13, 3.83, 1.70

meout 600


使用uptime查看系统的平均负载

```shell
gpw@gopuwe:~$ uptime
 22:47:16 up 12:21,  3 users,  load average: 7.13, 3.83, 1.70

top、uptime命令执行后的平均负载如何理解_第3张图片

你可能感兴趣的:(操作系统,数据结构,算法,数据库)