先给结论：load average 的三个数字不是 CPU 使用率，而是正在运行与正在等待 I/O 完成的进程数平均值（1/5/15 分钟）。它统计的是"任务排队长度"，所以 8 核机器 load 稳定在 8 左右，意味着几乎所有核心都刚好被占满，属于满载但未积压；长期超过 8 就是开始排队了。更关键的是：load 高不一定是 CPU 忙——磁盘 I/O 卡住时 load 会飙到几十，而 CPU 可能还在喝茶。看 load 必须配 vmstat 的 r/b 两列才能定性。

一、先把定义说准：它统计三个数的和

load average 的定义在 Linux 内核里非常明确，它等于下面三类任务数之和的指数移动平均：

1. R（Running / Runnable）：正在 CPU 上跑，或者已就绪、在等 CPU 时间片
2. D（Uninterruptible Sleep）：不可中断睡眠——典型场景是等磁盘 I/O、等网络文件系统响应
3. 早期内核还含 TASK_UNINTERRUPTIBLE 的变体（TASK_KILLABLE 等），现代内核统计口径基本就是 R + D

所以正确的心智模型是：load 衡量的是"系统手上积压了多少活"，不是"CPU 有多忙"。

前两个要点直接决定了两类典型误读：

• 把 load 当 CPU 使用率 → 8 核机器 load 4 就说"CPU 用了 50%"，错。load 4 只是说平均有 4 个任务在跑/等，CPU 可能只忙了 30%
• 忽略 D 状态 → 数据库所在磁盘坏了，load 冲到 50，你去加 CPU 毫无用处

二、怎么读那三个数字：趋势比绝对值重要

uptime 输出长这样：

 16:20:01 up 43 days,  2:14,  3 users,  load average: 0.62, 1.35, 4.08

三个数字是 1 分钟、5 分钟、15 分钟的指数移动平均。绝对值只用来判断"是否超标"，三个数的相对关系才告诉你系统在往哪个方向走：

判断基线：单核系统 load 1 = 满载，4 核 = 4，8 核 = 8。别背"load 超过 1 就危险"这种单核时代的老经验。

三、定性靠 vmstat：r 和 b 两列是关键

光看 load 数值无法区分"CPU 忙"和"I/O 卡"，一条命令就能分离：

vmstat 1

procs -----------memory---------- ---swap-- -----io---- -system-- ------cpu-----
 r  b   swpd   free   buff  cache   si   so    bi    bo   in   cs us sy id wa st
12  0      0 512340  82104 2145096    0    0   120    48 4210 8901 92  7  1  0  0
 0 14      0 498220  82104 2145096    0    0  8940   320 3120 2210  3  2  12 83  0

读法非常直接：

• r 列（runnable）持续大于 CPU 核数 → 真的在排队等 CPU，需要加核心或优化计算
• b 列（blocked，D 状态）不为 0 且持续 → 进程卡在 I/O 上，load 是被 D 状态抬起来的，加 CPU 没用，要查磁盘/存储
• 第二张表里的 wa（iowait）83% 就是铁证：CPU 大部分时间在等 I/O，别被 load 数字骗了

我排查线上 load 突增的顺序固定是这三步：uptime 看趋势 → vmstat 1 看 r/b 定性 → pidstat -d 1 或 iostat -x 1 定位到具体进程和磁盘。

四、两个高频误区

误区一：load 必须除以核数才是"百分比"。 不完全对。真正的百分比是 load / 核数 * 100%，但这个比值只在"纯 CPU 型负载（b≈0）"时才等价于 CPU 利用率，剩下的场景里它什么都不是。

误区二：容器里 load 不准。 这是最坑的一个。load average 来自 /proc/loadavg，它反映的是宿主机全网状态，不是容器的。容器云上跑着 3 个 Pod，你去 Pod 里看 load 是 40，很可能是隔壁容器在刷盘，跟你毫无关系。容器环境要看 cgroup 指标：

# cgroup v1
cat /sys/fs/cgroup/cpu/cpu.stat        # nr_running / nr_uninterruptible
# cgroup v2
cat /sys/fs/cgroup/cpu.stat

判断容器真实的 CPU 压力，用 nr_throttled（被限流的次数）和 nr_running，比 load 可靠得多。

五、生产环境该怎么设告警

我的建议是三档，别只设一个阈值：

1. 趋势告警（最重要）：15 分钟值比 1 小时前上涨 3 倍以上就提醒，不看绝对值。突发积压永远是先被趋势抓住的
2. 容量告警：load > 核数 × 1.5 持续 10 分钟（留出合理的瞬时波动空间）
3. 定性告警：load 高但 wa 也高 → 单独报"存储疑似瓶颈"，这类告警要发给不同的负责人，不然永远是"CPU 分析半天，问题在磁盘"

顺带一句：load 不是越低越好。一个 8 核机器长期 load 0.1，说明你在浪费钱——容量规划要的是"稳定在核数的 60%~80% 区间"，那才是健康的成本效率。

FAQ

Q：8 核服务器 load 多少算正常？ 稳定在 8 以下属于安全区，8~12 是满载区间需要观察，持续超过 12（核数 ×1.5）就该排查了。但必须结合 vmstat 的 r/b 列定性，纯 CPU 型负载和 I/O 型负载的处理方式完全不同。

Q：load 很高但 CPU 使用率很低，是怎么回事？ 几乎可以肯定是 I/O 阻塞。load 统计包含 D 状态（不可中断睡眠）进程，磁盘或网络存储响应慢时，大量进程卡在 D 状态把 load 抬高，而 CPU 实际很闲。用 vmstat 1 看 b 列和 wa 列即可确认。

Q：容器里的 load average 能信吗？ 不能直接信。容器读到的 /proc/loadavg 是宿主机全局数据，不反映容器自身压力。容器环境应改用 cgroup 的 cpu.stat（nr_running、nr_throttled）判断真实 CPU 压力。