系统 / Linux更新于 约 4 分钟阅读 · 执行耗时因环境而异
Linux Load Average 飙高：CPU、I/O 和不可中断任务的判断
Load Average 不等于 CPU 使用率。它也包含等待 I/O 的不可中断任务，必须结合运行队列、iowait 与进程状态判断。
维护者 Kevin · Ovalk
适用范围与前提
适用于 Linux 主机级诊断；容器 CPU 限额可能与主机核数不同。iostat 通常由 sysstat 提供，PSI 可用性取决于内核配置。
记录时间窗口、工作负载及正常基线。采集多个间隔，不要仅依赖第一份累计统计；诊断权限不等于允许终止进程或重启存储客户端。
示例不是可以直接粘贴的指令。请替换示例域名、路径、服务名和大写占位符。先收集证据；重载、回滚、清理及执行任务会改变系统状态，需批准影响范围与恢复计划。不要分享凭据或未脱敏日志。
常见症状
- 负载远高于 CPU 核数
- 接口延迟升高但 CPU 利用率不高
- 大量进程状态为 D
1. 建立一分钟现场快照
在做重启或扩容前收集 uptime、CPU、内存、磁盘延迟和进程状态。高 load 但低 CPU 常指向磁盘、NFS、网络存储或内核等待，而非单纯算力不足。
uptime
vmstat 1 5
iostat -xz 1 5
ps -eo state,pid,ppid,comm,wchan:32 --sort=state | head -n 302. 区分 CPU 饱和与 I/O 堵塞
CPU 饱和时找占 CPU 的进程和热点调用；iowait 高时检查磁盘队列、设备错误、文件系统和远程存储。D 状态任务不可被普通信号终止，先修复其等待的资源。
top -b -n1 | head -n 25
dmesg -T | tail -n 803. 恢复时避免扩大雪崩
限流、暂停批处理或摘流比杀死大量进程更可控。若需要重启节点，先确认副本和连接迁移方案；重启后用同一组指标验证瓶颈是否消失。
systemctl list-jobs
cat /proc/pressure/io解读证据
| 观察结果 | 下一步检查 |
|---|---|
| 运行队列长且 CPU 忙 | 调查计算需求及容器限流，对照工作负载实际可用 CPU，而非固定通用阈值。 |
| D 状态及存储压力 | 将等待位置与设备或远程文件系统健康关联。D 状态是不可中断睡眠，重复终止进程不能修复等待的资源。 |
| 服务恢复后负载仍高 | 负载是时间平均值；应结合当前延迟、队列采样和压力信号区分历史影响与持续故障。 |
说明性诊断案例
以下假设案例用于解释推理，并非客户真实事故，也不代表已在你的技术环境中测试。
一台八核主机负载达到 30，但 CPU 大多空闲；多个工作进程处于 D 状态，存储延迟同时上升。增加 CPU 无法解除存储等待。先通过服务控制降低新增工作，调查存储路径，依赖恢复后再对照相同指标。
验证恢复
- 在同一观察窗口对照应用延迟、错误率、CPU 队列、I/O 延迟和 PSI。
- 逐步恢复流量或批处理，确认压力不会立即返回；空闲节点不能证明容量充足。
回滚与停止条件
限流与并发变更应可回退。任何重启前确认健康副本及存储恢复行为；缺少故障转移容量时，应停止重启计划。
预防与长期修复
- 为 CPU、iowait、磁盘队列和 PSI 同时建立观测。
- 批处理任务加并发上限与错峰。
- 为存储依赖建立可用性和延迟 SLO。
参考资料与纠错
请使用与你安装版本匹配的文档。以下资料解释基础行为，命令仍需结合实际环境验证。
向 Kevin 提交更正，请附页面地址、版本与脱敏复现步骤。请查看编辑原则（英文）。