基础篇：到底应该怎么理解“平均负载”

root@Test-MySQL:/home/zoom/test# uptime 
 08:41:38 up 3 days,  5:40,  2 users,  load average: 0.00, 0.03, 0.02

我相信你对前⾯的⼏列⽐较熟悉，它们分别是当前时间、系统运⾏时间以及正在登录⽤户数。
⽽最后三个数字呢，依次则是过去1分钟、5分钟、15分钟的平均负载（Load Average）。

平均负载

平均负载是指单位时间内，系统处于可运⾏状态和不可中断状态的平均进程数，也就是平均活跃进程数，它和CPU使⽤率并没有直接关系。

• 可运⾏状态：是指正在使⽤CPU或者正在等待CPU的进程，也就是我们常⽤ps命令看到的，处于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，最后三个数字依次则是过去1分钟、5分钟、15分钟的平均负载（Load Average）

  root@Test-MySQL:/home/zoom/test# uptime 
   08:41:38 up 3 days,  5:40,  2 users,  load average: 0.00, 0.03, 0.02

• 执行top/nproc查到cpu个数，当平均负载⽐ CPU 个数还⼤的时候，系统已经出现了过载
  • 如果1分钟、5分钟、15分钟的三个值基本相同，或者相差不⼤，那就说明系统负载很平稳。
  • 如果1分钟的值远⼩于15 分钟的值，就说明系统最近1分钟的负载在减少，⽽过去15分钟内却有很⼤的负载。
  • 如果1分钟的值远⼤于 15 分钟的值，就说明最近1分钟的负载在增加，这种增加有可能只是临时性的，也有可能还会持续增加下去，所以就需要持续观察。⼀旦1分钟的平均负载接近或超过了CPU的个数，就意味着系统正在发⽣过载的问题，这时就得分析调查是哪⾥导致的问题，并要想办法优化了。
• 当平均负载⾼于 CPU 数量70%的时候，你就应该分析排查负载⾼的问题了。⼀旦负载过⾼，就可能导致进程响应变慢，进⽽影响服务的正常功能。

假设我们在⼀个单 CPU 系统上看到平均负载为 1.73，0.60，7.98，那么说明在过去 1 分钟内，系统有73% 的超载，⽽在 15 分钟内，有 698% 的超载，从整体趋势来看，系统的负载在降低。

平均负载与CPU使⽤率

平均负载不等于 CPU 使⽤率，平均负载是指单位时间内，处于可运⾏状态和不可中断状态的进程数。所以，它不仅包括了正在使⽤ CPU 的进程，还包括等待 CPU 和等待 I/O 的进程。⽽ CPU 使⽤率，是单位时间内 CPU 繁忙情况的统计，跟平均负载并不⼀定完全对应。⽐如：

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

平均负载案例分析

我们以三个示例分别来看这三种情况，并⽤ iostat、mpstat、pidstat 等⼯具，找出平均负载升⾼的根源。