Linux 系统性能瓶颈的判断方法

平均负载持续高于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” —— 这时候才能下结论：是那块盘快挂了，而不是应用代码写得烂。