load average反映的是可运行或不可中断睡眠状态的平均进程数，需与逻辑cpu核心数比较判断是否过载：单核>1、四核>4才算真正过载。
Linux CPU负载高，先别急着杀进程。关键看懂 load average 和 %Cpu(s) 这两组数字的含义和关系——它们反映的是不同维度的问题：一个是“有多少活在排队”，一个是“CPU当前干得多快”。搞混就容易误判。
看懂 uptime 和 top 第一行的 load average
执行 uptime 或打开 top，第一行末尾的三个数（如 load average: 2.45, 1.88, 1.32）就是 1 分钟、5 分钟、15 分钟平均负载。
- 它统计的是**过去一段时间内，处于“可运行”（R）或“不可中断睡眠”（D）状态的平均进程数**，不是 CPU 使用率
- 判断是否过载，要和逻辑 CPU 核心数比：
— 单核：load > 1 就算忙；
— 四核：load > 4 才算真正过载；
— 更稳妥的经验值：load / CPU核数 - 如果 1 分钟值远高于 15 分钟值（比如
5.2, 1.1, 0.9），说明负载是突发的，刚冲上来，要立刻查当前活跃进程
区分 CPU 使用率（%Cpu）和负载（load）
top 第三行的 %Cpu(s): 32.1 us, 8.4 sy, 0.0 wa, 59.2 id 描述的是 CPU 时间分配，而 load 是任务队列长度。
- us（user）高：业务代码、应用进程占 CPU 多，比如 Java/Python 程序计算密集
- sy（system）高：内核态耗时多，常见于频繁系统调用、上下文切换、大量 fork/exec
-
wa（iowait）高：CPU 在等磁盘 IO，但此时 load 可能不高（因为进程在 D 状态），
iostat -x 1配合看 -
id 很低 + r 值大：
vmstat 1中的r列（运行队列长度）持续大于 CPU 核数，说明真有大量进程抢 CPU
快速定位高负载源头的 top 操作
进 top 后不用退出，直接交互操作：
- 按 P（大写）：按 CPU 使用率降序，一眼看到“罪魁”
- 按 1：展开显示每个逻辑 CPU 的使用率，确认是否单核打满（常见于单线程服务）
- 按 H：切换线程视图，Java 进程里某个线程飙高，
top -H -p PID再配合jstack定位栈 - 按 U：输入用户名，只看某用户下的进程，适合隔离排查（如只看 www-data）
- 按 i：隐藏 idle 进程，让界面更聚焦活跃者
辅助验证与交叉检查命令
单靠 top 容易漏掉历史趋势或隐藏瓶颈：
-
vmstat 1 5：看r（运行队列）、b（阻塞）、wa（IO等待）三列，综合判断是 CPU 争抢还是磁盘拖慢 -
mpstat -P ALL 1：确认是否不均衡——某个 CPU 核 99%，其余都在 10%，那大概率是单线程瓶颈 -
pidstat -u 1 5：按进程/线程维度输出 CPU 使用明细，比 top 更稳定，适合脚本采集 -
dmesg | grep -i "oom\|kill"：排除被内核 OOM killer 杀掉进程导致的连锁反应
基本上就这些。load 高 ≠ CPU 忙，CPU 使用率高 ≠ 一定是程序写得差——结合队列、IO、线程、日志交叉看，才能准确定位。不复杂但容易忽略。
