平均负载持续高于CPU核心数表明系统资源排队，需结合vmstat、iostat、iotop和dmesg交叉验证瓶颈类型：r值高为CPU饱和，wa高+bi/bo大为I/O瓶颈，si/so非零为内存不足，%util高且await异常指向磁盘故障。
看平均负载是否超过 CPU 核心数
平均负载不是 CPU 使用率，而是单位时间内“活跃进程数”的平均值——包括正在跑 CPU 的（R 状态）和卡在不可中断 I/O 的（D 状态）。uptime 输出的三个数字（1/5/15 分钟）若持续高于 grep -c ^processor /proc/cpuinfo 的结果，说明系统已排队等资源，哪怕 top 显示 CPU idle 90%，也可能是磁盘在拖慢整个队列。
- 1 分钟负载突高 + 15 分钟低 → 紧急事件刚发生，立刻查
vmstat 1中的r（运行队列）和b（阻塞进程） - 负载高但
us和sy很低、wa>20% → 八成是磁盘 I/O 卡住，不是 CPU 真忙 - 负载高且
r值长期 > CPU 核数 → 确认 CPU 饱和，下一步盯进程级消耗
用 vmstat 一眼识别三类瓶颈特征
vmstat 1 3 是最轻量、信息密度最高的综合快照。它不告诉你“哪个进程”，但能立刻排除或锁定瓶颈类型：
-
r > CPU核数且id很低 → CPU 瓶颈（注意区分us高还是sy高） -
si或so持续 > 0 → 内存不足，开始 swap，性能断崖下跌 -
wa高 +bi/bo大 → I/O 等待严重，此时iostat -x 1必须跟上 - 别只看
free列：Linux 的available（可用内存）比free更真实，free -h才是正确姿势
定位具体设备与进程：从 iostat 到 iotop
当 iostat -dx 1 显示某块盘 %util ≥ 95% 且 await > 10ms（机械盘）或 > 1ms（SSD），就确认是这块设备拖了后腿。但光知道设备不够，得找到“谁在狂写”：
-
iotop -o只显示当前有 I/O 的进程，比top更精准；注意看IO>列，不是PR或%CPU - 如果
iotop里看不到明显大户，但iostat持续高压 → 可能是内核行为（如日志刷盘、ext4 journal、kswapd 频繁换页），需结合dmesg -T | tail -20排查 - SSD 上
%util接近 100% 不一定真饱和（NVMe 支持深度队列），要重点看avgqu-sz是否长期 > 1，这才是真实排队长度
别跳过内核级线索：dmesg 和 pidstat 补盲
很多瓶颈不会在 top/iostat 里显形，但会留下内核痕迹。比如 OOM Killer 杀进程、磁盘超时、驱动报错，全藏在 dmesg -T 里；而 pidstat 能补上 top 缺失的维度：
-
dmesg -T | grep -i "killed process\|timeout\|error"—— 一查就知道有没有被内核强制终止过进程 -
pidstat -d 1比iotop更稳定（不依赖 /proc 文件系统实时性），还能看到每个进程的读写 KB/s 和 IO 等待时间 -
pidstat -u 1可以验证某个进程是否真占 CPU，避免被top的采样抖动误导（比如短时脉冲型占用）
真正卡住系统的，往往不是单个指标爆表，而是多个信号交叉印证：比如 vmstat 显示 wa 高 + iostat 显示某盘 %util 高 + iotop 看到某进程在持续写 + dmesg 里有 “end_request: I/O error” —— 这时候才能下结论：是那块盘快挂了，而不是应用代码写得烂。
