Linux I/O性能监控需结合iostat与sar：iostat -x 1实时定位设备忙闲（%util>80%表饱和，r/s/w/s突增示进程刷盘），sar回溯历史趋势（sar -d查时段异常，配合sar -u/-r判内存换页干扰），再通过top %wa与iostat %util交叉验证根因。
Linux 文件系统性能监控，关键在于快速识别 I/O 瓶颈是否来自设备层、队列层或进程层。iostat 和 sar 不是替代关系，而是分工明确的组合：iostat 看“此刻设备忙不忙”，sar 看“过去一小时它为什么忙”。两者结合，才能把瞬时异常和长期趋势串起来。
iostat 定位实时设备级压力
iostat -x 1 是最常用的有效命令，每秒刷新一次扩展指标。重点关注以下几列：
- %util：设备忙时占比，持续 >80% 表示磁盘已饱和；若
- await：I/O 平均响应时间，SSD 超过 20ms、HDD 超过 50ms 就需警惕排队现象
- avgqu-sz：平均队列长度，>1 表明请求开始堆积，>4 基本确认存在严重排队
- r/s 和 w/s：读写次数突增（如从 200 跳到 3000）往往指向某个进程在密集刷盘
- rkB/s 和 wkB/s：配合 %util 判断瓶颈类型——高带宽低利用率，可能是网络存储延迟或文件系统锁竞争
sar 回溯历史趋势与关联上下文
sar 的价值在于时间维度还原。它能告诉你“什么时候开始变慢”“是不是只在备份时段出问题”：
- sar -d 1 30：实时采样 30 秒磁盘设备数据，适合抓突发 IO 风暴
- sar -d -f /var/log/sa/sa$(date -d yesterday +%d)：读取昨日历史记录，对比业务高峰前后的 util/await 变化
- sar -d -p：显示逻辑卷（LVM）名称而非底层 sdX，对使用 LVM 或云盘的环境更实用
- 配合 sar -u 和 sar -r：若发现 %wa 升高同时内存 free 下降、si/so 上升，大概率是缺内存导致频繁换页，间接拖累 I/O
交叉验证，锁定根因
单看 iostat 或 sar 都可能误判。必须用多个信号互相印证：
- top 中 %wa >30% + iostat 中 %util
- iostat 显示某块盘 %util 95% + sar -d 历史中该盘每晚 2:00 固定飙升 → 检查 crontab 备份任务或日志轮转配置
- await 高 + avgqu-sz 高 + rkB/s 低 → 磁盘响应慢，优先排查硬件（坏道、RAID 降级）、驱动或存储网络（iSCSI 延迟）
- await 高 + avgqu-sz 低 + tps 高 → 更可能是应用层问题，比如小文件随机读写多、未启用 direct I/O、或 ext4 日志模式不当
补充建议：别漏掉文件系统本身
即使块设备指标正常，文件系统也可能成为瓶颈：
- 用 df -i 检查 inode 是否耗尽，尤其小文件场景下极易触发
- 用 tune2fs -l /dev/sdX1 | grep "Filesystem state" 确认 ext4 是否处于 clean 状态，异常关机后未修复会影响性能
- 检查挂载选项：noatime, barrier=1, commit=30 等设置对写入延迟影响显著，生产环境应避免 defaults
- 对于 XFS，xfs_info 可查看 stripe width、allocation group 等参数是否匹配底层 RAID
