服务器明显变慢，top 里的Load Average已经飙到十几，CPU使用率却没有到100%。这并不是监控互相矛盾，而是负载和CPU占用衡量的东西本来就不同。
Linux负载除了包含等待CPU运行的任务，还会受到不可中断等待任务的影响。磁盘、网络存储或内核资源卡住时，进程没在消耗多少CPU，负载照样可能持续上涨。
先把负载和CPU占用分开理解
先查看当前负载、CPU核心数和运行队列：
uptime
nproc
cat /proc/loadavgLoad Average的三个数字分别反映最近1分钟、5分钟和15分钟的平均负载。单看数字大小没有意义，4核服务器负载为4和1核服务器负载为4，压力完全不同。
/proc/loadavg 中斜杠前的数字是当前可运行任务数，适合与长期平均值一起看。负载高只说明任务在排队或等待，不能直接等同于CPU已经跑满。
用top确认CPU时间花在哪里
执行下面的命令并观察一段时间，不要只截取某一秒：
top
vmstat 1 10CPU空闲值仍然很高，但负载持续上升时，应重点看 wa 和 st。wa 可作为I/O等待的线索，st 较高则可能说明虚拟机的CPU时间被宿主机占用。
内核文档也提醒，iowait并不是一个能单独定案的精确指标。它需要和阻塞进程、磁盘延迟及业务日志一起判断，不能只因 wa 高就认定硬盘损坏。
找出D状态进程
不可中断睡眠通常显示为D状态。可以先列出当前状态为D的进程：
ps -eo state,pid,ppid,wchan:32,comm,args | awk '$1 ~ /^D/'短暂出现一两个D状态任务并不罕见，真正需要关注的是同一批进程长时间停留、数量不断增加，并且与负载曲线同步。wchan 能提供任务正在内核中等待的位置，但符号含义需要结合系统版本判断。
不要直接反复执行kill -9。 D状态进程通常要等内核操作返回后才会响应信号，强制发送信号既不能解除底层等待，也可能在恢复时造成数据未完整处理。
检查磁盘延迟而不是只看使用率
系统安装了sysstat时，可以查看设备延迟和队列：
iostat -xz 1 10重点比较业务磁盘的读写延迟、队列长度和持续繁忙程度。某块盘长时间延迟升高，同时Web、数据库或日志进程进入D状态，才形成比较完整的I/O瓶颈证据。
磁盘空间写满、inode耗尽、云盘性能额度触顶、文件系统错误和网络存储抖动，都可能表现为I/O变慢。此时应继续检查 df -h、df -i、内核日志及云平台磁盘监控，而不是立刻调大应用线程数。
排除内存回收和交换分区压力
内存紧张时，大量页面回收和Swap读写也会拖慢任务。可以结合下面的数据观察：
free -h
vmstat 1 10
cat /proc/pressure/io
cat /proc/pressure/memoryvmstat 中持续出现较高的 si、so，说明系统正在频繁换入换出。PSI数据则能帮助判断任务因I/O或内存压力被阻塞的时间比例，适合和业务卡顿时间对照。
直接清空缓存通常只能让数字短暂变化，还可能增加后续磁盘读取。先找出持续增长的进程、缓存用途和实际Swap活动，再决定限制进程、优化查询还是增加内存。
虚拟机还要看steal和宿主机影响
云服务器里 st 长时间偏高，说明虚拟CPU没有拿到预期的执行时间。此时本机进程并未把CPU用满，应用仍会感觉响应变慢，负载也可能积累。
先保留同一时间段的 top、vmstat 和应用响应数据，再与云平台监控对照。单次尖峰可能来自宿主机调度，持续异常则需要联系服务商核查或迁移实例。
旧实例已经叠加磁盘性能、内存和宿主机争用等多重变量时，可以在 萤光云 创建相近规格做对照，也可以借助按小时计费的 LightNode 保留短期并行环境。对照时要使用同一系统版本、相同业务压力和相同监控窗口，否则快一点并不能说明根因已经找到。
修复后怎么确认负载真的恢复
完成磁盘、内存或实例调整后，至少观察一个完整业务高峰。Load Average应逐步回落，D状态任务不再持续堆积，磁盘延迟、Swap活动或steal值也应同步改善。
最后从用户侧检查页面响应、接口耗时和后台任务，确认不是仅把监控数字压低。负载下降、等待证据消失、业务延迟恢复三者同时成立，才算排查闭环。
常见问题
Load Average超过CPU核心数就一定有问题吗？
不一定。短时突发可以被系统快速消化，需要结合持续时间、运行队列和业务响应判断。长期高于核心数且请求变慢，才值得进一步定位。
D状态进程能直接重启服务器解决吗？
重启可能暂时清掉等待任务，但会中断业务，也可能掩盖磁盘或存储故障。先保存日志和设备证据，确认无法恢复时再安排维护窗口。
iowait为0就能排除磁盘问题吗？
不能。iowait本身有统计边界，还可能受多核调度影响。应结合D状态、iostat、PSI和内核日志一起判断。
