Linux性能监控需联动top、vmstat、iostat：top定位高CPU、高%wa或内存换页异常；vmstat观察r、si/so、bi/bo判断资源流转失衡；iostat -x分析await、avgqu-sz、%util等锁定磁盘根因。
Linux性能监控不是看单个命令输出，而是把 top、vmstat 和 iostat 的数据串起来看——它们分别盯住 CPU、内存与进程调度、磁盘 I/O 三个关键维度，合起来才能判断瓶颈在哪。
用 top 快速定位“谁在吃资源”
top 是第一眼扫描工具，重点不是看实时刷新的数字，而是抓住三类异常信号：
- CPU 使用率长期 >80%，且 %us（用户态） 高 → 可能是某个应用进程跑满核，按 P 排序找高 %CPU 进程
- %wa（I/O wait） 持续 >20% → 表明 CPU 在等磁盘响应，此时要立刻切到 iostat 查磁盘队列和 await
- RES 内存占用大 + %MEM 高，同时 SWAPIN/SWAPOUT 活跃 → 内存不足开始换页，需结合 vmstat 的 si/so 字段确认
用 vmstat 把握系统级资源流转节奏
vmstat 1 10（每秒采样 10 次）比单次快照更有价值，它揭示的是资源“流动”是否失衡：
- r 列（运行队列长度） > CPU 核数 × 2 → 说明有大量进程在排队等 CPU，即使 %us 不高，也可能是 I/O 或锁导致阻塞
- si/so 列持续非零 → 真实发生内存换入换出，不是 swap 分区空闲就代表内存够用
- bi/bo 列值很大（比如 >10MB/s），但 iostat 显示磁盘 util 很低 → 可能是大量小 IO 或缓存未生效，也可能是 RAID 卡或文件系统层延迟
用 iostat 锁定磁盘 I/O 瓶颈根因
iostat -x 1 5（启用扩展统计）是查磁盘问题的核心，别只盯着 %util：
- await > 10ms（机械盘）或 > 1ms（SSD）且持续偏高 → 不是磁盘忙，而是请求排队或响应慢，再看 avgqu-sz（平均队列长度） 是否 >1
- r_await 明显高于 w_await → 读密集型负载，检查是否缺缓存、索引缺失或大表全扫
- %util 接近 100% 但 r/s + w/s 很低 → 单次 IO 太大或延迟极高（比如 NFS 挂载卡顿、存储网络丢包），不是吞吐问题，是响应问题
三命令联动分析典型场景
遇到响应变慢时，按顺序执行并交叉验证：
- 先运行 top：发现 %wa=45%，r=8 → CPU 在等 I/O，且有 8 个进程排队
- 立刻开 vmstat 1 5：看到 bi=12000（KB/s）、si=0、so=0、r=7～9 → 磁盘读压力大，内存没换页，排除内存瓶颈
- 再跑 iostat -x 1 3：sda 设备 await=86ms、avgqu-sz=5.2、%util=98% → 磁盘已饱和，队列积压，下一步查是哪个进程在读 /dev/sda（用 iotop 或 pidstat -d 1）
不复杂但容易忽略：三个命令的时间窗口要尽量对齐，避免“top 看到的高 wa”和“iostat 采样间隙漏掉峰值”。
