背景与现象

运维工程师在日常巡检或接到告警时，经常会遇到这样一类问题：

• 服务器 CPU 的 %iowait 持续高于 30%，机器负载异常飘高
• 应用日志里出现大量超时、卡顿，关键接口响应时间从几毫秒跳到几秒甚至几十秒
• uptime 显示的负载数值（load average）远高于 CPU 核心数，但 vmstat 发现 CPU User% 其实很低
• 磁盘吞吐（Throughput）并没有打满，但 IO 延迟（Latency）非常高，IO 队列堆积

这类问题的共同特征是：磁盘 IO 成为了系统瓶颈，但瓶颈的具体位置和成因并不一目了然。是哪个进程在大量读写？是哪个文件或块设备？是顺序 IO 还是随机 IO？是读还是写？是应用程序本身的问题还是内核 IO 调度策略的问题？

盲目重启服务、盲目加内存、盲目扩容磁盘，往往解决不了问题，还会引入新的风险。本篇文章的目标是：在不停服的前提下，用 Linux 内置的或常见的工具链，精准定位 IO 性能问题的根因，覆盖从现象观察到根因定位再到调优验证的完整闭环。

工具准备：这些工具通常已内置

以下工具在大多数 Linux 发行版中可直接使用，无需额外安装：

检查工具是否存在：

which iostat iotop blktrace pidstat
iostat -V   # 看 sysstat 版本

第一阶段：先看整体 IO 状况——判断是不是 IO 问题

1.1 用 vmstat 初步判断

vmstat 1 10

重点关注这几列：

procs -----------memory---------- ---swap-- -----io---- --system-- -----cpu-----
 r  b   swpd   free   buff  cache   si   so    bi    bo   in   cs us sy id wa st
 4  2      0 2048000 120000 4200000    0    0   128 65536    0    0  5  3 60 32  0

• bi（blocks received from block device）：每秒从磁盘读入的块数
• bo（blocks sent to block device）：每秒写入磁盘的块数
• wa（I/O wait）：CPU 等待 IO 完成的时间百分比
• b（processes blocked）：处于不可中断睡眠状态的进程数

判断标准：

• wa 持续高于 20%~30%，说明系统大量时间花在等待 IO 上，是 IO 瓶颈的强烈信号
• b 列数值如果大于 CPU 核心数，说明有进程在等待 IO 而被阻塞
• bi 和 bo 都很低但 wa 很高，常见原因是随机 IO 导致的磁盘寻址开销，而不是吞吐打满

1.2 用 iostat 看块设备全局统计

iostat -xzm 2 5

参数说明：

• -x：显示扩展统计（%util、avgqu-sz、awits 等关键指标）
• -z：不显示没有活动的设备
• -m：以 MB/s 为单位显示吞吐
• 2 5：每 2 秒采样一次，共采样 5 次

典型输出：

Device:         rrqm/s   wrqm/s     r/s     w/s    rMB/s    wMB/s avgrq-sz avgqu-sz   await r_await w_await  svctm  %util
sda               0.00     2.00    0.50   10.50     0.01     0.52    83.54     0.18   16.42   12.33   16.87   5.22   0.06

核心字段解读：

重点：不要只盯着 %util。一块 7200 RPM 的 HDD，即使 %util 只有 40%，如果 avgqu-sz 达到 8，IO 延迟也会非常高，因为队列堆积了太多请求。对于 SSD，%util 更能反映真实饱和程度。

1.3 确认是哪个设备在承受 IO

iostat -d -p ALL 2 1 | grep -E "^sd|^nvme|^dm-"

或者：

cat /proc/diskstats

查看所有块设备的 IO 统计。如果发现 /dev/sda 和 /dev/sda1 都在活跃，要进一步确认是哪个分区在承受负载：

iostat -p sda 2 3

第二阶段：定位到具体进程——谁在读写

2.1 用 iotop 实时看进程级 IO

sudo iotop -o -a -d 2

参数说明：

• -o：只显示正在做 IO 的进程（减少干扰）
• -a：显示累计 IO 而非实时速率
• -d 2：每 2 秒刷新一次

典型输出：

Total DISK READ:        0.00 B/s | Total DISK WRITE:      152.34 MB/s
Current DISK READ:       0.00 B/s | Current DISK WRITE:       8.92 MB/s
  TID  PRIO  USER     DISK READ  DISK WRITE  SWAPIN     IO COMMAND
12433 be/4 root      152.34 MB/s    0.00 B/s  0.00 % 99.97 % mysqld
 8721 be/3 root        0.00 B/s   120.55 MB/s  0.00 % 78.23 % redis-server
18745 be/4 nginx       8.92 MB/s    0.00 B/s  0.00 % 35.12 % php-fpm

这里可以直接看到：

• mysqld 正在以 152 MB/s 的速度读取磁盘，这是非常高的读 IO
• redis-server 以 120 MB/s 写入
• IO 百分比（%IO 列）显示该进程占用的 IO 带宽比例

注意：iotop 需要 root 权限，或者 CAP_NET_ADMIN 等能力。如果在容器内运行，需要 --privileged 或挂载 /proc 和 /sys/kernel/debug。

2.2 用 pidstat 按进程 ID 追踪 IO

# 看所有进程的 IO 统计，每 2 秒一次
pidstat -d 2 5

# 看指定进程的 IO 情况（假设 PID 是 12433）
pidstat -d -p 12433 1 10

输出中重点关注 kB_rd/s（每秒读取 KB 数）和 kB_wr/s（每秒写入 KB 数）。

2.3 进一步定位是哪个文件在被读写

拿到进程 PID 后，用 lsof 找出该进程打开了哪些文件：

sudo lsof -p 12433 | grep -E "REG|DIR" | awk '{print $NF}' | sort | uniq -c | sort -rn | head -20

这会列出该进程访问频率最高的文件。如果 MySQL 进程在大量读盘，可能是：

• innodb_data_file_path：InnoDB 数据文件
• innodb_log_file_size：Redo log
• tmpdir 或 sort_buffer_size：临时表和排序溢出

如果发现某个大文件被反复读写，可以进一步确认：

# 看该文件被打开的文件描述符
sudo ls -la /proc/12433/fd | grep -E "$(sudo lsof -p 12433 | grep 'ibdata' | awk '{print $NF}' | head -1)"

第三阶段：分析 IO 模式——是顺序还是随机

3.1 用 iostat 的扩展统计判断 IO 类型

Device:         rrqm/s   wrqm/s     r/s     w/s    rKB/s    wKB/s avgrq-sz avgqu-sz   await
sda               0.00     0.00  3200.00 100.00     0.00  16000.00   5120.00     8.20

• avgrq-sz（Average Request Size）：平均每次 IO 请求的大小，以扇区为单位（512 字节）。这里 avgrq-sz = 5120 即 2.5 MB，明显是大块顺序 IO。
• 如果 avgrq-sz 在 8~64（4 KB ~ 32 KB）范围，通常是随机小 IO，比如数据库页面读写
• rrqm/s 和 wrqm/s：合并的读写请求数。如果合并率高（接近 r/s 和 w/s），说明 IO 调度器在合并相邻请求，对顺序 IO 友好

3.2 用 blktrace 跟踪 IO 请求路径

blktrace 是更底层的工具，可以跟踪块设备上每个 IO 请求的生成分发、进入调度、完成的完整路径。对于精确定位问题不可或缺。

安装

# RHEL/CentOS
sudo yum install blktrace -y

# Debian/Ubuntu
sudo apt install blktrace -y

启动跟踪

# 对 sda 设备进行跟踪，输出到当前目录
sudo blktrace -d /dev/sda -o ./blktrace_output

等待一段时间（建议 30 秒到 2 分钟，覆盖一个完整的业务周期），然后按 Ctrl+C 停止。也可以用 -w 参数指定时长：

sudo blktrace -d /dev/sda -w 60 -o ./blktrace_output

这会生成 blktrace_output.blktrace.* 文件。

分析 blktrace 输出

blktrace 本身是二进制格式，需要用 blkparse 转换成可读格式：

sudo blkparse -i ./blktrace_output -d - | head -100

-d 表示直接输出到标准输出。输出格式：

8,0   3        1     0.000000000 12433  Q  WS 33554432 + 8192 [mysqld]
8,0   3        2     0.000001234 12433  G  WS 33554432 + 8192 [mysqld]
8,0   3        3     0.000002456 12433  I  WS 33554432 + 8192 [mysqld]
8,0   3        4     0.000003678 12433  D  WS 33554432 + 8192 [mysqld]
8,0   3        5     0.008765432     0  C  WS 33554432 + 8192 [mysqld]

字段说明：

• 第 1 列 8,0：Major,Minor 设备号
• 第 2 列 3：CPU ID
• 第 3 列 1：序列号
• 第 4 列：时间戳（精确到纳秒）
• 第 5 列 12433：进程 PID
• 第 6 列 Q/G/I/D/C：IO 操作阶段
• Q（Queue）：请求进入块层
• G（Get）：IO 调度器获取请求
• I（Insert）：插入调度队列
• D（Dispatch）：从调度器分发到磁盘
• C（Complete）：完成
• 第 7 列 WS：Write 或 Read，Sync 或 Async
• 第 8 列 33554432：起始扇区号
• 第 9 列 + 8192：请求扇区数（8192 × 512 字节 = 4 MB）
• 第 10 列 [mysqld]：进程名

如何通过 blktrace 判断 IO 瓶颈：

1. 看 Q 到 D 的时间差——这是 IO 在调度队列中的等待时间。如果 D 时间戳减去 Q 时间戳数值很大（比如 50ms+），说明 IO 在调度队列里等了太久，内核 IO 调度器是瓶颈。
2. 看 C 减 D 的时间差——这是磁盘实际处理 IO 的时间。如果这个值很大，说明磁盘自身是瓶颈。
3. 看读操作的 Q 到 C 延迟——读 IO 的延迟如果远大于写 IO，说明是读请求在排队，这通常与随机读有关。
4. 结合 avgqu-sz 来看——如果队列中有很多请求在等待，但 D 的频率不高，说明调度器在合并请求，但整体请求量太大。

用 btt 分析 blktrace 结果

blktrace 自带 btt 工具，可以生成更直观的分析报告：

sudo blkparse -i ./blktrace_output -d /tmp/blktrace.bin
python3 /usr/share/doc/blktrace/scripts/btt/btt.py -i /tmp/blktrace.bin -d 2>/tmp/btt_report.txt
cat /tmp/btt_report.txt

btt 会输出每个阶段的平均延迟：

Device: sda
[Q2Q] (ms)      avg:        0.001    min:        0.000    max:       23.421    std:        0.045
[Q2G] (ms)      avg:        0.002    min:        0.000    max:        0.389    std:        0.008
[Q2I] (ms)      avg:        0.001    min:        0.000    max:        0.120    std:        0.004
[I2D] (ms)      avg:        0.087    min:        0.000    max:      152.388    std:        1.234
[D2C] (ms)      avg:       12.456    min:        0.000    max:      456.123    std:       34.567
[Q2C] (ms)      avg:       12.546    min:        0.001    max:      456.234    std:       34.567

• Q2G：从请求进入到被调度器获取的时间。如果这个值大，说明 CFQ/Deadline 等调度器在排队
• I2D：从插入调度队列到真正下发到磁盘的时间。这个阶段涉及请求合并和调度决策
• D2C：从下发到完成的时间，这是磁盘真实处理时间
• Q2C：端到端延迟

如果 I2D 很大（例如 > 10ms），说明 IO 调度器堆积了大量请求，调度算法本身成为了瓶颈，这时候可以尝试：

• 换成 noop 调度器（适合 SSD 或高 IOPS 场景）
• 增大 queue_depth（PCIe SSD）
• 减少调度器对请求的合并

如果 D2C 很大（例如 HDD 上 > 20ms），说明磁盘自身寻址或传输慢，需要考虑换盘或优化 IO 模式。

3.3 用 seekwatcher 可视化 IO 模式

如果安装了 seekwatcher，可以将 blktrace 数据绘制成图表：

blktrace -d /dev/sda -o raw_data
seekwatcher -t raw_data -o io_visualization.png

生成的 PNG 图片可以直观看到 IO 突发的时间点和 IO 延迟的分布。

第四阶段：常见根因与修复方案

根因一：数据库高并发随机读

典型场景：MySQL InnoDB 在没有足够缓冲池时，大量页面换入换出（Buffer Pool Miss），导致随机 IO。

判断方法：

# 看 MySQL InnoDB 缓冲池命中率
mysql -e "SHOW ENGINE INNODB STATUS\G" | grep -E "Buffer pool hit rate|Page reads"

修复方案：

1. 估算 innodb_buffer_pool_size：设置为可用内存的 60%~80%，确保热数据都在内存里
2. 开启 innodb_buffer_pool_dump_at_shutdown = ON，减少重启后预热时间
3. 调整 innodb_max_dirty_pages_pct，在脏页积累过多前主动刷新
4. 检查 innodb_flush_log_at_trx_commit，如果不是严格持久化需求，可以适当放宽到 2

# MySQL my.cnf 示例（innodb_buffer_pool_size 根据实际内存调整）
innodb_buffer_pool_size = 32G   # 建议设置为可用内存的 60-80%
innodb_buffer_pool_instances = 8  # 多实例减少锁竞争
innodb_max_dirty_pages_pct = 75
innodb_flush_log_at_trx_commit = 2
innodb_read_io_threads = 16
innodb_write_io_threads = 16

风险提醒：修改 innodb_flush_log_at_trx_commit 会影响数据持久性。如果设置为 2（每秒刷新一次），极端情况下最多丢失 1 秒的事务数据。只在可接受丢失的业务场景下使用，如数据仓库、统计分析类业务。

根因二：Swap 频繁触发

典型场景：物理内存耗尽，系统开始 Swap，磁盘 IO 暴涨。

判断方法：

vmstat 1 5
# 看 si（swap in）和 so（swap out）列是否持续非零

# 看具体哪些进程在用 Swap
for f in /proc/*/status; do awk '/VmSwap/{s+=$2}/Name/{n=$2}END{if(s>0)print n,s}'$f 2>/dev/null; done | sort -k2 -rn | head -10

修复方案：

1. 确认应用内存占用是否合理（是否有内存泄漏）
2. 调整 vm.swappiness（默认 60，可以降到 10~30，减少主动 Swap）
3. 增加物理内存
4. 限制进程内存使用（cgroup 内存限制、MySQL max_connections、php-fpmpm.max_children 等）

# 查看当前 swappiness
cat /proc/sys/vm/swappiness

# 临时修改（重启后失效）
sudo sysctl -w vm.swappiness=10

# 永久生效
echo"vm.swappiness = 10" | sudo tee -a /etc/sysctl.conf
sudo sysctl -p

风险提醒：将 swappiness 降得过低（如 0）可能导致 OOM Killer 在内存真正耗尽前不触发 Swap，反而直接杀进程。要结合业务特点调整。

根因三：IO 调度器不匹配

典型场景：SSD 使用了 cfq（Completely Fair Queuing）调度器，导致 IO 延迟反而变高。HDD 使用了 noop 导致随机读写性能差。

判断方法：

# 查看当前调度器
cat /sys/block/sda/queue/scheduler

# 查看块设备类型（SSD 还是 HDD）
cat /sys/block/sda/queue/rotational
# 1 = HDD, 0 = SSD/NVMe

常见调度器：

修复方案：

# 临时修改（重启后失效）
echo mq-deadline | sudo tee /sys/block/sda/queue/scheduler

# 永久生效（RHEL/CentOS）
echo'ACTION=="add|change", SUBSYSTEM=="block", KERNEL=="sd[a-z]", ATTR{queue/scheduler]="mq-deadline"' | \
  sudo tee /etc/udev/rules.d/60-ssd-scheduler.rules

# 永久生效（Debian/Ubuntu）
echo'SUBSYSTEM=="block", ATTR{queue/scheduler}="mq-deadline"' | \
  sudo tee /lib/udev/rules.d/60-ssd-scheduler.rules

根因四：文件系统碎片化或挂载选项不当

典型场景：ext4 文件系统在大文件删除后产生碎片，或者 noatime 未挂载导致每次读取都写访问时间，增加 IO。

判断方法：

# 查看当前挂载选项
mount | grep sda1

# 检查文件系统碎片（ext4）
sudo fsck -n /dev/sda1  # -n 表示只读检查，不修复

# 对于 xfs
sudo xfs_db -r /dev/sda1
xfs_db> frag

修复方案：

1. 添加 noatime 和 nodiratime 挂载选项，避免访问时间更新带来的写 IO

# 临时生效
sudo mount -o remount,noatime,nodiratime /dev/sda1 /data

# 永久生效（/etc/fstab）
# /dev/sda1 /data ext4 defaults,noatime,nodiratime 0 2

1. 对 ext4 文件系统，如果碎片严重，可以考虑在线碎片整理（注意：生产环境操作有风险）：

# RHEL 7+ 需要安装 e2fsprogs
sudo yum install e2fsprogs -y

# 在线碎片整理（需谨慎，生产环境建议在维护窗口操作）
sudo e4defrag -c /data

根因五：日志写入过于频繁

典型场景：应用程序写大量 DEBUG 级别日志，或者日志轮转（logrotate）配置不当，导致同步写 IO 阻塞。

判断方法：

# 看哪些文件被频繁写入
sudo find /var/log -type f -name "*.log" -exec ls -lth {} + | head -20

# 看具体进程的写 IO
pidstat -d 1 5 | grep -v "^Average" | awk '$7 > 0 {print}'

修复方案：

1. 将日志目录迁移到独立磁盘或 SSD
2. 调整日志级别，关闭不必要的 DEBUG 日志
3. 使用异步日志写入（大多数 Web 应用支持）
4. 配置 logrotate 避免单文件过大：

# /etc/logrotate.d/myapp 示例
/var/log/myapp/*.log {
    daily
    rotate 14
    missingok
    notifempty
    compress
    delaycompress
    sharedscripts
    postrotate
kill -USR1 $(cat /var/run/myapp.pid 2>/dev/null)  # 通知应用重新打开日志文件
    endscript
}

第五阶段：调优验证与监控

验证 IO 性能基准

调优前后用 fio 做基准测试，记录数据作为对比：

# 安装 fio
sudo yum install fio -y   # or: sudo apt install fio -y

# 随机读测试（模拟数据库场景）
sudo fio --name=randread --filename=/tmp/fio_test --ioengine=libaio \
  --rw=randread --bs=4k --numjobs=4 --size=1G --runtime=60 \
  --group_reporting -- iodepth=32

# 顺序写测试
sudo fio --name=seqwrite --filename=/tmp/fio_test --ioengine=libaio \
  --rw=write --bs=1M --numjobs=1 --size=2G --runtime=60 \
  --group_reporting -- fsync=1

关注指标：

• IOPS：每秒 IO 操作数，随机读测试中 4K 随机读是核心指标
• 带宽（BW）：顺序读写测试的吞吐量
• 延迟（lat）：平均和 99th percentile 延迟

建立常态化监控

单次排查不足以保证长期健康，需要建立监控：

# crontab 中加入定期 iostat 收集
# 每 5 分钟采集一次 iostat 数据到文件（用于事后分析）
*/5 * * * * /usr/bin/iostat -xzm 2 3 >> /var/log/iostat.log 2>&1

# 告警脚本示例（%util > 80% 时告警）
#!/bin/bash
UTIL=$(iostat -x -c 1 1 | awk '/^%util/{print $NF}')
if (( $(echo"$UTIL > 80" | bc -l) )); then
echo"Disk IO alert: sda util ${UTIL}%" | tee /dev/kmsg
# 这里接你的告警渠道：钉钉/企业微信/PagerDuty
fi

用 Prometheus node_exporter 的磁盘 IO 指标（node_disk_io_time_seconds_total、node_disk_read_time_seconds_total 等）配合 Grafana 面板展示 IO 趋势，设置合理阈值告警。

故障复盘模板

每次 IO 问题解决后，建议记录以下内容，形成团队知识沉淀：

【故障复盘】磁盘 IO 瓶颈排查

发生时间：
故障持续时长：
影响范围：

现象：
- 系统负载：
- %iowait：
- %util / avgqu-sz：
- 主要 IO 进程：
- IO 类型（读/写/随机/顺序）：

排查路径：
1. [命令/工具] 观察到了 [指标]，判断为 [初步结论]
2. [命令/工具] 进一步确认了 [指标]，排除了 [可能性A]
3. [命令/工具] 定位到根因是 [具体原因]

根因：
修复方案：
验证结果：

预防措施：

总结

磁盘 IO 问题排查的核心路径：

vmstat（初步判断）→ iostat（确认设备级瓶颈）→ iotop（定位进程）
→ pidstat/lsof（定位具体文件和操作）→ blktrace（分析 IO 模式与延迟分布）
→ 根因判断（数据库 Swap 调度器 文件系统）→ 针对性修复 → fio 验证

关键原则：

• 先看整体再看局部，不要一上来就上 blktrace，先用 vmstat + iostat 过滤掉非 IO 问题
• 工具组合使用，单一工具往往只能回答部分问题，需要交叉验证
• 不轻易重启，大多数 IO 问题可以在运行时定位和修复
• 复盘和监控同样重要，排查一次问题要形成可复用的监控规则和 SOP

大多数 Linux 磁盘 IO 性能问题，根因集中在四个方向：高随机读（数据库 Swap）、同步写 IO（日志/日志轮转）、IO 调度器不匹配、文件系统碎片或挂载选项不当。用好 iostat 和 blktrace 这两把利器，能覆盖 80% 以上的场景。