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 进程堆栈。 
