负载(Load)和 CPU 利用率之间有什么区别?
一个是排队长度,一个是忙碌比例:load 统计"有多少任务想跑",CPU 利用率统计"CPU 有多少时间在跑"。 顾客多但收银员一直在结账,是 load 和利用率都高;顾客多但收银机死机了,就是 load 高、利用率低。 把这两个指标拆开看,才能定位瓶颈在算力还是在等待。
1. 一张四象限图
| load | CPU 利用率 | 典型原因 | 处理方向 |
|---|---|---|---|
| 高 | 高 | 计算真跑满,任务排队 | 扩容 / 优化算法 / 加缓存 |
| 高 | 低 | 大量 D 状态卡在 IO、NFS、锁 | 查磁盘与网络存储,减少阻塞点 |
| 低 | 高 | 少数线程吃满 CPU,但不排队 | 单线程热点,看 perf top / 火焰图 |
| 低 | 低 | 空闲 | 关注延迟与连接数即可 |
超市模型
load = 排队人数 + 正在结账的人数(想结账的总量)
利用率 = 收银员忙碌时间占比
排队长但收银员闲 → 收银机卡了(IO 阻塞)
排队短但收银员忙 → 只有一个柜台开着(单线程热点)
排队长且收银员忙 → 真的该加柜台了(扩容)
2. 为什么两者会背离
load 里包含了不可中断睡眠(D 状态),而 D 状态的任务根本不占 CPU。所以:
- 磁盘
await飙高、NFS 超时、驱动卡死 → D 状态堆积 → load 涨,%idle也涨。 - 大量线程抢一把锁 → 线程在 R 与 S 之间反复横跳,load 涨,但真正干活的时间少,
sy可能很高。 - 单线程 CPU 密集计算 → 一个核 100%,其余核空闲,整机利用率只有 1/N,load 也只是 1 左右。
反过来,CPU 利用率高不一定有压力:一个 8 核机器上 7 个核在跑批处理、1 个核留给在线服务, 利用率 87% 看起来很满,但请求延迟毫无变化——利用率是"资源占用",不是"服务质量"。
3. 一起采,才能定位
# 每秒打印 load1、CPU 利用率、D 状态任务数,一眼看背离
while true; do
read -r l1 _ < /proc/loadavg
read -r _ u n s i w irq sirq st _ < /proc/stat
d=$(ps -eo state | grep -c '^D')
echo "load1=$l1 util=$(( (u+n+s+irq+sirq+st)*100 / (u+n+s+i+w+irq+sirq+st) ))% D=$d"
sleep 1
done
# 确认到底是算力不够还是 IO 卡住
mpstat -P ALL 1 3 # 看是否单核打满、%wa 是否高
iostat -x 1 3 # 看 %util 与 await
pidstat -d 1 # 哪个进程在读盘
4. 常见追问
Q:多少 load 算高?
先归一化:load / 核数。小于 1 一般有余量,1 附近是满载,持续大于 1 说明有排队。
但阈值要按业务定:纯计算服务对排队极敏感,异步 IO 服务容忍度高得多。
Q:为什么 load 有 1/5/15 三个值? 分别是三个衰减窗口的指数平均。1 分钟看突发,5 分钟看趋势,15 分钟看水位。 三个值同时上升说明压力是持续的;只有 1 分钟高,通常是一次短促的尖峰。
Q:CPU 利用率高但 load 低,有问题吗? 说明有热点但不排队(比如单核打满),风险是延迟抖动和无法水平扩展。 这时应该做的是并行化或拆服务,而不是加机器。
Q:监控告警该用哪个?
容量规划看 load/核数 的长期趋势,服务质量看延迟分位(p99),根因定位看 us/sy/wa/st 的拆分。
单看任何一个指标都会误判。
# 告警规则示例:只在"排队"和"忙碌"同时成立时才升级为告警
- alert: CpuPressure
expr: node_load1 / count(node_cpu_seconds_total{mode="idle"}) by (instance) > 1.5
and avg by (instance)(rate(node_cpu_seconds_total{mode!="idle"}[5m])) > 0.85
for: 10m
annotations:
summary: "load 与利用率同时超过阈值,优先考虑扩容或降级"
注意判定条件是 and 而不是 or:单独的 load 高可能只是 IO 慢,单独的利用率高可能只是单核热点,
两者同时成立才说明"任务真的在排队等 CPU"。
小结
load 是"需求",利用率是"供给"。两者同时高 → 扩容;load 高利用率低 → 查 IO 与锁; 利用率高 load 低 → 找单点热点。面试时把这四象限和超市类比讲出来,比背定义有效得多。