答案是负载高但CPU利用率低本质是进程处于R或D状态等待资源而非运行，与CPU实际执行时间无关；需优先查wa值、D状态进程、iostat和vmstat交叉验证。
负载高但 CPU 利用率低，不是监控出错，而是 Linux 的负载（load average）和 CPU 使用率统计的是两件事：前者算的是“排队+卡住”的进程数，后者只算真正在 CPU 上跑的时间。所以出现 load 飙到 10、top 显示 %CPU 才 5% 完全正常——很可能一堆进程正卡在磁盘、网络或内核锁上，CPU 反而闲着。
看 wa 值确认 I/O 等待是否拖垮负载
运行 top，盯住 %Cpu(s) 行里的 wa 字段：
- wa > 5%：I/O 瓶颈大概率存在，比如磁盘慢、NFS 挂载卡顿、RAID 重建中
- wa > 30%：几乎可以断定是 I/O 阻塞主导，进程大量处于 D 状态
- wa 很低但 load 很高：先排除 I/O，转向其他原因
查 D 状态进程，揪出“假死”元凶
D 状态（Uninterruptible Sleep）进程不耗 CPU，但会拉高 load，且无法 kill。用这条命令快速定位：
Linux Security Scanner
下载
Linux 安全审计工具，检查 SSH 配置、开放/监听端口、防火墙规则（ufw/iptables/nftables）、失败登录尝试、sudoers 权限...
- 输出里带
D或D 的行就是嫌疑进程 - 重点关注命令名，如
jbd2（ext4 日志）、nfsiod、kswapd0、dd或数据库写操作进程 - 对 PID 执行
cat /proc/[PID]/stack，能看清它卡在哪个内核函数，比如ext4_writepages或nfs_wait_on_request
检查运行队列和上下文切换是否异常
即使没有 D 进程，大量 R 状态（就绪但没抢到 CPU）也会抬高 load：
- 在
top中按1查看各 CPU 核心使用率，是否存在单核打满、其余空闲？说明调度不均或锁争用 - 运行
vmstat 1，观察cs（context switch）列：持续 > 10000 表示频繁切换，可能是短命进程风暴（如每秒 fork 多个日志轮转进程） - 运行
pidstat -t 1，看线程级状态，确认是不是某个应用开了几百个线程却都在等同一把锁
别忽略云环境和内核资源问题
在虚拟机或容器中，还要多看两眼：
- top 中
st（steal time）> 5%：宿主机 CPU 被其他虚拟机抢占，本机进程排队但无 CPU 可用 - 内存严重不足时，
kswapd0可能长期卡在 D 状态回收内存，同时free -h显示可用内存极低 - 内核日志里找线索：
dmesg -T | tail -30或journalctl -k --since "2 hours ago" | grep -i "fail\|timeout"
