load average 基础

平均负载(load average)提供了一个快速查看系统整体性能的手段，反映了系统整体的负载情况。

它是指单位时间内，系统处于可运行状态和不可中断状态的平均进程数的指数衰减平均值。

这个 "指数衰减平均" 只是一种更快速的计算方式，你把它直接当成活跃进程数的平均值。

所谓可运行状态的进程，是指正在使用 CPU 或者正在等待 CPU 的进程。

也就是我们常用 ps/top 命令看到的处于 R 状态(Running 或 Runnable)的进程。

不可中断状态的进程则是正处于内核态中的进程，并且这些流程是不可被打断的。

比如最常见的是等待硬件设备的 I/O 响应，也就是我们在 ps/top 命令中看到的 D 状态(Uninterruptible Sleep，也称为 Disk Sleep)的进程。

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

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

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

比如当平均负载为 2 时，意味着什么呢？

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

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

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

平均负载最理想的情况是等于 CPU 个数。所以在评判平均负载时，首先你要知道系统有几个 CPU。

这可以通过 top(按 1) 命令、lscpu 命令或者从文件 /proc/cpuinfo 中读取

# grep 'model name' /proc/cpuinfo | wc -l

推荐的方法是监控系统的平均负载，根据更多的历史数据，来判断系统负载的变化趋势。

一旦负载过高，就可能导致进程响应变慢，进而影响服务的正常功能。

既然平均负载代表的是平均活跃进程数，那平均负载高了，不就意味着CPU 使用率高吗？

我们还是要回到平均负载的含义上来，平均负载是指单位时间内，处于可运行状态和不可中断状态的进程数。

所以，它不仅包括了正在使用 CPU 的进程，还包括等待 CPU 和等待 I/O 的进程。

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

比如以下几种情况：

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

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

3、大量等待 CPU 的进程调度也会导致平均负载升高，此时的 CPU 使用率也会比较高(主要是 sys cpu 较高)。比如 CPU上下文切换。

注意：系统的平均负载(load average)和 CPU 使用率并没直接关系。

Linux load average 的误区

Load average 的概念源自 Unix 系统，用于衡量 runnable processes 的数量。

但是在 Linux 上的 load average 除了包括 Running 和 Runnable process 数量之外，还包括 uninterruptible sleep 的进程数量。

通常等待 I/O 设备、等待网络的时候，进程会处于 uninterruptible sleep 状态。

Linux 设计者可能认为 uninterruptible sleep 应该都是非常短暂的，所以被等同于 runnable。

然而现实世界中 uninterruptible sleep 未必很短暂。大量的、或长时间的 uninterruptible sleep 通常意味着 I/O 设备可能遇到了瓶颈。

我们知道：sleep 状态的进程是不需要 CPU 的，即使所有的 CPU 都空闲，正在 sleep 的进程也是运行不了的。

所以 Linux 把 uninterruptible sleep 进程加入到 load average 的计算的做法直接颠覆了 load average 本来的意义。

因此在 Linux 系统上，当看到 load average 很高的时候，你不知道是 runnable 进程太多还是 uninterruptible sleep 进程太多，也就无法判断是 CPU 不够用还是 I/O 设备有瓶颈。