生产服务器的 load average 持续升高，但 top 中 CPU 仍有大量 idle，这通常不是计算能力不足。Linux 负载包含可运行任务，也会受到不可中断睡眠任务影响；磁盘、NFS、云盘或内核 I/O 路径阻塞时，进程可能进入 D 状态并推高负载。
一、确认负载是否持续异常
date
uptime
cat /proc/loadavg
nproc
vmstat 1 10将 1、5、15 分钟负载与 CPU 核数对比，并观察趋势。单次采样不能说明问题；刚结束的突发任务也可能让 15 分钟负载暂时较高。
二、区分 CPU 忙还是任务等待
top
mpstat -P ALL 1 10
pidstat -u -r -d -w 1 10关注 %us、%sy、%wa、%st 和 idle：
user/system 高：继续定位 CPU 消耗进程。
iowait 高：检查块设备和存储延迟。
steal 高：虚拟机可能被宿主机争抢 CPU。
CPU idle 高但 load 高：重点查 D 状态任务、锁和短时任务堆积。
三、找到 D 状态进程
ps -eo state,pid,ppid,wchan:32,etimes,cmd | awk '$1 ~ /^D/'
ps -eo pid,ppid,stat,wchan:32,comm --sort=statSTAT 为 D 表示任务正在不可中断等待，常见于块设备、NFS、FUSE 或驱动调用。记录 PID、父进程、持续时间和 wchan。
具有 root 权限时，可以检查单个进程：
cat /proc/<pid>/stack
cat /proc/<pid>/wchan
ls -l /proc/<pid>/fd | head不要对生产环境所有 PID 无限制遍历 /proc/*/stack，这会产生大量输出，也可能掩盖关键证据。
四、检查磁盘与块设备
iostat -xz 1 10
lsblk -o NAME,TYPE,SIZE,FSTYPE,MOUNTPOINTS
df -hT
df -ih
dmesg -T | grep -Ei 'I/O error|timeout|reset|blk_update|nvme|scsi|ext4|xfs' | tail -n 100重点看 await、队列、设备利用率和错误日志。高利用率不一定等于故障，必须结合延迟、吞吐基线和业务类型判断。云盘还要检查 IOPS、吞吐额度及 burst credit。
五、检查 NFS 与远程存储
findmnt -t nfs,nfs4
nfsstat -m
nfsstat -c
mount | grep -E ' nfs| nfs4'如果 D 状态进程的工作目录或文件描述符位于 NFS，检查服务端、网络、DNS 和挂载参数。硬挂载 NFS 在服务端不可用时可能让进程长时间等待，这是数据安全设计的一部分，不要直接更改为软挂载来掩盖故障。
六、检查内存回收与 PSI
free -h
vmstat 1 10
cat /proc/pressure/cpu
cat /proc/pressure/io
cat /proc/pressure/memory持续的 memory pressure、swap in/out 或 direct reclaim 也会拖慢任务。PSI 能帮助判断任务因为 CPU、I/O 或内存资源不足而停顿的比例。
七、应急处理步骤
保存
ps、vmstat、iostat、内核日志和故障时间。判断阻塞源是本地盘、云盘、NFS、数据库盘还是驱动。
对业务入口限流或切流，防止新请求继续形成 D 状态堆积。
存储恢复后观察进程是否自动恢复，不要连续发送
kill -9。单节点无法恢复时，通过控制台做受控重启；重启前必须确认数据一致性、集群副本和文件系统风险。
D 状态进程通常无法被信号立即终止，因为它在等待内核操作完成。大量 kill -9 既不能解决底层 I/O，也会破坏现场。
八、长期治理
监控 load、D 状态数量、PSI、磁盘延迟和内核 I/O 错误。
为云盘 IOPS、吞吐和容量预留峰值空间。
NFS、分布式存储和本地盘分别建立可用性探测。
应用设置合理超时与并发上限，防止故障时无限堆积线程。
对关键节点保留控制台和故障转移能力。
“负载高”只是结果。真正有效的排查是找到任务在等什么，以及那个依赖为什么迟迟没有返回。