Linux 服务器负载高怎么查：看懂 load average 并定位元凶进程

收到告警“负载过高”，很多人第一反应是看 CPU 使用率，结果 CPU 才 30%——负载高 ≠ CPU 忙。这篇讲清 load average 的含义，以及一套从告警到定位元凶的完整路径。

load average 到底在量什么
uptime 输出的三个数字（1/5/15 分钟）是“可运行进程 + 不可中断睡眠进程（D 状态）”的平均数。关键点：D 状态进程也计入负载——所以磁盘 IO 卡住时 CPU 明明空闲，负载照样飙高。经验判断：load 持续超过 CPU 核数才算高（4 核机器 load 6 才需要紧张），且要看趋势，15 分钟值高于 1 分钟值说明在缓解。

四步定位法
1. 先分清瓶颈类型：top 按 1 展开各核，看 %wa（iowait）——高 iowait 基本是磁盘/存储瓶颈；
2. CPU 忙：top 里 P 按 CPU 排序找元凶，再用 pidstat -u 1 观察波动，配合 top -H -p <pid> 看线程，Java 应用常配合 jstack 看线程在忙什么；
3. D 状态堆积（IO 瓶颈）：ps -eo state,pid,cmd | grep "^D" 找卡住的进程，iostat -x 1 看 %util 与 await——哪个盘 %util 接近 100% 就是它；
4. 内存不足引发的连锁：free -h 看 available，swap in/out 频繁说明在颠簸，负载升高只是表象。

常见误判
1. 一核机器 load 3 就很糟，32 核机器 load 3 完全健康——必须除以核数再判断；
2. 只看 CPU 指标，漏掉 NFS/云盘抖动导致的 D 状态堆积（云服务器常见，尤其共享型存储）；
3. 告警恢复就不管了——应保留 sar/atop 历史，复盘当时的进程画像。

一句话总结：先看 %wa 分流 CPU 型还是 IO 型，CPU 型找线程，IO 型找盘，内存问题看 swap。工具链：uptime → top → pidstat/iostat → ps -D。