Linux性能监控需结合top、vmstat、iostat三工具，从进程、内存、CPU、IO四维度交叉验证：top定位高负载源头，vmstat揭示资源争用趋势，iostat锁定磁盘瓶颈，联动分析才能准确定位真实瓶颈。
Linux性能监控不是只看一个命令的输出，而是把 top、vmstat、iostat 三者结合起来，从进程、内存、CPU、IO 四个维度交叉验证，才能准确定位瓶颈。
用 top 快速定位高负载源头
top 是第一眼排查工具，重点看三块：顶部的系统概览（load average、CPU 使用率、内存使用）、中间的进程列表（按 %CPU 或 %MEM 排序）、底部的运行状态统计。
- 若 load average 远高于 CPU 核数（比如 4 核机器显示 12.5），说明系统整体过载，需继续查是 CPU 密集还是 IO 等待导致
- 按 Shift+P 按 CPU 排序，找长期占满单核的进程；按 Shift+M 按内存排序，看是否有异常增长或泄漏
- 注意 %wa（iowait）值：如果 CPU idle 很高但 %wa 也高（比如 >20%），说明 CPU 在等磁盘，问题大概率在 IO 层
用 vmstat 揭示资源争用的时间规律
vmstat 1 10（每秒采样一次，共10次）能暴露周期性压力，比 top 更适合观察趋势。重点关注 r（运行队列长度）、b（阻塞进程数）、si/so（swap 进出）、bi/bo（块设备读写）这几列。
- r 值持续 > CPU 核数：说明就绪态进程太多，CPU 调度不过来，可能 CPU 不足或进程频繁唤醒
- b 值非零且波动大：进程在等待不可中断资源（如磁盘 IO、NFS），配合 iostat 看是否磁盘响应慢
- si/so 非零：正在发生 swap，内存严重不足；此时 free 内存低 + 缓存回收频繁，需检查应用内存配置或泄漏
用 iostat 锁定磁盘性能瓶颈
iostat -x 1 5（开启扩展统计，每秒一次）的核心指标是 %util、await、svctm（已弃用，看 await 和 r_await/w_await 更准）、avgqu-sz（平均队列长度）。
- %util 接近 100% 不代表一定慢，要结合 await：若 await 显著高于磁盘标称延迟（如 SATA 盘 >20ms，NVMe
- avgqu-sz > 1 且 await 上升：IO 请求积压，可能是应用并发太高、磁盘本身慢、或 RAID 卡/驱动问题
- 对比 r_await 和 w_await：若写延迟远高于读，检查是否日志刷盘频繁、sync 写多、或存储后端（如 NFS、Ceph）写入慢
三工具联动分析典型场景
例如用户反馈服务响应变慢：
- 先跑 top：发现 load average=8（2核机器），%wa=65%，CPU idle=20% → 初步判断是 IO 等待
- 再跑 vmstat 1 5：r=5~7，b=3~4，bi=1200，bo=800 → 运行队列和阻塞进程都高，块设备读写活跃
- 最后 iostat -x 1 5：sda 的 %util=98%，await=86ms，avgqu-sz=4.2 → 磁盘饱和且响应延迟高
- 结论：磁盘 IO 成为瓶颈，进一步用 iotop 或 pidstat -d 找出具体是哪个进程在大量写 /var/log 或数据库 redo log
不复杂但容易忽略的是时间维度和指标关联——单独看 top 可能以为是 CPU 问题，但 vmstat 和 iostat 一对照，真相往往是磁盘拖慢了整个调度链。
