浅谈Linux系统平均负载

 

前言

---

每次发现系统变慢时，我们通常做的第一件事，就执行top或者uptime命令，来了解系统的负载情况。比如像下面这样，我在命令行里输入了 uptime命令，系统也随即给出了结果。

$ uptime
02:34:03 up 2 days, 20:14, 1 user, load average: 0.63, 0.83, 0.88

但我想问的是，你真的知道这里每列输出的含义吗？相信你对前面的几列比较熟悉，它们分别是当前时间、系统运行时间以及正在登录用户数.

02:34:03       //当前时间

up 2 days, 20:14     //系统运行时间

1 user          //正在登录用户数

而最后三个数字呢 0.63, 0.83, 0.88，依次则是过去1分钟、5分钟、15分钟的平均负载(Load Average)。

 

uptime含义

---

有人会说，平均负载不就是单位时间内的CPU使用率吗？上面的0.63,就代表CPU 使用率是63%。其实并不是这样，如果你方便的话，可以通过执行man uptime命令，来了解平均负载的详细解释。

简单来说，平均负载是指单位时间内，系统处于可运行状态和不可中断状态的平均进程数，也就是平均活跃进程数，它和CPU使用率并没有直接关系。这里先解释下可运行状态和不可中断状态这俩词。

所谓可运行状态的进程，是指正在使用CPU或者正在等待CPU的进程，也就是我们常用ps aux命令看到的，处于R状态(Running或Runnable)的进程。

不可中断状态的进程则是正处于内核态关键流程中的进程，并且这些流程是不可打断的，比如最常见的是等待硬件设备的I/O响应，也就是我们在ps命令中看到的D状态(Uninterruptible Sleep,也称为Disk Sleep)的进程。

比如，当一个进程向磁盘读写数据时，为了保证数据的一致性，在得到磁盘回复前，它是不能被其他进程或者中断打断的，这个时候的进程就处于不可中断状态。如果此时的进程被打断了，就容易出现磁盘数据与进程数据不一致的问题。

所以，不可中断状态实际上是系统对进程和硬件设备的一种保护机制。

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

既然平均的是活跃进程数，那么最理想的，就是每个CPU上都刚好好运行着一个进程，这样每个 CPU都得到了充分利用。比如当平均负载为2时，意味着什么呢？

・在只有2个CPU的系统上，意味着所有的CPU都刚好被完全占用

・在4个CPU的系统上，意味着CPU有50%的空闲

・而在只有1个CPU的系统中，则意味着有一半的进程竞争不到CPU

 

平均负载为多少时合理

---

讲完了什么是平均负载，现在我们再回到最开始的例子，不知道你能否判断出，在uptime命令 的结果里，那三个时间段的平均负载数，多大的时候能说明系统负载高？或是多小时候就能说明系统负载很低呢？

我们知道，平均负载最理想的情况是等于CPU个数。所以在评判平均负载时，首先你要知道系统有几个CPU,这可以通过top命令或者从文件/proc/cpuinfo中读取，比如:

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

有了 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使用率高吗？

我们还是要回到平均负载的含义上来，平均负载指单位时间内，处于可运行状态和不可中断状态的进程数。所以，它不仅包括了正在使用CPU的进程，还包括等待CPU和等待I/O的进程。而CPU使用率，是单位时间内CPU繁忙情况的统计，跟平均负载并不一定完全对应。比如：

•CPU密集型进程，使用大量CPU会导致平均负载升高，此时这两者是一致的

•I/O密集型进程，等待I/O也会导致平均负载升高，但CPU使用率不一定很高

•大量等待CPU的进程调度也会导致平均负载升高，此时的CPU使用率也会比较高

 

 

最后做一个详细解释

---

概念

平均负载指的是单位时间内（1,5,15分钟）系统处于可运行状态和不可中断状态的平均进程数，也就是平均活跃进程数

• 可运行状态： 正在使用CPU或者等待CPU的进程，也就是通过ps aux看到的状态为R的进程
• 不可中断状态： 正处于内核关键流程中的进程，并且这些流程是不可被打断的，比如IO响应。也就是通过ps aux看到的状态为D的进程。

不可中断状态实际上是系统对进程和硬件设备的一种保护机制

既然平均的是活跃进程数，那么最理想的就是每个CPU上正好运行着一个进程，每个进程CPU都得到了充分的利用。

一、uptime 命令

$ uptime
16:33:56 up 69 days,  5:10,  1 user,  load average: 0.14, 0.24, 0.29

以上信息的解析如下：

• 16:33:56 : 当前时间 up 69 days, 5:10 : 系统运行了69天5小时10分 1 user :
• 当前有1个用户登录了系统load average: 0.14, 0.24, 0.29 :
• 系统在过去1分钟内，5分钟内，15分钟内的平均负载 load average: 0.14, 0.24, 0.29 :
• 系统在过去1分钟内，5分钟内，15分钟内的平均负载

平均负载解析

查看逻辑 CPU 核心数：

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

运行结果表示，有 1 个逻辑 CPU 核心。以1个CPU核心为例，假设 CPU 每分钟最多处理100个进程 –

• load=0，没有进程需要 CPU
• load=0.5，CPU处理了 50 个进程
• load=1, CPU 处理了 100 个进程，这时 CPU 已被占满，但系统还是能顺畅运作的
• load=1.5, CPU 处理了 100 个进程，还有 50 个进程正在排除等着 CPU 处理，这时，CPU 已经超负荷工作了

为了系统顺畅运行，load 值最好不要超过 1.0，这样就没有进程需要等待了，所有进程都能第一时间得到处理。

很显然，1.0 是一个关键值，超过这个值，系统就不在最佳状态了。 一般 0.7 是一个比较理想的值。

另外，load 值的健康状态还跟系统 CPU 核心数相关，如果 CPU 核心数为 2，那么 load 值健康值应该为 2，以此类推。
评价系统的负载一般采用 15 分钟内的那个平均负载值。