“平均负载”的学习之路

Posted 2020-12-11 xiaowei123

在学习操作系统的时候，我们都知道一个进程的执行时需要CPU、资源等条件，当我们的系统有大量进程运行的时候，你会发现电脑变得比刚开机的时候慢很多，有时候很苦恼。有时候当我们刚把项目部署在服务器上的时候，没过多久系统就开始报警，提示我们系统资源不够啦~，需要你赶紧跑来处理呀，我扛不住了呀~，不然我就奔溃啦！此时，我们便会立马赶紧飞奔而来，赶紧赶紧一定要解决这个头疼的问题，不然明天我就要走人了，上有老下有小我还不想早早就滚人呀，QAQ（好惨的一个我啊！）这时，你想起来你在跟着倪鹏飞大大学习 Linux 性能优化那段艰辛的日子，回想起了他一把辛酸的教你还学不会的场景。。。

 

那时，你在命令行输入 uptime 命令，可爱的 Linux 系统给你回馈了信息。

[root@localhost ~]# uptime
 21:08:23 up  8:42,  4 users,  load average: 0.03, 0.14, 0.41

这时，你问倪大大这些信息是啥意思呀~，我看不懂啊o(╥﹏╥)o

倪大大说：没事我来告诉你：

21:08:23            // 当前时间

up  8:42,          // 系统运行时间 

4 users            // 正在登录用户数

load average: 0.03, 0.14, 0.41  //最后三个数字呢，依次则是过去 1 分钟、5 分钟、15 分钟的平均负载（LoadAverage）。

小白的我o(╥﹏╥)o问：倪大大，平均负载是什么东东呀 ~，是不是类似于一个平均数呀 ~

倪大大面带笑容：孺子可教也，没错，何为平均负载呢？让我们来看看官方手册上是如何说的。

DESCRIPTION
       uptime  gives  a  one line display of the following information.  The current time,
       how long the system has been running, how many users are currently logged  on,  and
       the system load averages for the past 1, 5, and 15 minutes.

       This is the same information contained in the header line displayed by w(1).

       System  load  averages  is  the  average  number  of processes that are either in a
       runnable or uninterruptable state.  A process in a runnable state is  either  using
       the  CPU  or waiting to use the CPU.  A process in uninterruptable state is waiting
       for some I/O access, eg waiting for disk.  The averages are taken  over  the  three
       time  intervals.  Load averages are not normalized for the number of CPUs in a sys‐
       tem, so a load average of 1 means a single CPU system is loaded all the time  while
       on a 4 CPU system it means it was idle 75% of the time.

看到了吧！其实平均负载是指单位时间内，系统处于可运行状态和不可中断状态的平均进程数，也就是平均活跃进程数，它和 CPU 使用率并没有直接关系。

小白的我带着无比的好奇心?(′???｀?)问问了：那什么是可运行状态和不可中断状态。

倪大大看了我一副热爱学习的样子，立马给我解释到：所谓可运行状态的进程，是指正在使用 CPU 或者正在等待 CPU 的进程，也就是我们常用 ps 命令看到的，处于 R 状态（Running 或 Runnable）的进程。而不可中断状态的进程则是正处于内核态关键流程中的进程，并且这些流程是不可打断的，比如最常见的是等待硬件设备的 I/O 响应，也就是我们在 ps 命令中看到的 D 状态（Uninterruptible Sleep，也称为 Disk Sleep）的进程。比如，当一个进程向磁盘读写数据时，为了保证数据的一致性，在得到磁盘回复前，它是不能被其他进程或者中断打断的，这个时候的进程就处于不可中断状态。如果此时的进程被打断了，就容易出现磁盘数据与进程数据不一致的问题。所以，不可中断状态实际上是系统对进程和硬件设备的一种保护机制。那我们可以看下我们系统有什么状态：

[root@localhost ~]# ps -s
  UID    PID   PENDING   BLOCKED   IGNORED    CAUGHT STAT TTY        TIME COMMAND
    0    683  00000000  00000000  00000006  00000000 Ss+  tty1       0:00 /sbin/agetty --nocl
    0   1207  00000000  00010000  00384004  4b813efb Ss   pts/0      0:00 -bash
    0   1349  00000000  00000000  00384004  4b813efb Ss+  pts/1      0:00 -bash
    0   1437  00000000  00000000  00384004  4b813efb Ss+  pts/2      0:00 -bash
    0   1979  00000000  00000000  00384004  4b813efb Ss+  pts/3      0:00 -bash
    0   3484  00000000  00000000  00000000 <f3d1fef9 R+   pts/0      0:00 ps -s

小白的我：哦哦，原来是这个意思呀 ~ 大大那这个 STAT 是不是有很多个状态呀！

倪大大： 是的，但我们使用 ps -aux 可以看到很多 进程的状态，我们来试一下。

[root@localhost ~]# ps -aux
USER        PID %CPU %MEM    VSZ   RSS TTY      STAT START   TIME COMMAND
root          1  0.0  0.6 128192  6804 ?        Ss   12:25   0:04 /usr/lib/systemd/systemd --
root          2  0.0  0.0      0     0 ?        S    12:25   0:00 [kthreadd]
root          4  0.0  0.0      0     0 ?        S<   12:25   0:00 [kworker/0:0H]
root          6  0.0  0.0      0     0 ?        S    12:25   0:03 [ksoftirqd/0]
root          7  0.0  0.0      0     0 ?        S    12:25   0:00 [migration/0]
root          8  0.0  0.0      0     0 ?        S    12:25   0:00 [rcu_bh]
root          9  0.0  0.0      0     0 ?        R    12:25   0:26 [rcu_sched]
root         10  0.0  0.0      0     0 ?        S<   12:25   0:00 [lru-add-drain
root       1207  0.0  0.2 115756  2296 pts/0    Ss   12:28   0:00 -bash
root       1345  0.0  0.5 158928  5608 ?        Ss   14:09   0:01 sshd: root@pts/1
root       1349  0.0  0.2 115676  2244 pts/1    Ss+  14:09   0:00 -bash
root       1433  0.0  0.5 158928  5616 ?        Ss   14:23   0:03 sshd: root@pts/2
root       1437  0.0  0.2 115676  2244 pts/2    Ss+  14:23   0:00 -bash
root       1533  0.3  0.7 162356  7952 ?        Ssl  14:32   1:33 ./redis-server *:6379
root       1973  0.0  0.5 158928  5616 ?        Ss   20:44   0:00 sshd: root@pts/3
root       1979  0.0  0.2 115676  2172 pts/3    Ss+  20:44   0:00 -bash
..........

我们使用 man 手册可以查看下这个字母代表的状态是啥？ man ps 

PROCESS STATE CODES
       Here are the different values that the s, stat and state output specifiers (header
       "STAT" or "S") will display to describe the state of a process:

               D    uninterruptible sleep (usually IO)
               R    running or runnable (on run queue)
               S    interruptible sleep (waiting for an event to complete)
               T    stopped by job control signal
               t    stopped by debugger during the tracing
               W    paging (not valid since the 2.6.xx kernel)
               X    dead (should never be seen)
               Z    defunct ("zombie") process, terminated but not reaped by its parent

       For BSD formats and when the stat keyword is used, additional characters may be
       displayed:

               <    high-priority (not nice to other users)
               N    low-priority (nice to other users)
               L    has pages locked into memory (for real-time and custom IO)
               s    is a session leader
               l    is multi-threaded (using CLONE_THREAD, like NPTL pthreads do)
               +    is in the foreground process group

小白，这些英文对你来说 so so easy 啦，我就不一一解释了。

小白的我o(╥﹏╥)o（委屈的一批，我我我），面露笑容说：好的大大，这是 so easy easy 啦 ~

倪大大说：你可以简单理解为，平均负载其实就是平均活跃进程数。平均活跃进程数，直观上的理解就是单位时间内的活跃进程数，但它实际上是活跃进程数的指数衰减平均值。这个“指数衰减平均”的详细含义你不用计较，这只是系统的一种更快速的计算方式，你把它直接当成活跃进程数的平均值也没问题。

小白白的我：大大，既然平均的是活跃进程数，那么最理想的，就是每个 CPU 上都刚好运行着一个进程，这样每个 CPU 都得到了充分利用，那当数字是其他的时候是什么含义呀？

倪大大解释道：如果你平均负载是 2，那么情况如下： 

• 在只有 2 个 CPU 的系统上，意味着所有的 CPU 都刚好被完全占用。
• 在 4 个 CPU 的系统上，意味着 CPU 有 50% 的空闲。
• 而在只有 1 个 CPU 的系统中，则意味着有一半的进程竞争不到 CPU。

小白的我：哦哦，我懂了大大原来是这样呀。

倪大大这时向我扔了个炸弹：小白，我来问问你一些问题。

平均负载为多少时合理？不知道你能否判断出，在 uptime命令的结果里，那三个时间段的平均负载数，多大的时候能说明系统负载高？或是多小的时候就能说明系统负载很低呢？

我脑子突然一抽：这个吗~这个吗~，我要知道它的 CPU 数才能判断呀，突然脑子想到了这个命令：

[root@localhost ~]# lscpu  |grep "^CPU(s):.*"
CPU(s):                1

倪大大抚摸着我的脑袋：小白不错呀！是不是偷偷开小灶了，变得这么厉害了！其实还可以使用这个命令：

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

我心虚的一批o(╥﹏╥)o（我是昨晚才看到这个命令的），不然我也不会啊！

这时，有了 CPU 个数，我们就可以判断出，当平均负载比 CPU 个数还大的时候，系统已经出现了过载。 对了，大大我有个新的问题又来了。我们在例子中可以看到，平均负载有三个数值，到底该参考哪一个呢？ 

 大大说：

实际上，都要看。三个不同时间间隔的平均值，其实给我们提供了，分析系统负载趋势的数据来源，让我们能更全面、更立体地理解目前的负载状况。打个比方，就像初秋时北京的天气，如果只看中午的温度，你可能以为还在 7 月份的大夏天呢。但如果你结合了早上、中午、晚上三个时间点的温度来看，基本就可以全方位了解这一天的天气情况了。

同样的，前面说到的 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% 的时候，你就应该分析排查负载高的问题了。一旦负载过高，就可能导致进程响应变慢，进而影响服务的正常功能。（但 70% 这个数字并不是绝对的，最推荐的方法，还是把系统的平均负载监控起来，然后根据更多的历史数据，判断负载的变化趋势。当发现负载有明显升高趋势时，比如说负载翻倍了，你再去做分析和调查。）

 

我：哦，原来是这样紫呀！那平均负载与 CPU 使用率有什么区别呀？

大大：平均负载是指单位时间内，处于可运行状态和不可中断状态的进程数。所以，它不仅包括了正在使用 CPU 的进程，还包括等待 CPU 和等待I/O 的进程。

而 CPU 使用率，是单位时间内 CPU 繁忙情况的统计，跟平均负载并不一定完全对应。比如：CPU 密集型进程，使用大量 CPU 会导致平均负载升高，此时这两者是一致的；I/O 密集型进程，等待 I/O 也会导致平均负载升高，但 CPU 使用率不一定很高；大量等待 CPU 的进程调度也会导致平均负载升高，此时的 CPU 使用率也会比较高。

 

 接下来我们进行实战分析下吧！（好的大大）(*?▽?*)

现在 Linux 系统上安装 stress 和 sysstat 工具。我们的 CPU 是单核的（苦逼o(╥﹏╥)穷人家的我，没钱买好电脑┭┮﹏┭┮）

 

stress 是一个 Linux 系统压力测试工具，这里我们用作异常进程模拟平均负载升高的场景。而 sysstat 包含了常用的 Linux 性能工具，用来监控和分析系统的性能。我们的案例会用到这个包的两个命令 mpstat 和 pidstat。（mpstat 是一个常用的多核 CPU 性能分析工具，用来实时查看每个 CPU 的性能指标，以及所有 CPU 的平均指标。pidstat 是一个常用的进程性能分析工具，用来实时查看进程的 CPU、内存、I/O 以及上下文切换等性能指标。）

 

场景一：CPU 密集型进程

运行 stress 命令，模拟一个 CPU 使用率 100% 的场景：

 stress --cpu 1 --timeout 600

接下来运行 uptime 查看平均负载的变化情况：

 -d 参数表示高亮显示变化的区域
watch -d uptime
Every 2.0s: uptime
22:11:05       up 9:45, 4 users,   load average:1.95,   0.72,  0.30

我们看到 1 分钟的平均负载已经升到了1.95。

接下来运行 mpstat 查看 CPU 使用率的变化情况：

mpstat -P ALL 5
22时12分56秒  CPU    %usr   %nice    %sys   %iowait    %irq   %soft  %steal  %guest  %gnice   %idle
22时12分56秒  all   99.60    0.00    0.40    0.00       0.00  0.00    0.00    0.00    0.00     0.00

我们可以看到有一个CPU的使用率达到 99.60 %，而 iowait 却处于 0.00。我们可以知道平均负载的升高是 CPU 的使用率造成的。

这时，我们可以用 pidstat 来查询到底哪个进程导致的原因啦~~~(*?▽?*)

 

pidstat -u 5 1
22时18分23秒   UID       PID    %usr %system  %guest    %CPU   CPU  Command
22时18分28秒     0         9    0.00    0.20    0.00    0.20     0  rcu_sched
22时18分28秒     0      3545   98.61    0.00    0.00   98.61     0  stress

平均时间:   UID       PID    %usr %system  %guest    %CPU   CPU  Command
平均时间:     0         9    0.00    0.20    0.00    0.20     -  rcu_sched
平均时间:     0      3545   98.61    0.00    0.00   98.61     -  stress

我们可以看到是由于执行了 stress 命令，即进程id 为3545 的进程导致的原因。

 

场景二：I/O 密集型进程

我们同样运行 stress 命令，使用 sync 同步命令进行 I/O 压力测试：

stress -i 1 --timeout 600

运行 uptime 进行监控

watch -d uptime

Every 2.0s: uptime
22:21:05     up 9:45, 4 users,   load average:1.07,   0.92,  0.60

我们使用 mpstat 进行 CPU 使用情况检测：

mpstat -P ALL 5
22时23分44秒  CPU    %usr   %nice   %sys  %iowait    %irq   %soft  %steal  %guest  %gnice   %idle
22时23分49秒  all    0.21    0.00   12.01    0.00    0.00   32.67    0.00    0.00    0.00    0.00
22时23分49秒    0    0.00    0.00   0.81    0.00    0.00    68.32    0.00    0.00    0.00    0.00

可以看出平均负载升高是由于 iowait的原因。

接下来我们使用 pidstat 来查看到底是哪个进程的原因。

pidstat -u 5 1
22时29分08秒   UID       PID    %usr %system  %guest    %CPU   CPU  Command
22时29分13秒     0      1433    0.00    0.20    0.00    0.20     0  sshd
22时29分13秒     0      1533    0.00    0.20    0.00    0.20     0  redis-server
22时29分13秒     0      2152    0.00    8.98    0.00    8.98     0  kworker/u256:0
22时29分13秒     0      4270    0.20    0.20    0.00    0.40     0  watch
22时29分13秒     0      4324    0.00    7.98    0.00    7.98     0  kworker/u256:1
22时29分13秒     0      4489    3.39   78.04    0.00   81.44     0  stress
22时29分13秒     0      4504    0.00    0.20    0.00    0.20     0  kworker/0:2
22时29分13秒     0      4696    0.00    0.20    0.00    0.20     0  pidstat

我们可以看出是 stress 导致的原因。

 

场景二：大量进程的进程

stress -c 4 --timeout 600

一个CPU，4个进程。

watch -d uptime
Every 2.0s: uptime
22:35:05    ...., 4 users,   load average:6.77,   5.92,  3.60

借下来我们使用 pidstat 来查看下：

# 间隔 5 秒后输出一组数据
$ pidstat -u 5 1
14:23:25      UID       PID    %usr  %system  %guest   %wait    %CPU   CPU  Command
14:23:30        0      3190   17.00    0.00    0.00   84.80   25.00     0  stress
14:23:30        0      3191   18.00    0.00    0.00   85.20   25.00     0  stress
14:23:30        0      3192   25.00    0.00    0.00   84.80   25.00     1  stress
14:23:30        0      3193   25.00    0.00    0.00   85.00   25.00     1  stress14:23:30        0      3200    0.00    0.20    0.00    0.20    0.20     0  pidstat

我们可以看出是 stress 导致的原因~~

 

回想完那段满满收获的日子，我想起了我的知识，我想起了我的....

哦豁完蛋，我要滚蛋走人了~o(╥﹏╥)o

（以上故事都是自己瞎编的，知识都是倪大大的，我只是的学习者o(╥﹏╥)o，希望自己能努力进步，少壮不努力长大连砖都没得搬的我o(╥﹏╥)o）