linux Troubleshooting
Linux CPU 和 Load Average 过高排查流程
Linux 机器出现 load average 高、top us/sy/wa 异常时，先区分 CPU 使用率高还是 Load 高——CPU 高用 top -H 和 pidstat 找线程，Load 高 CPU 却低就查 iowait、D 状态进程和 steal time，避免盲目重启掩盖真实瓶颈。
先区分 CPU 使用率高还是 Load Average 高。CPU 高看进程和线程，Load 高但 CPU 不高通常要查 IO wait、不可中断睡眠和磁盘/网络阻塞。
Scenario
这篇文章解决什么问题
适用于“Linux CPU 和 Load Average 过高排查流程”对应的线上或本地排障场景。不要只根据最终报错下结论，应先把问题拆成入口、链路、目标服务和资源限制几层，再用命令逐层证实。先区分 CPU 使用率高还是 Load Average 高。CPU 高看进程和线程，Load 高但 CPU 不高通常要查 IO wait、不可中断睡眠和磁盘/网络阻塞。
Symptoms
典型现象
- Linux 机器出现 load average 高、top us/sy/wa 异常时，先区分 CPU 使用率高还是 Load 高——CPU 高用 top -H 和 pidstat 找线程，Load 高 CPU 却低就查 iowait、D 状态进程和 steal time，避免盲目重启掩盖真实瓶颈。
- 相关日志、命令或页面中反复出现 linux、cpu、load 等关键词。
- 同一服务在不同机器、不同入口或不同时间段表现不一致，需要通过证据链缩小范围。
Before Debugging
排查前先确认
- 先确定故障资源：CPU、内存、磁盘、网络、权限、文件句柄还是 systemd 生命周期。
- 区分当前状态和故障发生时状态，事故恢复后 free/top 可能已经看不出根因。
- 任何清理或 kill 操作前先记录 PID、命令行、日志和影响范围。
Root Causes
常见根因分层
资源耗尽或限制过低
磁盘、内存、CPU、load、文件句柄和进程数限制都会让服务表现为启动失败、连接失败或随机超时。
- 先看系统级指标，再看进程级指标
- 确认 systemd/cgroup 限制
- 保留 dmesg/journalctl 历史证据
运行环境和交互 shell 不一致
systemd 服务没有你的 shell 环境变量、工作目录和 PATH；手动能跑不代表服务单元能跑。
- ExecStart 使用绝对路径
- 设置 WorkingDirectory 和 EnvironmentFile
- 修改 unit 后 daemon-reload
文件、权限和句柄生命周期异常
权限不对、文件已删除但仍被进程持有、日志无限增长、fd 泄漏都会造成表象复杂的问题。
- 用 lsof +L1 查 deleted 文件
- 检查目录权限和属主
- 看 /proc/<pid>/limits
Diagnosis Path
分步诊断流程
1. 固定现场，避免追着变化状态跑
先记录故障时间、影响入口、完整错误和最近一次变更。Linux CPU 和 Load Average 过高排查流程 这类问题经常在重启、重试或缓存刷新后短暂消失，没有现场信息会很难复盘。
- 截图或保存完整错误文本
- 记录请求域名/IP/端口/namespace/服务名
- 标出最近发布、配置、证书、镜像或依赖变更
uptime
top -H -p <pid>2. 在故障发生的同一位置复现
很多误判来自测试位置不同：本机通不代表服务器通，容器内通不代表宿主机通，集群外通也不代表 Pod 内通。复现命令要尽量贴近真实流量路径。
- 从报错服务所在机器执行测试
- 必要时加 Host、SNI、namespace 或代理参数
- 把成功路径和失败路径的输出并排比较
top -H -p <pid>
pidstat -u -p ALL 1 5
pidstat -w -p ALL 1 53. 读取服务端证据，而不是只看客户端提示
客户端报错通常是结果摘要。真正能区分根因的是服务端日志、内核日志、事件、进程状态或数据库状态。
- 用 uptime/top 看 load、CPU idle、iowait 和核心数关系。
- 找出占用最高的进程，再切到线程视角确认是否单线程打满。
- 如果 load 高但 CPU idle 也高，重点检查 D 状态进程和 IO wait。
pidstat -u -p ALL 1 5
pidstat -w -p ALL 1 5
vmstat 1 54. 做最小修复并立即回归验证
每次只改一个变量，修复后用同一条复现命令回测，并观察日志是否停止增长。这样可以避免多个临时改动互相掩盖。
- 如果 load 高但 CPU idle 也高，重点检查 D 状态进程和 IO wait。
- 结合最近发布、定时任务、日志暴涨判断是否是业务触发。
- 需要深入时再用 perf、火焰图或应用 profiler，避免一上来盲目重启。
vmstat 1 5
ps -eo pid,ppid,stat,pcpu,comm --sort=-pcpu | headCommands
排查命令与使用意图
命令 1
用于补充“Linux CPU 和 Load Average 过高排查流程”的排查证据链。uptime 的输出需要结合上下文其他命令交叉验证，不要单独依赖某一条结果下结论。
uptime命令 2
用于补充“Linux CPU 和 Load Average 过高排查流程”的排查证据链。top 的输出需要结合上下文其他命令交叉验证，不要单独依赖某一条结果下结论。
top -H -p <pid>命令 3
用于补充“Linux CPU 和 Load Average 过高排查流程”的排查证据链。pidstat 的输出需要结合上下文其他命令交叉验证，不要单独依赖某一条结果下结论。
pidstat -u -p ALL 1 5命令 4
用于补充“Linux CPU 和 Load Average 过高排查流程”的排查证据链。pidstat 的输出需要结合上下文其他命令交叉验证，不要单独依赖某一条结果下结论。
pidstat -w -p ALL 1 5命令 5
用于补充“Linux CPU 和 Load Average 过高排查流程”的排查证据链。vmstat 的输出需要结合上下文其他命令交叉验证，不要单独依赖某一条结果下结论。
vmstat 1 5命令 6
用于补充“Linux CPU 和 Load Average 过高排查流程”的排查证据链。ps 的输出需要结合上下文其他命令交叉验证，不要单独依赖某一条结果下结论。
ps -eo pid,ppid,stat,pcpu,comm --sort=-pcpu | headRisk Notes
容易踩坑的地方
- 生产上不要在来源未确认时 rm -rf 大目录，应先确认目录用途和影响范围。
- kill 进程前先确认它属于哪个服务、是否会触发级联重启，优先使用 SIGTERM 而非 SIGKILL。
- 不要忽略 dmesg 中的 OOM Killer 记录，它往往是应用内存泄漏或配置不当的早期信号。
Verification
修复后怎么确认
- 原始故障现象已经消失，且使用同一入口重新测试 Linux CPU 和 Load Average 过高 能稳定成功。
- 服务端日志不再出现同类错误，监控中的错误率、重启次数、连接数或延迟回到正常区间。
- 如果做过临时绕过，已经记录恢复计划，例如还原宽松策略、补监控、补限制或提交正式配置。
Prevention
后续预防
- 为关键服务配置日志轮转、资源限制和基础监控，避免等到用户报障才发现问题。
- 把 systemd unit、timer 和环境文件纳入版本管理，确保所有变更可追溯可回滚。
- 对清理动作保留可回滚路径，优先移动/截断/轮转，不盲删。
- 建立系统资源基线监控，一旦 CPU、内存、磁盘或文件句柄超过阈值即可自动告警。
常见问题
Load Average 超过 CPU 核数就一定有问题吗？
通常说明排队压力上升，但要结合业务峰值、响应时间、CPU idle 和 iowait 判断。短暂超过不等于故障。
为什么 top 看 CPU 不高但机器很卡？
可能是 IO wait、内存换页、D 状态进程或容器限额导致的调度等待，不是纯 CPU 问题。
Long-tail SEO
你可能正在搜索这些报错
下面这些错误原文、场景词和中英文搜索词，都是排查同类问题时常见的入口。
- Linux load average 高
- Linux CPU load high 排查
- top wa 高 IO wait
- pidstat 查看 CPU
- ps 找 CPU 高进程
- Linux steal time 高
- load average 高但 CPU 不高
- Linux 系统负载突然升高
Need More Help
这个问题还没完全解决？
把你的报错、环境和已经尝试过的步骤发给我，后续会优先补充到排障手册。