下面从核心认知纠偏、核心命令速查表、标准排障全流程、高频踩坑经验四个维度分享，都是生产环境反复验证的落地经验，照着走就能快速定位绝大多数负载问题。
一、核心实战认知：先搞懂「负载到底是什么」，避免瞎排查
很多新手排障的第一个误区，就是把「负载高」等同于「CPU 满了」，实际上负载高的成因有三类，排查方向完全不同。
1、Load Average 不是 CPU 使用率
它统计的是「正在 CPU 运行 + 等待 CPU 调度 + 不可中断睡眠（通常等 IO）」的进程总数。
负载高 ≠ CPU 满：最典型的就是 IO 瓶颈场景，CPU 很空闲（idle 很高），但大量进程在等磁盘读写，负载照样飙升。
趋势比绝对值重要：1 分钟 > 5 分钟 > 15 分钟 → 压力正在上涨；反之则在缓解。
经验阈值：长期超过物理核心数的 80% 属于高负载，需要重点关注。
2、CPU 各字段对应故障方向
us（用户态）高：业务程序计算量大、死循环、代码效率低，优先排查应用层。
sy（内核态）高：系统调用频繁、上下文切换过多，常见于大量短连接、频繁创建销毁线程。
wa（IO 等待）高：磁盘 / 网络 IO 阻塞，进程在等 IO 完成，是最容易被误判的场景。
si（软中断）高：大量网络收发包、TCP 连接爆炸，常见于高并发 Web、流量攻击。
3、内存不是 used 高就告警
二、生产高频命令速查表
按排查场景分类，拿来就能用，不用背参数。
【1. 整体负载速查】
# 1秒看负载趋势与系统运行时长uptime# 静态输出系统整体状态（适合脚本调用、快速截图留存）top -bn1 | head -20# 10秒定位瓶颈类型（CPU/IO/上下文切换），每秒1次共输出5次vmstat 1 5# 回看历史负载（排查过去时间段的故障，需系统开启sar服务）sar -q -f /var/log/sa/sa$(date +%d -d yesterday)
【2. CPU 深度排查】
# 查看所有CPU核心状态，快速定位单核心打满的情况mpstat -P ALL 1# 按进程统计CPU使用率，每秒刷新，比top更精准pidstat -u 1# 按CPU占用降序，取Top10进程ps aux --sort=-%cpu | head -10# 查看线程级CPU占用，定位多线程程序的热点线程ps -T -p <PID> --sort=-%cpu | head -10
【3. 内存排查】
# 最直观的内存概览free -h# 内核级最详细的内存细节cat /proc/meminfo# 按进程统计内存占用，每秒刷新pidstat -r 1# 按内存占用降序，取Top10进程ps aux --sort=-%mem | head -10# 查看进程内存映射，辅助定位内存泄漏pmap -x <PID>
【4. 磁盘 IO 排查】
# 磁盘详细IO指标，重点看%util、await、svctmiostat -x 1# 实时查看哪个进程在占用IO，只显示正在进行IO的进程iotop -oP# 按进程统计IO读写速率pidstat -d 1# 定位「删除未释放」的文件（解决df和du结果不一致的经典问题）lsof | grep deleted# 快速定位当前目录Top10大目录du -sh * | sort -hr | head -10
【5. 网络相关负载排查】
# 查看TCP连接整体状态，快速判断连接数是否异常ss -s# 查看网卡实时流量，定位带宽打满sar -n DEV 1# 查看指定端口的连接详情ss -antp | grep :8080# 排查软中断CPU占用mpstat -P ALL 1
【6. 进程深度调试】
# 树形展示进程父子关系，快速定位进程爆炸ps auxfpstree -p# 查看进程打开的所有文件、端口、句柄lsof -p <PID># 跟踪进程系统调用，定位程序卡死、无响应的原因strace -tt -p <PID># 统计进程系统调用耗时分布strace -c -p <PID>
三、负载过高标准排障全流程（Step by Step）
新手照着一步步走，就能从「接到告警」定位到具体根因，不会乱排查。
步骤 1：确认现状与趋势，判断严重程度
执行 uptime，对比 1/5/15 分钟负载，判断压力是上升还是下降；
用 nproc 查看 CPU 核心数，评估负载水位；
如果是历史故障，用 sar -q 回溯故障发生时间点的负载变化，确认故障开始时间。
步骤 2：10 秒定位瓶颈类型（最核心一步）
执行 vmstat 1 5，重点看 4 列，直接分出大类：
r 列（运行队列）：持续大于 CPU 核心数 → CPU 计算瓶颈
b 列（不可中断进程）：持续大于 0 → IO 阻塞瓶颈
cs 列（上下文切换）：突发飙升 → 进程 / 线程频繁创建销毁，或大量短连接
配合us/sy/wa进一步确认 CPU 消耗类型
实战经验：90% 的负载高都能在这一步定方向，不用上来就漫无目的地翻日志、杀进程。
步骤 3：针对性深入定位进程
场景 A：CPU 密集型（r 列高、us/sy 高）
pidstat -u 1 找出 CPU 占用最高的进程 PID；
ps -T -p <PID> 定位具体是哪个线程在消耗 CPU；
结合业务日志、jstack/gdb 等工具分析代码，排查死循环、计算密集逻辑。
场景 B：IO 密集型（b 列高、wa 高、idle 高）
iostat -x 1 确认是哪块磁盘繁忙，看%util（磁盘繁忙度）、await（IO 平均耗时）；
iotop -oP 或 pidstat -d 1 找出高 IO 的进程；
区分读写类型：写多通常是日志刷盘、数据库写入；读多通常是缓存失效、大量随机读；
lsof -p <PID> 确认进程在读写哪些文件。
场景 C：内存不足导致负载高
free -h 看 available 是否不足、Swap 是否持续上涨；
pidstat -r 1 找出内存占用最高的进程；
观察内存走势：持续上涨不回落大概率是内存泄漏，平稳高位可能是业务正常容量不足。
场景 D：软中断导致 CPU 高（si 高）
mpstat -P ALL 1 确认软中断占比；
sar -n DEV 1 看网卡流量，确认是否带宽打满；
ss -s 看 TCP 连接数，排查连接数爆炸、CC 攻击。
步骤 4：根因确认与应急处理
四、高频踩坑与实战经验总结
D 状态进程杀不掉，不要硬 kill -9：不可中断睡眠状态的进程，强制杀也没用，还可能引发数据异常，优先解决 IO 根源。
别把 buffer/cache 当内存占用：很多新手看到 used 很高就慌，实际上 cache 是系统主动使用的，业务需要时可以回收，看available才准确。
TIME_WAIT 多不是故障：这是 TCP 正常回收状态，只要不是几万级别的暴涨，不用优化；CLOSE_WAIT过多才是应用代码没主动关闭连接的 bug。
df 和 du 结果不一致：几乎都是文件被删除，但进程还持有文件句柄，空间没释放。用lsof | grep deleted定位，优雅重启进程即可，不要反复删文件。
单线程程序会出现「CPU 整体不高但负载高」：程序只能用一个核心，打满单核后运行队列积压，整体 CPU 占比低但负载上升，属于正常现象。
生产环境不要长时间 strace：会显著拖慢目标进程性能，定位到问题立即退出，核心高并发服务慎用。
优先用 ss 不用 netstat：连接数上千时 netstat 会遍历 /proc 卡死，ss 直接读取内核状态，速度快几个量级。
排障一定要留痕：重要故障把命令输出保存下来，方便事后复盘，不要查完就关闭窗口。
