iostat是sysstat中用于实时监控块设备I/O性能的核心工具，通过await、%util、r/s、w/s、rkB/s、wkB/s等指标组合判断磁盘是否成为瓶颈：await过高（机械盘>10–15ms、SSD>2–5ms）且%util高而吞吐低，表明物理层瓶颈；await高但%util低，则问题在内核队列或文件系统锁；需结合iotop、pidstat等进一步定位进程与IO行为。
iostat 是 sysstat 工具包中的核心命令，专用于实时观察块设备（如硬盘、SSD、NVMe）的 I/O 性能指标。它不直接“诊断瓶颈”，但能帮你快速识别磁盘是否成为系统性能拖累——关键看 await（平均I/O等待时间）、%util（设备忙时百分比）和 r/s、w/s、rkB/s、wkB/s（吞吐量与IOPS）三类指标的组合异常。
关注核心指标：什么值算“有问题”？
运行 iostat -x 1（每秒刷新一次扩展统计）后，重点观察以下列：
- await：单次I/O请求从发出到完成的平均耗时（毫秒）。传统机械盘 > 10–15ms 值得警惕；SSD > 2–5ms 就可能有压力；持续 > 20ms 通常表明队列积压或硬件响应变慢。
- %util：设备忙于处理I/O的时间占比。接近 100% 并非绝对危险（尤其对并行能力强的SSD），但若同时伴随高 await 和低吞吐量，说明设备已达服务能力极限。
- r/s + w/s：每秒读写请求数（IOPS）。对比设备标称值（如 SATA SSD 约 50K–100K IOPS，NVMe 可达百万级），明显偏低却 %util 高，暗示随机小IO或锁竞争问题。
- rkB/s + wkB/s：每秒读写数据量（KB）。若远低于设备理论带宽（如 SATA III 600MB/s、PCIe 4.0 x4 约 3.2GB/s），而 %util 不高，可能是应用未充分并发或IO模式低效（如大量小块同步写）。
定位瓶颈类型：区分是磁盘慢、队列堵，还是应用拖累？
单看 iostat 不足以定因，需结合指标组合判断：
- 高 await + 高 %util + 低 r/s+w/s → 典型磁盘物理瓶颈（如机械盘随机读写、SSD老化、RAID卡缓存失效）。
- 高 await + 高 %util + 高 r/s+w/s → 设备饱和但仍在尽力服务，需扩容或优化IO路径（如换NVMe、调整IO调度器）。
- 高 await + 低 %util → 关键线索！说明请求在内核层排队（如 block layer queue 拥塞、文件系统锁争用、ext4 journal 延迟），而非磁盘本身慢。此时应查 iostat -x 中的 avgqu-sz（平均队列长度）是否显著大于 1，再结合 iotop 或 pidstat -d 找出具体进程。
- 低 await + 高 %util → 正常高负载状态（如顺序大文件拷贝），设备高效运转，无需干预。
实用操作建议：让 iostat 输出更有效
- 用 iostat -xmt 2：-x（扩展统计）、-m（MB/s单位）、-t（打印时间戳）、2（2秒间隔），便于记录趋势。
- 加 -d 参数隐藏CPU统计，聚焦磁盘（默认会混入CPU行，易干扰）。
- 监控特定设备：如只看 nvme0n1，用 iostat -xm /dev/nvme0n1 1。
- 对比空闲与业务高峰期：同一负载下，await 是否随业务增长线性上升？若突增，检查是否有新任务引入大量同步写或 fsync 调用。
- 别只盯峰值：用 iostat -x 1 60 > io.log 采集1分钟数据，再用 awk 分析 avgqu-sz 或 await 的中位数/95分位值，比单次快照更可靠。
下一步该做什么？
iostat 是起点，不是终点。确认磁盘层异常后：
- 用 iotop -o 查哪个进程在猛刷磁盘；
- 用 lsof + PID 看它在写哪些文件；
- 用 strace -p PID -e trace=write,fsync,fdatasync 看是否频繁小写+强制刷盘；
- 检查挂载选项（如 ext4 是否用了 data=ordered 或 barrier=1）、文件系统碎片（xfs_info / df -T）、以及 RAID/NVMe 控制器固件版本。
