1.怎样理解平均负载?

1.通过我们在查看当前系统的状态的时候,往往会采用top或者uptime命令进行查看。

[root@node01 ~]# uptime
 06:17:15 up 28 min,  3 users,  load average: 0.00, 0.01, 0.04

其中后面的三个数字表示:过去的1分钟、5分钟、15分钟内的平均负载。这三个不同时间间隔的平均值,其实给我们提供了,分析系统负载趋势的数据来源,让我们能更全面,更立体地理解目前的负载状态。

比如说:在一个单cpu系统中看到的平均负载为1.73、0.60、7.98,那么说明在过去的1分钟内,系统有73%的超载,在过去的15分钟内,有698%的超载,因而从整体趋势来看,系统的负载在降低。

平均负载:指的是单位时间内,系统处于可运行状态和不可中断状态的平均进程数,也就是是平均活跃进程数。

它和cpu的使用率没有直接的关系。

 

可运行状态的进程,是指正在使用cpu或着正在等待cpu的进程,也就是我们常用ps命令看到的,出入R状态(Ruing)或者(Runnable)的进程。

不可中断状态:指的是正在处于内核态关键流程中的进程,并且这些流程都是不可中断的,比如说最常见的是等待硬件设备I/O响应,也就是我们在ps命令中看到的D状态(Uninterruptible sleep,也称为Disk sleep)的进程。比如:当一个进程想磁盘读写数据时,为了保证数据的一致性,在得到磁盘回复前,它是不能被其他进程或这中断打断的,这个时候的进程处于不可中断状态,如果此时的进程被打断了,就容易出现磁盘数据与进程数据不一致的问题。所以,不可中断状态实际上是系统对进程和硬件设备的一种保护机制。

查看系统cpu的命令

[root@node01 ~]# grep 'model name' /proc/cpuinfo|wc -l
1

 

2.平均负载与CPU使用率

平均负载是指单位时间内,处于可运行状态和不可中断状态的进程数,所以它不仅包括了正在使用cpu的进程,还包括等待cpu和等待i/o的进程

而cpu使用率,是单位时间内cpu繁忙情况的统计,跟平均负载并不一定完全对应。

  • CPU 密集型进程,使用大量 CPU 会导致平均负载升高,此时这两者是一致的;
  • I/O 密集型进程,等待 I/O 也会导致平均负载升高,但 CPU 使用率不一定很高;
  • 大量等待 CPU 的进程调度也会导致平均负载升高,此时的 CPU 使用率也会比较高。

工具: iostat、mpstat、pidstat 

安装:

yum -y install stress  sysstat

stress 是一个 Linux 系统压力测试工具,这里我们用作异常进程模拟平均负载升高的场景

而 sysstat 包含了常用的 Linux 性能工具,用来监控和分析系统的性能。我们的案例会用到这个包的两个命令 mpstat 和 pidstat。

1.mpstat 是一个常用的多核 CPU 性能分析工具,用来实时查看每个 CPU 的性能指标,以及所有 CPU 的平均指标。
2.pidstat 是一个常用的进程性能分析工具,用来实时查看进程的 CPU、内存、I/O 以及上下文切换等性能指标

场景1:cpu密集型

这里预先开启三个回话窗口

session1 : 终端运行  stress  命令,模拟一个  CPU  使用率 100% 的场景

$ stress --cpu 1 --timeout 600

session2:在第二个终端运行 uptime 查看平均负载的变化情况

# -d 参数表示高亮显示变化的区域
$ watch -d uptime
...,  load average: 1.00, 0.75, 0.39

session3:运行 mpstat 查看 CPU 使用率的变化情况:

# -P ALL 表示监控所有CPU,后面数字5表示间隔5秒后输出一组数据

[root@node01 ~]# mpstat -P ALL 5
Linux 3.10.0-1160.24.1.el7.x86_64 (node01)     06/10/2021     _x86_64_    (1 CPU)

06:53:46 AM  CPU    %usr   %nice    %sys %iowait    %irq   %soft  %steal  %guest  %gnice   %idle
06:53:51 AM  all   99.80    0.00    0.20    0.00    0.00    0.00    0.00    0.00    0.00    0.00
06:53:51 AM    0   99.80    0.00    0.20    0.00    0.00    0.00    0.00    0.00    0.00    0.00

session4:到底是哪个进程导致了 CPU 使用率为 100% 呢?你可以使用 pidstat 来查询

[root@node01 ~]# pidstat -u 5 1     ##显示所有CPU的指标,并在间隔5秒输出一组数据
Linux 3.10.0-1160.24.1.el7.x86_64 (node01)     06/10/2021     _x86_64_    (1 CPU)

06:57:06 AM   UID       PID    %usr %system  %guest    %CPU   CPU  Command
06:57:11 AM     0        42    0.00    0.20    0.00    0.20     0  kworker/u256:1
06:57:11 AM     0      2211   98.41    0.20    0.00   98.61     0  stress
06:57:11 AM     0      2218    0.20    0.20    0.00    0.40     0  watch
06:57:11 AM     0      2238    0.00    0.20    0.00    0.20     0  pidstat

从这里可以明显看到,stress 进程的 CPU 使用率为 100%。

 

场景二:I/O密集型

session1:运行  stress  命令,但这次模拟  I/O  压力,即不停地执行  sync:

$ stress -i 1 --timeout 600

session2:运行 uptime 查看平均负载的变化情况:

$ watch -d uptime

session3:第三个终端运行 mpstat 查看 CPU 使用率的变化情况:

mpstat -P ALL 5 1   

session4;到底是哪个进程导致了 CPU 使用率为 100% 呢?你可以使用 pidstat 来查询

[root@node01 ~]# pidstat -u 5 1
Linux 3.10.0-1160.24.1.el7.x86_64 (node01)     06/10/2021     _x86_64_    (1 CPU)

07:06:42 AM   UID       PID    %usr %system  %guest    %CPU   CPU  Command
07:06:47 AM     0        42    0.00    8.33    0.00    8.33     0  kworker/u256:1
07:06:47 AM     0      2338    3.57   78.77    0.00   82.34     0  stress
07:06:47 AM     0      2339    0.20    0.20    0.00    0.40     0  watch
07:06:47 AM     0      2418    0.00    8.13    0.00    8.13     0  kworker/u256:0
07:06:47 AM     0      2523    0.00    0.20    0.00    0.20     0  pidstat

场景3:大量进程场景

当系统中运行进程超出 CPU 运行能力时,就会出现等待 CPU 的进程。

比如,我们还是使用 stress,但这次模拟的是 8 个进程:

session1:

$ stress -c 8 --timeout 600

session2:由于系统只有 21个 CPU,明显比 8 个进程要少得多,因而,系统的 CPU 处于严重过载状态,平均负载高达 7.97:

$ uptime
...,  load average: 7.97, 5.93, 3.02

session3:

[root@node01 ~]# mpstat -P ALL 5 1
Linux 3.10.0-1160.24.1.el7.x86_64 (node01)     06/10/2021     _x86_64_    (1 CPU)

07:15:26 AM  CPU    %usr   %nice    %sys %iowait    %irq   %soft  %steal  %guest  %gnice   %idle
07:15:31 AM  all  100.00    0.00    0.00    0.00    0.00    0.00    0.00    0.00    0.00    0.00
07:15:31 AM    0  100.00    0.00    0.00    0.00    0.00    0.00    0.00    0.00    0.00    0.00

session4:

[root@node01 ~]# pidstat -u 5 1
Linux 3.10.0-1160.24.1.el7.x86_64 (node01)     06/10/2021     _x86_64_    (1 CPU)

07:14:37 AM   UID       PID    %usr %system  %guest    %CPU   CPU  Command
07:14:42 AM     0      2581   12.18    0.00    0.00   12.18     0  stress
07:14:42 AM     0      2582   12.38    0.00    0.00   12.38     0  stress
07:14:42 AM     0      2583   12.38    0.00    0.00   12.38     0  stress
07:14:42 AM     0      2584   11.98    0.00    0.00   11.98     0  stress
07:14:42 AM     0      2585   11.98    0.00    0.00   11.98     0  stress
07:14:42 AM     0      2586   12.18    0.00    0.00   12.18     0  stress
07:14:42 AM     0      2587   12.18    0.00    0.00   12.18     0  stress
07:14:42 AM     0      2588   12.18    0.00    0.00   12.18     0  stress
07:14:42 AM     0      2589    0.00    0.20    0.00    0.20     0  watch

Average:      UID       PID    %usr %system  %guest    %CPU   CPU  Command
Average:        0      2581   12.18    0.00    0.00   12.18     -  stress
Average:        0      2582   12.38    0.00    0.00   12.38     -  stress
Average:        0      2583   12.38    0.00    0.00   12.38     -  stress
Average:        0      2584   11.98    0.00    0.00   11.98     -  stress
Average:        0      2585   11.98    0.00    0.00   11.98     -  stress
Average:        0      2586   12.18    0.00    0.00   12.18     -  stress
Average:        0      2587   12.18    0.00    0.00   12.18     -  stress
Average:        0      2588   12.18    0.00    0.00   12.18     -  stress
Average:        0      2589    0.00    0.20    0.00    0.20     -  watch

可以看出,8 个进程在争抢 1 个 CPU,每个进程等待 CPU 的时间(也就是代码块中的 %wait 列)高达 75%。这些超出 CPU 计算能力的进程,最终导致 CPU 过载。

 

上一篇:到底应该怎么理解“平均负载”?


下一篇:性能测试必备知识(4)- 使用 stress 和 sysstat 分析平均负载过高的场景