load average 与 CPU 利用率本质不同：前者反映就绪/阻塞任务数，需对比逻辑核数判断瓶颈；后者仅表 CPU 时间占用。高 load 低 CPU 常因 D 状态进程堆积（如 I/O 阻塞），需用 ps 和 iostat 排查；高 CPU 低 load 多为单线程计算密集型。

系统负载（load average）和 CPU 利用率看起来都反映“忙不忙”，但它们衡量的完全是两件事。定位 CPU 瓶颈时，如果只盯着其中一个指标，很容易误判——比如看到 CPU 使用率才 20%，却忽略 load 高达 12，系统早已卡顿；或者发现 CPU 利用率 95%，却没注意到 load 只有 0.8，说明只是单个进程在霸占资源，并非整体瓶颈。

先看 load average 是否越界

load average 的三个数值（1/5/15 分钟）不是绝对值，必须对照 CPU 逻辑核心数判断：

• 执行 lscpu | grep "CPU(s)" 或 nproc 查清逻辑核数（比如是 8 核）
• 若 load1 持续 > 8，说明平均有超 8 个任务在争抢 CPU 或卡在 I/O；> 16 就属于严重拥堵，需立即介入
• 注意趋势：load15 > load5 > load1 表示压力在积累；load1 远高于后两者，说明是突发尖峰

再对比 CPU 利用率分布（top 或 htop 中的 us/sy/wa/iowait）

CPU 利用率低但 load 高，常见于 I/O 或内核阻塞；利用率高但 load 低，多是单线程计算密集型任务。关键看各成分占比：

• us（用户态）高 + load ≈ 1：大概率是单个应用 CPU 密集，比如死循环或未优化算法
• wa 或 iowait 高 + load 显著高于核数：进程大量处于 D 状态（不可中断等待磁盘/NFS/锁），CPU 空闲但任务排队
• sy（系统态）持续 > 30%：可能是频繁上下文切换、软中断过多（如网卡收包风暴）、或内核路径争用

重点排查 D 状态进程和 I/O 延迟

高 load + 低 CPU 最典型的根因就是 D 状态堆积，这类进程无法被 kill，也不会出现在 top 的 CPU 排名里，但会拉高 load：

• 用 ps -eo pid,stat,comm,wchan --sort=stat | grep "^.*D " 找出所有 D 状态进程及等待的内核函数（wchan）
• 结合 iostat -x 1 看 await（平均 I/O 等待时间）是否超 50ms、%util 是否长期 100%，确认磁盘是否饱和
• 检查是否有 NFS 挂载点卡住、ext4 日志阻塞、或 SCSI 设备响应异常（dmesg | tail -20 常有线索）

验证瓶颈是否解除

调整或修复后不能只看 CPU 使用率回落，要同步观察 load 趋势和底层状态：

• load1/load5/load15 应逐级下降，且 15 分钟值稳定在核数以内
• iostat 中 await 回落至 10ms 内、%util
• ps 查不到 D 状态进程，或数量明显减少（