iostat是排查linux磁盘i/o性能问题的核心工具，通过iostat -x 1关注%util、await、r/s、w/s、rmb/s、wmb/s等指标可快速定位瓶颈，并需结合pidstat、iotop、dmesg等命令交叉验证及针对性优化。
iostat 是排查 Linux 磁盘 I/O 性能问题最常用、最直接的工具之一。它能实时展示块设备（如硬盘、SSD、LVM 卷、RAID 设备）的读写吞吐量、IOPS、响应时间、队列长度等关键指标，帮助你快速定位是磁盘本身瓶颈、应用过度 IO、还是调度/队列配置不合理。
看懂核心指标：哪些字段真正影响性能
运行 iostat -x 1（每秒刷新一次扩展统计）后，重点关注以下几列：
- %util：设备忙于处理 I/O 请求的时间百分比。持续 >80% 通常说明磁盘饱和，但 SSD 或多队列设备需结合 avgqu-sz 和 await 综合判断；
- await：I/O 请求平均等待+服务时间（毫秒）。>10ms（HDD）或 >1ms（SSD）就值得警惕，若远高于设备标称延迟（如 NVMe 常态应
- avgqu-sz：平均队列长度。值大于 1 表示请求在排队；对单盘来说长期 >2~4 通常是瓶颈信号；
- r/s、w/s：每秒读/写请求数（IOPS）。对比设备理论极限（如 SATA SSD 约 50k~100k IOPS，HDD 约 100~200）可评估是否过载；
- rMB/s、wMB/s：每秒读/写吞吐量（MB）。对比接口带宽（如 SATA III 600MB/s、PCIe 4.0 x4 约 8GB/s）判断是否打满。
区分真实瓶颈和假象：常见干扰场景
某些高 %util 或 await 并不意味着磁盘故障，可能是临时或配置导致：
- 大量 sync 写入或 fsync() 调用（如数据库日志刷盘、rsync --sync）会强制落盘，拉高 await 和 %util；
- 使用 cfq（旧版）或低效 IO 调度器（如 deadline 在高并发随机写下表现差），换用 none（NVMe）、kyber 或 mq-deadline 可明显改善；
- 文件系统挂载选项不当，例如未启用 noatime 或 barrier=0（谨慎），可能增加元数据开销；
- 同一物理盘被多个 LVM 逻辑卷、Docker 卷或 KVM 虚拟磁盘共享，IO 被分散又竞争，需用 iostat -x -d 查看底层物理设备（如 /dev/sda）而非上层设备（如 /dev/dm-0）。
联动其他命令交叉验证
iostat 提供宏观视图，但需配合其它工具确认根源：
- 用 pidstat -d 1 找出具体哪个进程在大量读写（显示 PID、kB_rd/s、kB_wr/s）；
- 用 iotop -o 实时查看活跃 IO 进程及其读写速率（类似 top 的交互式界面）；
- 用 lsof +D /mnt/data 或 find /proc/[0-9]*/fd -ls 2>/dev/null | grep "REG" 定位大文件或频繁访问的文件路径；
- 检查内核日志：dmesg -T | grep -i "ata\|nvme\|i/o\|timeout"，确认是否存在硬件错误、链路降速或重试告警。
简单有效的优化方向
根据 iostat 结果，可优先尝试这些低成本调整：
- 对 HDD：启用 read-ahead（blockdev --setra 8192 /dev/sdb），提升顺序读效率；
- 对 SSD/NVMe：关闭磁盘缓存（hdparm -W0 /dev/nvme0n1）并确保使用 none 调度器；
- 批量写入场景：应用层合并小写、启用 write-back 缓存（需 UPS 保障）、或改用异步 IO（如 Linux AIO、io_uring）；
- 数据库类负载：调整 innodb_io_capacity、vm.dirty_ratio 等内核参数，避免脏页集中刷盘。
