高负载低CPU不是监控错误，而是负载统计可运行（R）和不可中断睡眠（D）进程数，CPU使用率统计实际执行时间占比；最常见原因是D状态进程堆积，如等待磁盘、NFS或内核I/O完成。
系统平均负载高但 CPU 利用率低，不是监控出错，而是两个指标统计维度不同：负载看的是“有多少任务在排队或卡住”，CPU 使用率看的是“CPU 实际干活的时间占比”。最常见真凶是大量进程卡在不可中断睡眠（D 状态），尤其是等待磁盘、NFS 或内核 I/O 完成时——它们不耗 CPU，却持续推高 load。
先确认是否真存在 I/O 等待瓶颈
运行 top，重点看 CPU 行末尾的 wa（iowait）值：
- wa 持续 ≥ 5%，且 idle 明显下降 → 强烈指向磁盘 I/O 瓶颈
- wa 很低（如 < 1%）但 load 仍高 → 更可能是 D 状态进程堆积，而非活跃 I/O
- 同时关注 st（steal time）：虚拟机中若 st 偏高，说明宿主机资源被争抢
查 D 状态进程和阻塞源头
D 状态进程是高 load 低 CPU 的核心线索，它们无法被信号中断，只能等底层完成：
- 列出当前 D 状态进程：ps -eo pid,stat,comm,wchan --sort=-wchan | head -15 —— wchan 列显示等待的内核函数，比 stat 更具诊断价值
- 常见 wchan 含义：io_schedule（通用 I/O 等待）、ext4_writepages（ext4 刷脏页卡住）、nfssvc（NFS 服务挂起）、__common_interrupt（NVMe/驱动响应异常）
- 若发现大量进程卡在相同 wchan，基本可定位到对应子系统（如文件系统、存储驱动或 NFS 服务）
检查磁盘与底层存储健康状态
I/O 卡顿往往源于硬件、驱动或存储后端问题，不能只盯上层进程：
- 用 iostat -x 1 观察：%util ≈ 100% + await > 100ms → 设备响应慢；%util 很低 但 avgqu-sz 高 → 请求队列积压，常见于 RAID 卡故障、Ceph OSD 过载或云盘突发 IOPS 耗尽
- 运行 dmesg -T | grep -i "error\|fail\|timeout"，查找 Buffer I/O error、end_request I/O error 或 page allocation failure 等关键报错
- 云环境特别注意“无声降级”：AWS EBS gp2 卷、阿里云云盘等在 IOPS 耗尽后不会报错，但 await 陡升、load 暴涨，需结合云平台监控交叉验证
排除内存与交换引发的连锁阻塞
内存严重不足会触发频繁换页，把内存压力转为磁盘 I/O 压力，间接抬高 load：
- 执行 free -h，关注 Available 是否远低于总内存，且 SwapFree 接近 0
- 运行 vmstat 1，持续出现高 si（swap in）和 bi（block in）值 → 正在发生大量换入换出
- 检查 cat /proc/buddyinfo：若高阶内存（如 order-10）为 0，说明连续大内存分配失败，可能引发内核路径阻塞
