一、为什么要关注磁盘I/O瓶颈？

当数据库查询突然变慢、应用启动耗时莫名增加或文件服务器响应延迟时，十有八九遇到了磁盘性能问题。机械硬盘的理论吞吐量仅200MB/s左右，而即便是SSD在混合读写场景下也可能跌落至三位数，现实中我们常遇到：

  • 支付系统交易流水堆积时批量写入性能断崖式下跌
  • K8s节点因容器镜像拉取导致虚拟机卡顿
  • Elasticsearch分片迁移触发磁盘饱和告警
  • MySQL主从同步延迟突破SLA阈值

这些问题都需要通过精准的I/O分析定位症结。接下来通过三位"手术专家"的实操，带你看清磁盘操作的微观世界。

二、iostat：系统级I/O健康扫描仪

2.1 基础参数速览（CentOS 7环境）

# 监控所有磁盘状态，每秒刷新（-d设备统计，-x扩展指标，1秒间隔）
$ iostat -dx 1
Device:   rrqm/s   wrqm/s     r/s     w/s    rkB/s    wkB/s  areq-sz  aqu-sz   await  %util
sda        0.00     7.00    0.00    3.00     0.00    24.00     8.00    0.02    6.67   0.20

关键指标解析：

  • %util：像老式汽车转速表，达到80%就该警惕（机械盘）
  • await：IO请求平均耗时（毫秒），注意和电梯等待时间类比
  • aqu-sz：请求队列长度，相当于超市结账排队人数

2.2 高压场景诊断

当发现%util长期90%+时：

# 查看块设备详细信息（-m以MB为单位，-p指定设备）
$ iostat -dxm -p sda 2
sda              0.00     0.00  789.00  156.00    30.12    15.23     0.09   12.34   92.34  99.80

# 指标突增案例：发现wkB/s（每秒写入KB）异常暴涨
Device      wrqm/s  wkB/s   %util
sda          142    180000   100.00  ← 突发写入导致磁盘满负荷

三、iotop：进程级IO流量监视器

3.1 实时进程追踪（Ubuntu 22.04环境）

# 需root权限运行，按O键切换仅显示实际IO进程
$ sudo iotop -oPa
Total DISK READ: 156.23 M/s | Total DISK WRITE: 45.67 M/s
PID  PRIO  USER     DISK READ  DISK WRITE  COMMAND
4452 be/4 mysql     152.34 M/s  0.00 B/s   mysqld --innodb_flush_method=O_DIRECT
701  be/3 postfix    3.89 M/s  45.67 M/s   pickup -l -t unix -u

排查技巧：

  • 发现某Java进程持续10MB+/s的swapin，可能是JVM内存不足引发频繁换页
  • Docker容器进程意外高读写（如日志未挂载volumes）

3.2 历史日志分析

# 记录IO操作到文件（-b批量模式，-t添加时间戳）
$ sudo iotop -bot -d 10 -n 6 > iotop.log

# 典型异常日志片段：
16:02:03  452 be/4 appuser   45.67 M/s  0.00 B/s  python data_import.py  ← 数据导入脚本导致写风暴

四、blkparse：磁盘操作显微镜头

4.1 全链路追踪（需blktrace套件）

# 记录sda设备10秒操作（需root）
$ blktrace -d /dev/sda -w 10

# 解析二进制数据为人类可读格式
$ blkparse -i sda -d sda.blktrace | less

# 关键字段解释样例：
  8,0    3        1     0.000000000  2195  Q  WS 587202584 + 8 [mysqld]
  8,0    3        2     0.000004213  2195  D  WS 587202584 + 8 [mysqld]

深度解析：

  1. 时间戳精度达纳秒级，适合对比多个IO事件的时间差
  2. 操作类型(Q:入队,D:下发,C:完成)形成完整生命周期
  3. 块地址+长度定位具体操作区域

4.2 实时诊断案例

# 组合使用blktrace和blkparse
$ blktrace -d /dev/nvme0n1 -o - | blkparse -i -

# 观察到大量BARRIER操作：
  8,0    0        1     0.000000000     0  Q  FS 587203920 + 32 [kworker/u4:2]
  8,0    0        2     0.000000000     0  D  FS 587203920 + 32 [kworker/u4:2]
  ← 文件系统同步请求，可能与ext4的data=ordered模式有关

五、工具特性对比表

工具 精度 维度 优势 缺陷
iostat 秒级 系统/设备 资源消耗低，适合长期监控 无法定位到具体进程
iotop 0.1秒级 进程级 实时可视化排名 可能漏掉内核线程操作
blkparse 纳秒级 块操作级别 可追溯完整IO生命周期 需要解析原始日志

六、避坑指南

  1. 权限陷阱：iotop需要root权限才能获取完整信息
  2. 采样间隔：iostat间隔太短会导致工具自身开销过大
  3. 数据关联：结合vmstat观察si/so（交换分区）情况
  4. SSD特殊项：注意监控%util对SSD的参考价值下降
  5. 容器环境：需进入cgroup命名空间查看实际进程

七、实战策略总结

当遭遇磁盘瓶颈时，建议采用"三维诊断法"：

  1. 先用iostat确认是否确实存在磁盘瓶颈
  2. 通过iotop找到嫌疑进程（重点关注DISK WRITE列）
  3. 使用blkparse进行手术刀级事件分析

对MySQL这类复杂应用，可配合show engine innodb status查看事务日志刷新情况。对于容器集群，需结合docker stats和cgroup的throttled_time指标。