Linux vmstat 能看出什么问题？

CPU过载需综合r与id判断：r持续大于CPU核数且id长期低于20%表明瓶颈；r高+wa高则可能为IO阻塞而非CPU不足。

看 CPU 是否过载：重点盯 r 和 id

运行队列长度 r 持续大于 CPU 核数（比如 4 核机器上 r 长期 ≥ 5），说明有进程在排队等 CPU，不是 CPU 不够就是程序卡在某处；id（空闲 CPU）长期低于 20%，配合高 us 或 sy，基本可断定 CPU 瓶颈。但注意：r 短时尖峰（如 1–2 秒）不等于问题，要连续观察 5–10 轮数据。

• vmstat 2 10 比 vmstat 2（无限运行）更可控，避免误操作停不下来
• 若 r 高 + wa（IO 等待）也高，问题可能不在 CPU 本身，而是磁盘慢导致进程卡住释放不了 CPU
• top 或 pidstat -u 1 可进一步定位是哪个进程吃满 CPU

判断内存是否真的不足：别只看 free，要看 swpd、si、so

free 值低≠内存不够——linux 会把空闲内存自动用作 buff/cache，这是正常且有益的行为；真正危险的信号是：swpd > 0 且 si、so 持续非零（比如每秒几百 KB 以上）。这说明内核正在频繁地把内存页换入换出，性能已受损。

• 执行 vmstat -S M 2 用 MB 单位更直观，避免 KB 数值过大干扰判断
• swpd > 0 但 si=so=0？可能是历史交换残留，不一定正在发生压力，需结合 free -h 中 available 列确认真实可用内存
• 若确认是内存不足，优先查 ps aux --sort=-%mem | head -5，而不是直接杀进程或调 drop_caches

发现 IO 瓶颈：从 b、bi/bo、wa 联合看

b（阻塞进程数）持续 > 0，同时 wa > 20%，且 bi/bo 数值大（比如 > 10 MB/s）——这三者齐现，大概率是磁盘 IO 扛不住了。特别注意：bi 高但 bo 很低，可能是大量读缓存未命中；bo 高但 bi 低，可能是日志刷盘或数据库 checkpoint 导致写风暴。

• vmstat -d 2 可查看具体磁盘的读写次数和扇区数，比默认输出更能定位哪块盘拖后腿
• b 高但 bi/bo 很小？可能是 NFS 或其他远程存储响应超时，进程卡在不可中断睡眠（D 状态），此时 ps aux | grep " D " 能抓到它们
• wa 高但 bi/bo 平稳？检查是否有大量同步写（如 fsync 调用）、或使用了慢速存储（机械盘跑随机写）

识别异常系统行为：cs 和 in 突增意味着什么

上下文切换 cs 每秒超过 5000 次（普通服务器），或中断 in 每秒超 2000 次，往往不是负载高那么简单——可能是驱动异常、网卡软中断集中、或某个进程疯狂 fork（查 vmstat -f 对比启动以来总 fork 数）。

• cs 高 + r 低 → 大量非自愿切换，典型如线程数过多、锁竞争激烈（如 java 应用线程池配置失当）
• in 高 + 网络流量不大 → 检查网卡是否启用了 NAPI、是否被错误 IRQ 绑定拉垮单个 CPU
• 仅靠 vmstat 无法定位具体进程，必须搭配 pidstat -w 1（看 per-process 上下文切换）或 cat /proc/interrupts

真实问题往往不是单指标超标，而是多个字段组合暴露矛盾：比如 r 高但 us 很低、wa 很高，说明 CPU 在等 IO；swpd 为 0 但 free 极小、cache 却没下降，那可能是应用自己 malloc 后没 free，vmstat 看不到，得用 pmap 或 gdb 进程堆栈。