磁盘 IO 飙升导致系统卡死？iostat 与 iotop 深度实战

一、概述

二、Linux IO 栈全景与调度器

应用程序 (read/write/pread/pwrite/io_uring)    |    vVFS (Virtual File System) --- Page Cache    |    v文件系统 (ext4 / xfs / btrfs)    |    vBlock Layer (通用块层)    |  - IO 合并 (merge)    |  - IO 调度 (mq-deadline/bfq/kyber/none)    |  - 请求队列 (多队列 blk-mq)    v设备驱动 (NVMe driver / SCSI / virtio-blk)    |    v物理设备 (NVMe SSD / SATA SSD / HDD / 云盘)

# 查看当前磁盘使用的调度器（方括号标记的是当前生效的）cat /sys/block/sda/queue/scheduler# 输出示例：[mq-deadline] kyber bfq none# 运行时切换调度器（立即生效，不需要重启）echo "bfq" > /sys/block/sda/queue/scheduler

# 持久化调度器配置（udev 规则）cat > /etc/udev/rules.d/60-io-scheduler.rules << 'EOF'# NVMe SSD 使用 noneACTION=="add|change", KERNEL=="nvme[0-9]*", ATTR{queue/scheduler}="none"# SATA SSD 使用 mq-deadlineACTION=="add|change", KERNEL=="sd[a-z]", ATTR{queue/rotational}=="0", ATTR{queue/scheduler}="mq-deadline"# HDD 使用 mq-deadlineACTION=="add|change", KERNEL=="sd[a-z]", ATTR{queue/rotational}=="1", ATTR{queue/scheduler}="mq-deadline"EOF
# 重新加载 udev 规则udevadm control --reload-rules && udevadm trigger

三、iostat 输出深度解读

# 最常用的命令：每秒刷新一次，显示扩展信息，单位用 MB# -x 扩展模式  -m 单位MB  -t 显示时间戳  1 间隔1秒iostat -xmt 1
# 只看特定磁盘iostat -xmt -d nvme0n1 sda 1
# 看第一次输出要注意：第一行是系统启动以来的累计平均值，不是实时数据# 从第二行开始才是每秒的实时数据，排查问题时忽略第一行

Device  r/s    rkB/s   rrqm/s  %rrqm  r_await  rareq-sz  w/s    wkB/s   wrqm/s  %wrqm  w_await  wareq-sz  d/s  dkB/s  drqm/s  %drqm  d_await  dareq-sz  f/s  f_await  aqu-sz  %utilsda     850.00 13600.0  45.00   5.03   0.85     16.00     320.00 25600.0  120.00  27.27  2.30     80.00    0.00  0.00   0.00    0.00   0.00     0.00     0.00  0.00    1.25    78.40

# 场景判断速查：# 1. await 高 + aqu-sz 高 + %util 高 → 磁盘确实忙不过来（HDD 常见）# 2. await 高 + aqu-sz 低 + %util 低 → 单个 IO 慢，可能是磁盘硬件问题或 RAID 降级# 3. await 正常 + w/s 极高 + wkB/s 低 → 大量小写入，考虑合并 IO 或调大 dirty ratio# 4. rrqm/s 接近 0 + rareq-sz 很小 → 纯随机读，Page Cache 没起作用# 5. w_await 远高于 r_await → 写入瓶颈，检查 fsync 频率和 journal 模式

# 查看今天的磁盘 IO 历史（-d 磁盘统计，-p 显示设备名）sar -dp 0
# 查看昨天的数据sar -dp -f /var/log/sysstat/sa$(date -d yesterday +%d)
# 查看指定时间段sar -dp -s 02:00:00 -e 04:00:00
# 输出示例：# 02:10:01  DEV       tps     rkB/s     wkB/s  areq-sz  aqu-sz  await  %util# 02:20:01  sda     1250.00  10000.00  40000.00   40.00    3.50   2.80  92.00# 02:30:01  sda      120.00   960.00    2400.00   28.00    0.15   1.25  12.00

四、iotop 定位 IO 密集进程

# 需要 root 权限（依赖内核的 taskstats 接口）# -o 只显示有 IO 活动的进程（过滤掉空闲的）# -P 显示进程而不是线程# -a 累积模式（显示自启动以来的累计 IO 量）sudo iotop -oP
# 推荐使用 iotop-c（C 语言重写版，性能更好）# Ubuntu: sudo apt install iotop-csudo iotop-c -oP

Total DISK READ:       125.50 M/s | Total DISK WRITE:       42.30 M/sActual DISK READ:      125.50 M/s | Actual DISK WRITE:       8.75 M/s    TID  PRIO  USER     DISK READ  DISK WRITE  SWAPIN     IO>    COMMAND  12847 be/4  mysql     98.20 M/s    5.60 M/s   0.00 %  82.35 % mysqld --defaults-file=/etc/mysql/my.cnf   3021 be/4  root      22.10 M/s    0.00 B/s   0.00 %  15.20 % tar czf /backup/db-20260206.tar.gz /var/lib/mysql    891 be/4  elastic    5.20 M/s   36.70 M/s   0.00 %   8.50 % java -Xms16g ... elasticsearch

# IO 调度类：# 1 = Realtime（实时，慎用）# 2 = Best-effort（默认，0-7 级，数字越小优先级越高）# 3 = Idle（空闲时才执行，适合备份任务）
# 把备份进程降到 Idle 级别（只在磁盘空闲时才给它 IO）sudo ionice -c 3 -p 3021
# 启动备份任务时直接指定低优先级sudo ionice -c 3 nice -n 19 tar czf /backup/db-20260206.tar.gz /var/lib/mysql
# 注意：ionice 只在 bfq 和 mq-deadline 调度器下生效# none 调度器（NVMe 默认）不支持 IO 优先级

# -d 显示 IO 统计  1 每秒采集  10 采集10次pidstat -d 1 10
# 只看特定进程pidstat -d -p 12847 1
# 输出示例：# Time      UID  PID   kB_rd/s  kB_wr/s  kB_ccwr/s  iodelay  Command# 15:30:01  999  12847 98200.00  5600.00    800.00      45    mysqld

五、blktrace + btt 深度分析

Q (Queued)      → 请求进入块层队列G (Get request) → 分配 request 结构体M (Merged)      → 与已有请求合并I (Inserted)    → 插入调度器队列D (Dispatched)  → 下发到设备驱动C (Completed)   → 设备完成 IO

# 采集 sda 的块层追踪数据，持续 10 秒sudo blktrace -d /dev/sda -w 10 -o trace
# 会生成 trace.blktrace.0, trace.blktrace.1 ... 每个 CPU 一个文件
# 用 blkparse 解析成可读格式blkparse -i trace -o trace.txt
# 输出示例（每行一个事件）：#  8,0  1  1  0.000000000  12847  Q  R 123456 + 8 [mysqld]#  8,0  1  2  0.000001200  12847  G  R 123456 + 8 [mysqld]#  8,0  1  3  0.000002500  12847  I  R 123456 + 8 [mysqld]#  8,0  1  4  0.000015000  12847  D  R 123456 + 8 [mysqld]#  8,0  1  5  0.000850000     0   C  R 123456 + 8 [0]# 解读：mysqld 发起了一个读请求，扇区 123456 开始读 8 个扇区（4KB）# Q→D 排队 15us，D→C 设备服务 835us，总耗时 850us

# 用 btt 分析（需要先用 blkparse 生成二进制格式）blkparse -i trace -d trace.binbtt -i trace.bin
# btt 输出的关键段落：
# ==================== All Devices ====================#             ALL           MIN           AVG           MAX           N# --------------- ------------- ------------- ------------- -----------# Q2C               0.000085000   0.001250000   0.025000000       12847# Q2D               0.000005000   0.000018000   0.000350000       12847# D2C               0.000080000   0.001232000   0.024800000       12847
# Q2C = 总延迟（队列到完成）# Q2D = 软件层延迟（队列到下发）# D2C = 硬件层延迟（下发到完成）

# 安装 iowatchersudo apt install iowatcher
# 生成 SVG 图表iowatcher -t trace -o io-pattern.svg
# 图表包含：IOPS 时间线、吞吐时间线、IO 延迟分布、IO 偏移量分布（可以看出是顺序还是随机）

六、fio 磁盘性能基准测试

# 安装 fiosudo apt install fio    # Debian/Ubuntusudo dnf install fio    # RHEL/Fedora

# 场景1：随机读 IOPS（模拟数据库查询）fio --name=rand-read --ioengine=io_uring --rw=randread \    --bs=4k --iodepth=64 --numjobs=4 --size=4G \    --direct=1 --runtime=60 --group_reporting \    --filename=/dev/nvme0n1  # 注意：直接测裸设备会销毁数据！测试用文件更安全
# 更安全的方式：在文件系统上测试fio --name=rand-read --ioengine=io_uring --rw=randread \    --bs=4k --iodepth=64 --numjobs=4 --size=4G \    --direct=1 --runtime=60 --group_reporting \    --directory=/mnt/test
# 场景2：随机写 IOPS（模拟数据库写入）fio --name=rand-write --ioengine=io_uring --rw=randwrite \    --bs=4k --iodepth=64 --numjobs=4 --size=4G \    --direct=1 --runtime=60 --group_reporting \    --directory=/mnt/test
# 场景3：顺序读吞吐（模拟大文件扫描、备份）fio --name=seq-read --ioengine=io_uring --rw=read \    --bs=1m --iodepth=16 --numjobs=1 --size=8G \    --direct=1 --runtime=60 --group_reporting \    --directory=/mnt/test
# 场景4：混合随机读写 7:3（模拟 OLTP 数据库）fio --name=mixed-rw --ioengine=io_uring --rw=randrw --rwmixread=70 \    --bs=4k --iodepth=32 --numjobs=4 --size=4G \    --direct=1 --runtime=60 --group_reporting \    --directory=/mnt/test

rand-read: (groupid=0, jobs=4): err= 0: pid=5678  read: IOPS=185.2k, BW=723MiB/s (758MB/s)    slat (nsec): min=1200, max=85000, avg=2850.00, stdev=1200.00    clat (usec): min=45, max=12500, avg=1350.00, stdev=680.00     lat (usec): min=48, max=12520, avg=1353.00, stdev=681.00    clat percentiles (usec):     |  1.00th=[  120],  5.00th=[  245], 10.00th=[  400],     | 50.00th=[ 1150], 90.00th=[ 2350], 95.00th=[ 2900],     | 99.00th=[ 4500], 99.50th=[ 5800], 99.99th=[10800]   bw (  KiB/s): min=680000, max=760000, per=100.00%, avg=740800.00  iops        : min=170000, max=190000, avg=185200.00

# 对比测试：同样参数，只换引擎# libaiofio --name=aio-test --ioengine=libaio --rw=randread \    --bs=4k --iodepth=128 --numjobs=1 --size=4G \    --direct=1 --runtime=30 --directory=/mnt/test
# io_uringfio --name=uring-test --ioengine=io_uring --rw=randread \    --bs=4k --iodepth=128 --numjobs=1 --size=4G \    --direct=1 --runtime=30 --directory=/mnt/test

七、文件系统选择

# ext4 高性能挂载参数mount -o noatime,nodiratime,barrier=0,data=writeback /dev/sda1 /data# noatime: 不更新访问时间戳，减少写入# nodiratime: 不更新目录访问时间# barrier=0: 关闭写屏障（仅在有 BBU 的 RAID 卡上使用，否则断电丢数据）# data=writeback: 元数据日志模式，比默认的 ordered 快但断电风险略高
# xfs 高性能挂载参数mount -o noatime,logbufs=8,logbsize=256k /dev/sda1 /data# logbufs=8: 增大日志缓冲区数量# logbsize=256k: 增大日志缓冲区大小
# /etc/fstab 持久化配置/dev/nvme0n1p1  /data  xfs  defaults,noatime,logbufs=8,logbsize=256k  0 2

八、IO 性能调优

# 查看当前预读值（单位：512字节扇区，默认 256 = 128KB）blockdev --getra /dev/sda
# 调大预读值（适合顺序读场景，如 Kafka、HDFS）sudo blockdev --setra 2048 /dev/sda   # 1MB 预读
# 调小预读值（适合纯随机读场景，如数据库 OLTP）sudo blockdev --setra 64 /dev/sda     # 32KB 预读
# 持久化配置（udev 规则）echo 'ACTION=="add|change", KERNEL=="sd[a-z]", ATTR{bdi/read_ahead_kb}="1024"' \    > /etc/udev/rules.d/61-readahead.rules

# 查看当前脏页参数sysctl vm.dirty_ratio vm.dirty_background_ratio vm.dirty_expire_centisecs vm.dirty_writeback_centisecs
# 参数说明：# vm.dirty_ratio = 20           # 脏页占内存 20% 时，写入进程被阻塞，同步刷盘（硬上限）# vm.dirty_background_ratio = 10 # 脏页占内存 10% 时，后台线程开始异步刷盘（软上限）# vm.dirty_expire_centisecs = 3000  # 脏页超过 30 秒必须刷盘# vm.dirty_writeback_centisecs = 500 # 后台刷盘线程每 5 秒唤醒一次

# 数据库服务器（低延迟优先，减少突发刷盘导致的延迟毛刺）sysctl -w vm.dirty_ratio=5sysctl -w vm.dirty_background_ratio=2sysctl -w vm.dirty_expire_centisecs=1000sysctl -w vm.dirty_writeback_centisecs=100
# 日志/流式写入服务器（吞吐优先，允许更多脏页缓冲）sysctl -w vm.dirty_ratio=40sysctl -w vm.dirty_background_ratio=20sysctl -w vm.dirty_expire_centisecs=6000sysctl -w vm.dirty_writeback_centisecs=500
# 持久化到 /etc/sysctl.d/60-io-tuning.confcat > /etc/sysctl.d/60-io-tuning.conf << 'EOF'vm.dirty_ratio = 5vm.dirty_background_ratio = 2vm.dirty_expire_centisecs = 1000vm.dirty_writeback_centisecs = 100EOFsysctl --system

# 查看块设备队列深度cat /sys/block/sda/queue/nr_requests# 默认值通常是 256
# NVMe 设备的硬件队列深度cat /sys/block/nvme0n1/queue/nr_requests
# 对于高并发 IO 场景，可以适当增大队列深度echo 1024 > /sys/block/sda/queue/nr_requests
# 查看当前 IO 合并策略cat /sys/block/sda/queue/nomerges# 0 = 允许合并（默认）  1 = 禁止前向合并  2 = 完全禁止合并# 纯随机 IO 场景可以设为 2，省去合并检查的开销

# 查看设备号（major:minor）ls -l /dev/sda# brw-rw---- 1 root disk 8, 0 ...  → 设备号 8:0
# 创建 cgroup 并设置 IO 限制mkdir -p /sys/fs/cgroup/backup-jobsecho"+io" > /sys/fs/cgroup/backup-jobs/cgroup.subtree_control
# 限制 sda 上的读写带宽为 50MB/s，IOPS 为 1000echo"8:0 rbps=52428800 wbps=52428800 riops=1000 wiops=1000" \    > /sys/fs/cgroup/backup-jobs/io.max
# 把备份进程加入这个 cgroupecho$BACKUP_PID > /sys/fs/cgroup/backup-jobs/cgroup.procs
# Kubernetes 中通过 Pod 的 resources 或 annotation 配置# 也可以用 io.latency 控制器设置延迟目标echo"8:0 target=5000" > /sys/fs/cgroup/db-workload/io.latency# 保证 db-workload 组的 IO 延迟不超过 5ms，其他组让路

九、常见 IO 问题排查案例

# 1. 先看 iostat 确认 IO 确实有问题iostat -xmt 1# 发现 w_await 从 0.5ms 涨到 15ms，wkB/s 从 20MB/s 涨到 180MB/s
# 2. iotop 找出谁在写sudo iotop -oP# 发现两个大户：# mysqld      → 20MB/s 写入（正常业务）# rsync       → 160MB/s 读取（备份任务在全量拷贝数据目录）
# 3. 确认 rsync 是定时任务触发的ps aux | grep rsync# root  5432  rsync -avz /var/lib/mysql/ backup-server:/backup/mysql/
# 4. rsync 的大量顺序读把磁盘带宽吃满，MySQL 的随机 IO 被挤压

# 方案1：用 ionice 降低备份任务优先级ionice -c 3 nice -n 19 rsync -avz /var/lib/mysql/ backup-server:/backup/mysql/
# 方案2：用 cgroup v2 限制备份任务的 IO 带宽echo "8:0 rbps=52428800 wbps=52428800" > /sys/fs/cgroup/backup/io.max
# 方案3：用 rsync 的 --bwlimit 限制传输速率rsync -avz --bwlimit=50000 /var/lib/mysql/ backup-server:/backup/mysql/# --bwlimit 单位是 KB/s，50000 = 50MB/s

# 1. iostat 看写入模式iostat -xmt -d sda 1# w/s=8500  wkB/s=34000  wareq-sz=4.0  w_await=3.5  %util=98
# 大量 4KB 小写入，这不像 ES 的正常行为（ES 的 segment merge 是大块顺序写）
# 2. 用 blktrace 看写入来源sudo blktrace -d /dev/sda -w 5 -o journal-traceblkparse -i journal-trace | grep "W" | awk '{print $NF}' | sort | uniq -c | sort -rn | head# 发现大量写入来自 [jbd2/sda1-8]，这是 ext4 的 journal 线程
# 3. 检查文件系统 journal 模式tune2fs -l /dev/sda1 | grep "Journal"# Default mount options: journal_data# journal_data 模式会把所有数据都写一遍 journal，写放大 2 倍！

# 切换到 ordered 模式（只对元数据做 journal，数据直接写）sudo mount -o remount,data=ordered /data
# 或者在 /etc/fstab 中修改/dev/sda1  /data  ext4  defaults,noatime,data=ordered  0 2
# 如果是 ES 这种自己管理数据一致性的应用，甚至可以用 writeback 模式# 但要确保有 UPS 或 BBU，否则断电可能丢数据

# 1. iostat 看详细指标iostat -xmt -d nvme0n1 1# r/s=45000  rkB/s=180000  r_await=0.08  aqu-sz=3.6  %util=100
# r_await 只有 0.08ms（80 微秒），完全正常# IOPS 45K，这块 NVMe 标称能跑 500K IOPS，远没到极限
# 2. 这是 %util 计算方式的问题# %util = (IO 请求数 * 每次 IO 耗时) / 采样间隔# 当并发 IO 足够多时，即使每个 IO 很快，%util 也会算到 100%# 对于多队列设备，%util 100% 不代表设备饱和

# Prometheus 告警规则（修正版）# 不再用 %util 告警 NVMe 设备，改用 await-alert:DiskIOHighLatencyexpr:|    rate(node_disk_io_time_weighted_seconds_total[5m])    / rate(node_disk_io_time_seconds_total[5m]) > 0.005for:5mlabels:    severity:warningannotations:    summary:"磁盘 IO 平均延迟超过 5ms"

十、bpftrace 追踪 IO 延迟

# bcc-tools 自带的 biolatency 脚本（最简单的用法）sudo biolatency-bpfcc -D 1# -D 按磁盘分别统计  1 每秒输出一次
# 输出示例：# disk = nvme0n1#      usecs               : count    distribution#          0 -> 1          : 0        |                                        |#          2 -> 3          : 0        |                                        |#          4 -> 7          : 125      |**                                      |#          8 -> 15         : 2840     |****************************************|#         16 -> 31         : 1950     |***************************             |#         32 -> 63         : 680      |*********                               |#         64 -> 127        : 245      |***                                     |#        128 -> 255        : 42       |                                        |#        256 -> 511        : 8        |                                        |#        512 -> 1023       : 3        |                                        |#       1024 -> 2047       : 1        |                                        |
# 大部分 IO 在 8-31 微秒完成，但有少量请求到了毫秒级——这就是长尾延迟

# 保存为 io-latency-by-process.btsudo bpftrace -e 'tracepoint:block:block_rq_issue{    @start[args->dev, args->sector] = nsecs;    @comm[args->dev, args->sector] = comm;}
tracepoint:block:block_rq_complete/@start[args->dev, args->sector]/{    $lat = (nsecs - @start[args->dev, args->sector]) / 1000;  // 转换为微秒    @latency[@comm[args->dev, args->sector]] = hist($lat);    delete(@start[args->dev, args->sector]);    delete(@comm[args->dev, args->sector]);}
END{    clear(@start);    clear(@comm);}'
# 输出会按进程名分别显示延迟直方图：# @latency[mysqld]:# [8, 16)    1250 |@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@|# [16, 32)    680 |@@@@@@@@@@@@@@@@@@@@@                   |# ...# @latency[rsync]:# [128, 256)  420 |@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@|# [256, 512)  380 |@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@    |# ...

# 追踪所有 IO 请求，显示进程名、延迟、扇区等sudo biosnoop-bpfcc -d nvme0n1
# 输出示例：# TIME(s)  COMM         PID   DISK      T SECTOR       BYTES  LAT(ms)# 0.000    mysqld       12847 nvme0n1   R 12345678     4096   0.08# 0.001    mysqld       12847 nvme0n1   R 12345686     4096   0.09# 0.003    jbd2/sda1-8  891   nvme0n1   W 98765432     16384  0.15# 0.850    rsync        5432  nvme0n1   R 55555555     131072 0.12
# 只看延迟超过 1ms 的慢 IOsudo biosnoop-bpfcc -d nvme0n1 -Q | awk '$NF > 1.0'

# 追踪 ext4 上超过 1ms 的操作sudo ext4slower-bpfcc 1
# 追踪 xfs 上超过 1ms 的操作sudo xfsslower-bpfcc 1
# 输出示例：# TIME     COMM         PID   T BYTES   OFF_KB   LAT(ms) FILENAME# 15:30:01 mysqld       12847 R 16384   1024     2.35    ibdata1# 15:30:01 mysqld       12847 S 0       0        5.80    ib_logfile0# T 列：R=read W=write O=open S=fsync# fsync 延迟 5.8ms，这可能是 journal 写入导致的

十一、IO 排查流程总结

系统卡顿/业务超时  |  vtop 看 %wa (iowait) ──── 低 → 不是 IO 问题，排查 CPU/内存/网络  |  高  viostat -xmt 1 ──── await 正常 → 可能是应用层阻塞，不是磁盘瓶颈  |  await 高  v判断设备类型 ──── NVMe → 看 await + IOPS，忽略 %util  |                HDD  → %util + await + aqu-sz 综合判断  viotop -oP ──── 找到 IO 大户进程  |  v分析 IO 模式 ──── wareq-sz/rareq-sz 小(4-8KB) → 随机 IO  |                wareq-sz/rareq-sz 大(128K+)  → 顺序 IO  v深入分析 ──── blktrace+btt 看各阶段延迟  |            bpftrace 看延迟分布和长尾  |            fio 做基准对比  v调优/解决 ──── 调度器/readahead/dirty ratio/cgroup 限制/硬件升级

十二、总结