磁盘 IO 性能直接决定数据库、文件服务、消息队列等 IO 密集型应用的响应速度。当系统出现卡顿、服务超时或负载升高时，快速判断是否由磁盘引起、定位瓶颈进程和具体设备，是运维和排查的基本功。
1. 关键指标速览
在分析之前，先明确几个常用术语：
- IOPS（每秒读写次数）：衡量小 IO 随机访问的能力，数据库、邮件服务对此敏感。
- 吞吐量（MB/s）：衡量顺序大 IO 的带宽，影响日志写入、视频传输、备份恢复等场景。
- 延迟（Latency）：单次 IO 请求从发起到完成的时间，通常关注平均值（await）和百分位值。
- 队列深度（avgqu-sz）：设备中待处理的 IO 请求数，过高说明积压严重。
- 利用率（%util）：设备繁忙程度。对机械磁盘，趋于 100% 通常意味着饱和；对 SSD/云盘，此值仅表示至少有一个请求在处理，并不能完全反映真实负载，需结合其他指标。
2. 核心工具与典型用法
(1) iostat —— 快速查看块设备及分区统计
iostat 是标准工具，通常安装 sysstat 包获得。基础用法：
iostat -x 1 # 每秒输出一次扩展统计关键列解释（以 -x 模式为例）：
r/s/w/s：每秒读/写次数，相加得 IOPS。rkB/s/wkB/s：每秒读/写千字节，相加得吞吐量。await：IO 请求的平均等待时间（含队列等待和服务时间），单位毫秒。应用感知的延迟主要参考此值。r_await/w_await：读/写的平均延迟，可分别查看读写瓶颈。aqu-sz：平均队列长度。%util：设备带宽利用率。注意：对并发的 SSD，100% 并不代表极致饱和，应结合 IOPS 和延迟判断。
经验阈值（机械盘）：await 超过 20ms 通常影响体验；对 SSD，5-10ms 也需关注，具体取决于应用延时要求。
(2) iotop —— 定位是哪个进程在吃 IO
iotop -o # 仅显示正在产生 IO 的进程可以实时看到每个进程的磁盘读写速率和 IO 百分比。快速找出“凶手”，结合 iostat 可判断进程读写是否与设备压力吻合。
(3) pidstat —— 从进程角度获取历史样本
pidstat -d 1 # 每秒输出进程 IO 统计输出包含 kB_rd/s、kB_wr/s 等，适合脚本采集或事后分析。
(4) dstat / sar —— 综合监控与历史回溯
dstat -d --disk-util --disk-tps 可同屏显示多个磁盘的读写量和利用率。sar -d 则可回溯历史数据（需 sysstat 采集服务运行）。
3. 实际分析路径
通常按以下步骤层层递进：
第 1 步：宏观确认是否 IO 问题
系统响应慢时，先用 top 查看 CPU 的 %iowait（即 CPU 空转等待 IO 的比例）。如果某颗或多颗 CPU 的 iowait 持续高于 30-50%，磁盘很可能是瓶颈。但注意：iowait 高也可能因 IO 任务集中而 CPU 闲置，现代多核系统上单独查看意义已减弱，仍需结合设备指标。
第 2 步：找到饱和的设备
iostat -x 1观察各磁盘的 await 和 %util。若某块盘 await 显著偏高（如 >50ms），而队列长度 >1，说明该设备处理能力跟不上请求。
第 3 步：定位繁忙进程
iotop -o或
pidstat -d 1 | grep -v 0.00确定是哪个进程（mysql、java、rsync）在大量读写。结合读写速率，判断是正常的业务峰值，还是异常的如全表扫描、日志爆炸、不当备份。
第 4 步：深入文件级别（可选）
使用 lsof -p <pid> 查看进程打开了哪些文件；或者 strace -p <pid> -e trace=read,write 2>&1 | head 观察系统调用行为。对于数据库，查看其自身的慢查询日志往往更直接。
4. 实例解读
假设 iostat -x 1 看到某 SSD 如下数据：
Device r/s w/s rkB/s wkB/s await r_await w_await aqu-sz %util
sda 1500 30000 12000 480000 12.50 2.00 15.20 4.30 98解读：写入 IOPS 极高（30000），吞吐量约 480 MB/s，平均写延迟 15.2 ms，对于 SATA SSD 已算较高；队列深度 4.3，说明持续有排队；%util 接近 100%。此时如果应用日志显示事务提交慢，可以判定磁盘写入能力饱和。优化方向：升级为 NVMe、增加 RAID、将 WAL 日志分离到低延迟设备，或优化应用写入模式（批量、异步）。
5. 不得不知的陷阱
- %util 的误导：单块 NVMe 磁盘背后可能有多条并行通道，100% 的 util 时仍可能有 IOPS 余量；应更多关注延迟和队列深度。
- 缓存效应：
iostat看到的是块设备层统计，并不直接体现应用实际落盘延迟。文件系统缓存、RAID 卡缓存会掩盖真实设备性能。压测时应使用O_DIRECT或fio绕过缓存评估真实 IO 能力。 - 虚拟化/云环境：云盘性能受限于配额（IOPS、带宽），突发耗尽后会被限流，表现为延迟突然飙升。此时需结合云监控检查是否触达限制。
掌握上述工具和分析路径，足以应对绝大多数日常磁盘 IO 性能问题。关键是养成“先宏观后微观、从设备到进程”的习惯，避免在错误的方向上浪费精力。