load 飙到 47 但 CPU 只用 8%：D 状态堆积的根因、定位与 PSI 监控落地

作者沈景行-346

Linux运维load-averageD状态PSINFS

结论先行：load average 统计的是「运行队列 + 不可中断任务数」的平滑值，不是 CPU 使用率。当出现「load 高 + CPU 低 + IO util 低但 await 高」的组合，第一嫌疑是 D 状态堆积，最常见的来源是 NFS / 共享存储抖动与同步磁盘 IO。

一、现象：机器「看起来很闲」，业务却卡死了

上个月凌晨 02:47，一台 16C64G 的 worker（CentOS 7.9，kernel 3.10.0-1160，NFS 挂载了 /mnt/share 存日志归档）开始报 P99 异常：一个本应 30ms 的「订单状态查询」接口，P99 直接拉到 12.3s，持续 7 分钟。

告警面板上最反直觉的一组数字：

load average（1min）：47.2（机器只有 16 核，load 是核数的近 3 倍）
top 里 us + sy：加起来 8.1%（机器看起来「很闲」）
free -h：可用内存 31G，没有 swap 抖动
iostat -x 1：磁盘 util 才 22%，但 await = 1240ms（单 IO 平均要等 1.24 秒）

按「load 高 = CPU 打满」的直觉，第一反应是抢 CPU；可 CPU 明明才 8%，线程数、GC、连接池全正常。最后定位到：31 个业务线程全部卡在 D 状态（不可中断睡眠），在等 NFS 上的一次目录 stat 返回。

二、根因：load average 统计的是「任务数」，不是「CPU 占用率」

很多人以为 load average 是「CPU 有多忙」，这是错的。

/proc/loadavg 里的三个数字，统计的是运行队列（R 状态）+ 不可中断睡眠（D 状态）的任务数，再对 1min / 5min / 15min 做指数平滑（内核每 5 秒采样一次，衰减系数分别为 5/2、5/11、5/61）。

也就是说：

一个进程在 D 状态等磁盘、等 NFS、等某把不可中断的锁，它不占任何 CPU，但会被算进 load。
16 核的机器，load = 47 完全可能对应「CPU 用 8% + 31 个进程在 D 状态排队」。

D 状态的本质是「内核帮你在等一个不可中断的完成事件」，典型来源：

同步磁盘 IO（ext4/xfs 的 read/write、fsync）
NFS / 共享存储抖动（最坑，远端 hang 时本地进程全 D）
mutex / rwlock 不可中断路径（某些内核模块）
futex 的不可中断变体（少见）

所以「load 高 + CPU 低 + IO util 低但 await 高」这个组合，几乎是 D 状态堆积的指纹。

三、定位四步法（命令可复现）

第 1 步：确认是不是 D 状态在拖

# 一行看 D 状态进程数
ps -eo state,comm | awk '$1=="D"' | wc -l   # 本例：31

# 看具体是谁
ps -eo pid,stat,comm,wchan | awk '$2 ~ /^D/'
# 输出里 wchan 列直接告诉你卡在哪个内核函数
# 本例看到大量 nfs_wait_on_request / nfs4_proc_lookup

第 2 步：看内核栈，确认卡在 NFS

# 对任一 D 状态进程
cat /proc/<pid>/stack
# 看到 nfs4_proc_lookup -> rpc_wait_bit_killable -> nfs_wait_on_request
# 基本可以断定是 NFS 元数据调用 hang 了

# 也可以看 wchan 字符串
cat /proc/<pid>/wchan; echo   # 输出 nfs_wait_on_request

第 3 步：用 PSI 量化「到底多卡」

# Linux 4.20+ 才有；本例机器是 3.10 没有，我在 5.15 的机器上复现
cat /proc/pressure/io
# some avg10=38.72 avg60=12.40 avg300=3.10 total=...
# full avg10=9.85   # full 高 = 整个 cgroup 都被 IO 阻塞

cat /proc/pressure/cpu
# some avg10=0.32   # CPU 压力几乎为 0，反证不是 CPU 问题

PSI 的 some 是「至少一个任务被阻塞的时间占比」，full 是「所有任务都被阻塞的时间占比」，比 load 精确得多。

第 4 步：止血 + 取证

# 止血：NFS 客户端超时
nfsstat -c          # 看 retrans（重传次数）飙升
# 业务侧：把 /mnt/share 的同步 fsync 改成异步 append + 本地落盘再回传
# 内核侧：mount -o timeo=6000,retrans=3（timeo 单位 1/100 秒，6000=60s）

# 取证：抓 IO 时间线
blktrace -d /dev/vdb -w 60 -o - | blkparse -i -   # 本地盘
# NFS 走不了 blktrace，改抓 nfs 客户端日志
dmesg -T | grep -i nfs

四、踩过的坑（反直觉清单）

load > nproc 不等于 CPU 打满。16 核机器 load=47，CPU 才 8%——load 是「任务数」，不是「占用率」。把它当 CPU 告警，要么误报要么漏报。
D 状态进程 kill -9 都杀不掉。信号要等它从内核路径返回才能处理，NFS hang 时你只能等超时或重启。所以业务侧必须给所有同步 IO 加 timeout，不能裸调。
15min load 是「历史残留」。指数衰减系数 5/61 ≈ 0.08，一次 5 分钟的 D 状态风暴，15min load 要 30 分钟后才回落到基线。告警用 1min 才有意义，15min 只适合看趋势。
iostat util 低 ≠ 磁盘没问题。util 是「有多少时间盘在干活」，await 才是「单次 IO 要等多久」。本例 util 22% 但 await 1240ms，盘其实被 NFS 客户端的同步等回包拖住了。
NFS 的 D 状态会「跨进程传染」。一个进程的 lookup hang 住，后续所有走同一 mount 的进程都会排队进 D，最后看起来是「全业务卡死」，其实只是共享存储抖了 30 秒。
kernel 3.10（CentOS 7）没有 PSI。老机器上你只能用 /proc/<pid>/stack + wchan 手工推断，PSI 在 4.20+ 才有。新机器（5.15 / 6.x）建议直接把 PSI 接进 Prometheus（node_exporter 已支持 node_pressure_cpu_waiting_seconds_total 等指标）。

五、结论与可复用清单

结论：load average 是「运行队列 + 不可中断任务数」的平滑值，不是 CPU 使用率。当出现「load 高 + CPU 低 + IO util 低但 await 高」的组合，第一嫌疑是 D 状态堆积，最常见的来源是 NFS / 共享存储抖动和同步磁盘 IO。

避坑清单（建议贴到运维 wiki）：

[ ] 告警不要只看 load，要同时看 us+sy、iostat await、/proc/pressure/{cpu,memory,io} 三者
[ ] 业务侧所有同步 IO（读文件、fsync、stat）必须带 timeout，禁止裸调
[ ] NFS mount 显式设置 timeo / retrans，不要依赖默认
[ ] 监控采集 ps -eo stat | grep -c ^D，D 状态进程数 > 1 就告警
[ ] 新机器（kernel ≥ 4.20）把 PSI 的 some / full 接进 Prometheus，比 load 精确得多
[ ] 老机器（CentOS 7 / kernel 3.10）用 /proc/<pid>/stack + wchan 手工定位，别指望 PSI
[ ] D 状态进程 kill -9 无效，止血靠「让内核路径返回」（超时、重启、切存储）
[ ] 15min load 只用于看趋势，告警用 1min

一句话总结：load 是「有多少人在排队」，CPU 是「有多少人在干活」——两者可以同时一个高一个低，关键看谁在 D 状态、在等什么。

赞 0 · 收藏 0 · 评论 0 · 浏览 0

暂无评论。