load average 飙到几十，CPU 却很闲：它到底在等什么

刚上服务器看 top，load average 一栏飙到几十，第一反应往往是 CPU 扛不住了。但很多时候 CPU 并不忙，真正排队的是等磁盘、等网络的进程，load average 数的不是 CPU 使用率，而是“想运行和正在等 I/O 的进程数”。

先说清 load average 的三列：1 分钟、5 分钟、15 分钟，数的是处于运行态（R）和不可中断睡眠态（D）的进程平均数。D 状态最常见的原因是等磁盘 I/O：读盘、写盘、等 NFS 响应时，进程就进 D 状态出不来，load 就往上走。所以一台磁盘慢、或者挂了远端存储的机器，load 很高但 CPU idle 还有大半，是完全可能的，不代表 CPU 不够。

先诊断：看 top 里 wa 那一列（iowait 占比），wa 高就是在等 I/O；再看 vmstat 的 b 列（等 I/O 的进程数）和 bi/bo（块设备读写量），确认是不是磁盘瓶颈；再用 ps aux 看有没有大量 D 状态进程，顺着找是哪个盘、哪个服务在拖；怀疑 NFS 就看挂载的远端存储延迟和重传。还有一种假象：load 高是因为起了太多进程在抢锁、等数据库，这时 CPU 也不高，但瓶颈在锁不在盘，看具体服务的等待指标再判断。

真要处理分两种：只是某一时刻的毛刺（比如备份、定时任务在跑），等它过去就行；长期 load 高，先找到等 I/O 的源头，是磁盘慢就换盘或分流，是 NFS 抖动就查网络和服务端，是某个服务在狂写日志就先限流。加 CPU 之前，先看 wa 和 D 状态进程，别被 load 那个数字吓到，白花钱。

预防也简单：监控别只盯 load 绝对值，结合 CPU 核数看（单核 load 1 才是满载，8 核机器 load 8 只是刚满），把 iowait 和 D 状态进程数一起盯，长期偏高再告警；给磁盘密集型任务错峰，别让备份、同步、批量写盘撞在同一个时段。