Linux 负载高但 CPU 不高？load average 与 iowait 排查
“load 到十了，CPU 却只有二十多”，这不一定是监控坏了。Ubuntu 24.04 上的负载平均值、CPU 使用率和磁盘等待统计描述不同事情。排查的关键不是寻找一个通用的危险数字，而是确认哪些任务在排队、等待什么，以及是否已经影响用户请求。
负载平均值不是 CPU 百分比
load average 是一段时间内可运行任务与不可中断等待任务的平均数量，不能直接读成百分比。它通常显示短、中、长几个时间窗口，反映变化趋势。对有多个可用 CPU 的机器，必须结合可用计算资源与工作负载解释。
即使负载低于逻辑 CPU 数，也不保证所有业务都没有瓶颈。某个串行关键线程可能已经满载，其他核却很空闲；相反，大量等待 I/O 的任务能把负载推高，而 CPU 并没有忙于计算。Linux /proc 文档说明了相关统计来源。
连续采样，别只截取一瞬间
在故障正在发生时运行：
# Ubuntu 服务器，只读观察
uptime
nproc
vmstat 1 10
top
记录发生时段和业务动作。vmstat 第一份报告中不少速率数据反映启动以来的平均情况，后续报告才对应指定采样间隔，因此不要把第一行当成当前一秒的现场。top 可以继续观察进程和每核变化，按 q 退出不会结束业务进程。
如果平台对 CPU 有配额或容器限制，nproc 等工具展示的数量也要与实际配额对照。整机可见多少 CPU，不一定等于某个服务在当前限制下可以持续获得多少计算时间。
把运行队列与阻塞队列分开看
vmstat 的 r 反映可运行任务，b 反映等待 I/O 完成的阻塞任务。r 长时间偏高并伴随 CPU 忙碌，可以继续分析计算竞争；b 增长则应结合磁盘、远程文件系统或其他内核等待情况检查。vmstat 手册解释了各列及采样行为。
单个进程出现 D 状态，不足以立即断言物理磁盘损坏。要核对进程在访问什么资源，是否有网络存储、设备错误或短时维护任务。不要为了降低负载数字而强制结束不明进程，尤其是正在写数据库或文件系统的任务。
iowait 是线索，不能单独定位磁盘
iowait 常被简化成“CPU 等硬盘的时间”，但多核环境的统计归属存在局限。内核文档明确提醒其数值不能作为绝对可靠的独立依据。高 iowait 可以提示继续观察 I/O，低 iowait 也不能排除个别请求在磁盘上等待。
把指标与应用耗时、存储延迟、吞吐及错误日志结合，才能缩小范围。有时缓存命中变化导致读盘增加，有时备份和业务争用同一设备。只更换更快的 CPU，未必能处理这些问题。
虚拟机还要注意 steal 等指标是否持续变化，并与服务方约定的 CPU 资源边界对照。一次短暂变化不是主机超售的充分证据，不应据此写出未经验证的结论。
根据证据选择调整并复测
如果是计算型并发挤压关键请求，可以调整并行度、任务时段或评估更合适的 CPU；如果是某次导出占用 I/O，则先考虑错峰、限速或存储方案。一次只改一个主要变量，保留原配置和同一负载下的对照结果。
验证时看关键请求成功率、响应时间和任务完成时间，负载数字只是辅助。调整任务并发后，要确认积压是否真的消化，而不是把工作推迟到监控窗口之外。恢复原设置的方式也应事先记录，避免一次排障变成无法解释的多项参数变更。
若已经出现长时间不可中断等待或设备错误，应先保护数据、收集日志，再按存储故障流程处理，不通过反复重启来证明系统“暂时好了”。