Linux 平均负载和CPU使用率的关系案例解说

平均负载和CPU使用率

我们知道：

• 平均负载是指单位时间内，处在可执行状态和不可中断睡眠状态的进程的平均数。也就是说，它包括了处在执行态，阻塞态和就绪态的进程。
• CPU使用率是指在单位时间内CPU处于非空闲状态的时间比，反映了CPU的繁忙程度。例如：单核CPU单位时间内非空闲态运行时间为0.8s，那么他的CPU使用率为80%；双核CPU单位时间内非空闲态运行时间分别为0.4s和0.6s，那么它的CPU使用率为（0.4+0.6）/2*100%=50%

我们再举个更生动的例子：
有一家银行，他只有一个业务窗口，每次只能接待一个人（单核CPU）。有一天一共有五个人来了，那么就会出现一人在办理手续，其余四人在等待的情况（CPU负载为5）
我们约定在业务窗口的那个人只有真正在办理业务才算是真正使用（CPU使用率）如下图

了解了负载与CPU使用率的关系之后，我们来聊聊什么情况下会导致负载上升以及平均负载和CPU使用率的关系

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

案例

本次案例，我会再现三种让平均负载升高的情况。这次案例运用到的工具有stress工具和sysstat工具，关于这两个工具的一些说明，在我的这篇文章里已经提到过，我就不再赘述了
Linux 系统性能分析命令和工具

本次案例的虚拟机配置

# 下载相关工具包
 yum install -y stsstat stress

场景1：CPU密集型进程（CPU使用率高）

#模拟cpu使用率为100%，持续时间为600s
stress --cpu 1 --timeout 600

#查看平均负载变化情况
uptime
... load average: 1.11, 0.59, 0.29

可以看到，在过去1分钟内，CPU的平均负载高达1.11，这说明cpu占有率已经超过100%
使用sysstat工具包中的mpstat查看cpu性能情况

mpstat -P ALL 5

可以看到，CPU的使用率已经为100%，而且他的iowait只有0.
这说明：平均负载的升高是由于CPU使用率为100%，也就是说CPU使用率的升高导致了平均负载的升高
我们用pidstat命令查看一下进程的性能情况，看看是哪个进程造成了如此高的CPU使用率

pidstat -u 5 1
UID  PID  %usr  %system  %guest  %wait  %CPU  CPU  Command
 0   2962  100.00  0.00   0.00   0.00   100.00  1   stress

就是刚开始我们所用的stress命令导致了这么一个情况的发生

场景二：I/O 密集型进程
我们首先使用stress工具来模拟IO压力，有时候大量的等待I/O线程也会导致负载升高，即不停的执行sync

-i： 产生n个进程 每个进程反复调用sync()，sync()用于将内存上的内容写到硬盘上
stress -i 1 --timeout 300

uptime
load average: 1.09, 0.54, 0.36

可以看到，过去1min之内的平均负载高达1.09
看一下CPU性能情况

mpstat -P  ALL 5

我们看到，图中的 iowait 为0，并没有出现我们认为的 Iowait 升高情况，但是sys升高了，这是为什么呢？
因为对于部分人（包括我）的虚拟机而言，使用的是 stress 中的sync()系统调用，作用是刷新缓冲区内存到磁盘中。而我们的虚拟机缓冲区可能比较小无法产生大的IO压力。这样大部分就都是系统调用的消耗了。

由此可见，大量的等待IO也会导致平均负载的升高，但是CPU使用率不一定升高

场景三：大量进程的场景
在这个场景中，我们模拟同时有8个进程。但是我们的CPU只有一个，剩下7个进程就会在等待CPU，与此同时我们的CPU处于严重过载的状态

产生8个进程 每个进程都反复不停的计算随机数的平方根
stress -c 8 --timeout 600

uptime
 load average: 7.44, 3.34, 1.47

由此可见，大量处在就绪态的进程也会导致平均负载的升高