场景概述
负载持续高于核数只是现象，背后可能是三类完全不同的等待：确实有任务在排队等 CPU（运行队列长、us 或 sy 高）、大量进程卡在 D 状态等 IO（wa 高、磁盘 await 大）、以及锁竞争或频繁上下文切换造成的开销（cs 高、sy 偏高）。三者的处置方向分别是减少计算、解决存储、优化并发模型，先分辨类型再动手，否则很容易在错误的方向上优化代码。
场景信息
| 触发条件 | load average 持续高于逻辑核数，或业务响应明显变慢 |
|---|---|
| 排查目标 | 定位瓶颈类型与对应的具体进程，避免在错误方向优化 |
| 工具链 | uptime 与 nproc 建基线 → vmstat 分辨类型 → top/pidstat 定位进程 → iostat/iotop 确认存储侧 |
| 采样原则 | load 的 5 分钟与 15 分钟平均值滞后于瞬时问题，抓现场用 1 秒级采样（vmstat 1、pidstat 1） |
三类负担的判据
- CPU 排队：vmstat 的 r 列持续大于核数，us 或 sy 接近满载，进程状态多为 R
- IO 等待：wa 明显偏高、r 不高但 b 列有值，iostat 的 await 与 util 都很高，进程状态多为 D
- 切换与锁：cs 每秒数值异常高、sy 偏高，pidstat -w 能看出切换集中在某些线程
- 虚拟化抢占：us 不高但 st 明显，负载升高而实际计算量没变，属于宿主层资源竞争
- 内存压力：available 偏低、si 与 so 持续非零，换页本身就会推高负载
四步定位命令
四步定位命令
# 第 1 步：基线——负载与核数一起看
uptime; nproc
vmstat 1 5 | tail -n +2
# 第 2 步：分辨类型（r 大=CPU 排队，wa 高=IO，cs 高=切换）
vmstat 1 5
# 第 3 步：定位具体进程
ps aux --sort=-%cpu | head -15
top -b -o %CPU -n 1 | head -n 20
pidstat -u 1 3 | sort -k8 -rn | head
pidstat -w -t 1 3 | sort -k5 -rn | head # 切换高的线程
# 第 4 步：若是 IO 侧，确认存储
iostat -xz 1 3
iotop -o -b -n 2 | head -n 20
ps -eo stat,pid,comm | awk '$1 ~ /D/' | head # 卡在 D 状态的进程vmstat 关键列
| 列 | 含义 | 判断方向 |
|---|---|---|
| r | 等待运行的进程数 | 持续大于核数说明 CPU 是瓶颈 |
| b | 不可中断睡眠进程数（多在等 IO） | 大于 0 且 wa 高说明存储拖后腿 |
| si / so | 从 swap 换入 / 换出的速率 | 持续非零说明内存压力已影响性能 |
| us / sy | 用户态与内核态 CPU 占比 | sy 偏高常见于系统调用密集与切换开销 |
| wa | 等待 IO 的 CPU 占比 | 偏高时 CPU 实际空闲，别去优化计算 |
| cs | 每秒上下文切换次数 | 异常高说明并发过度或锁竞争严重 |
负载包含不可中断睡眠的进程，所以「IO 等待型」负载升高时 CPU 使用率反而可能很低。看到负载高而 CPU 空，直接转去查 D 状态进程、iostat 的 await/util 与存储侧告警，比在应用代码里找理由有效。
虚拟化环境要多看一个变量：st（steal）表示被宿主机抢占的时间比例。st 明显升高时，同一台机器在物理机上表现正常，搬到云上就变慢，这属于资源竞争问题，扩容本机 CPU 不一定有效，需要与云厂商核对配额与规格。
不要用 top 的瞬时快照下结论：负载的 5 分钟与 15 分钟平均值天然滞后，突发型问题需要 1 秒级采样（vmstat 1、pidstat 1）连续观察几分钟，或用监控系统回看历史曲线，才能确认是持续瓶颈还是短时尖峰。
先判断突发还是持续：备份、报表、批处理这类定时任务会自己结束，若负载在固定时间点升高并在可预期的时间内回落，优先级远低于持续高位。用 1 秒级采样连续观察数分钟，或回看监控曲线，再决定是当天处理还是排期治理。
定位高负载的核心是分清三类负担：等着 CPU 执行、等着存储完成、以及被其他执行单元占用而无法前进。三者的处置手段完全不同，判断顺序是先看运行队列与上下文切换，再看存储等待，最后确认是否被外部环境抢占，方向选错会白花很多时间。