在 Linux 性能诊断领域，I/O 瓶颈往往是最隐蔽、最难定位的问题之一。CPU 飙高有 top，内存吃紧有 free，网络拥塞有 tcpdump，但当磁盘 I/O 成为系统瓶颈时，很多工程师的第一反应是“看 iostat”，然后对着 %util 接近 100% 的输出陷入沉默——知道磁盘忙，却不知道谁在忙、忙在哪个文件、忙在哪种操作上。
这正是面试官爱问这道题的原因：它考察的不是单一工具的使用，而是分层定位问题的系统性思维。iostat、iotop、blktrace 恰好构成了从宏观到微观、从现象到根因的完整排查链路。
第一层：iostat —— 确认“是不是 I/O 瓶颈”
iostat 是整个排查链路的起点。它的核心价值在于快速判断系统是否存在 I/O 层面的压力，而不是立刻揪出元凶。
执行 iostat -x 1，重点关注几列：
%util：设备繁忙程度。接近 100% 说明设备几乎一直在处理 I/O 请求。但要注意，对于 SSD 和 RAID 阵列，%util可能因并行处理能力而失真，不能单独作为瓶颈判据。await：平均每次 I/O 的等待时间（毫秒）。这是最关键的指标。如果await远高于正常值（机械盘通常 < 20ms，SSD 通常 < 1ms），说明 I/O 请求在队列中积压严重。r/s和w/s：每秒读写次数。结合await可以判断是 IOPS 打满还是吞吐打满。aqu-sz（avgqu-sz）：平均请求队列长度。队列持续增长是瓶颈的强信号。
面试要点：%util 高不等于瓶颈，await 高且 aqu-sz 持续增长才是。如果 %util 高但 await 正常，可能是设备本身并行能力强，未必是问题。
iostat 能告诉你“磁盘很忙”，但无法告诉你“谁在忙”。这就引出了下一层。
第二层：iotop —— 定位“哪个进程在制造 I/O”
确认存在 I/O 压力后，下一步是找到罪魁祸首进程。iotop 的作用相当于 I/O 领域的 top。
执行 iotop -oP（-o 只显示有 I/O 活动的进程，-P 显示进程而非线程），输出中重点关注：
DISK READ/DISK WRITE：进程的实际磁盘读写速率。SWAPIN：进程因换页导致的 I/O 等待占比。如果这个值很高，说明内存不足正在引发 swap I/O，问题根源可能在内存而非磁盘。IO>：进程等待 I/O 的时间占比。
典型场景：数据库服务器 await 飙升，iotop 显示是 mysqld 在疯狂写入。此时你知道了进程，但还不知道它在写哪个文件、是顺序写还是随机写、是 fsync 频繁还是批量刷盘。要回答这些问题，需要进入第三层。
面试要点：iotop 需要 root 权限，且在高 I/O 场景下本身可能消耗较多 CPU。生产环境中如果 iotop 不可用，可以用 pidstat -d 1 作为替代，它能按进程输出读写 KB 数。
第三层：blktrace —— 深入“I/O 在块层的完整生命周期”
blktrace 是块设备层的“X 光机”。它不关心进程或文件系统，而是直接追踪 I/O 请求在块设备队列中的完整生命周期：从进入队列（Q）、合并（M）、下发到驱动（D）、完成（C）的每一个阶段。
基本用法：
# 采集 10 秒数据
blktrace -d /dev/sda -o trace -w 10
# 解析为可读格式
blkparse -i trace.blktrace.* -o parsed.txt
# 或直接查看汇总统计
btt -i trace.blktrace.* -o btt_out
blkparse 输出中，每个 I/O 请求都有时间戳和事件类型。通过分析 Q→D→C 的时间差，可以精确判断延迟发生在哪个阶段：
- Q→D 时间长：请求在队列中排队久，说明设备处理能力不足或队列深度设置不合理。
- D→C 时间长：请求下发到设备后完成慢，说明设备本身响应慢（可能是磁盘故障、RAID 降级、SSD 磨损）。
- 大量 M（合并）事件：说明相邻 I/O 被合并，可能是顺序写场景。
- 大量 Q 但 D 很少：说明 I/O 调度器在合并或排序，可能存在调度器配置问题。
更实用的方式是用 btt 生成汇总报告，它会直接给出 Q2D、D2C、Q2C 的平均延迟和分布，让你一眼看出延迟瓶颈在队列还是在设备。
面试要点：blktrace 对生产系统有性能开销，且需要 root。它通常用于事后深度分析，而不是日常监控。面试中如果能说出“用 btt 看 Q2C 延迟分布”或“对比 D2C 时间判断是设备慢还是队列慢”，会显著加分。
三层工具的组合逻辑
这三层不是孤立的，而是一条漏斗式排查链路：
iostat：系统级——有没有 I/O 瓶颈？瓶颈在哪个设备？iotop/pidstat -d：进程级——哪个进程在制造 I/O？读还是写？swap 还是磁盘？blktrace/btt：块设备级——I/O 延迟发生在队列还是设备？是顺序还是随机？合并情况如何？
在实际面试中，面试官往往还会追问：“如果 iostat 显示 await 高，但 iotop 看不到明显进程怎么办？” 这时要考虑：I/O 可能来自内核线程（如 kworker、kswapd）、NFS 等网络文件系统、或者容器环境中的其他 namespace。blktrace 此时就是唯一能穿透这些抽象层的工具。
反过来，如果 blktrace 显示设备层延迟正常，但应用仍然感觉慢，那问题可能不在块设备层，而在文件系统层（如 ext4 的 journal 提交、XFS 的日志刷盘）或应用层的同步策略（如 fsync 调用频率）。这时需要结合 strace 观察系统调用，或使用 perf 进行更底层的分析。
总结
iostat、iotop、blktrace 分别对应 I/O 瓶颈定位的三个层次：确认现象、定位进程、深入块层。面试中回答这道题，关键不是背诵每个命令的参数，而是展示出“从宏观到微观、从现象到根因”的排查思路。能说清每个工具解决什么问题、在什么阶段使用、以及它们之间的衔接关系，就已经超越了大多数候选人。
未经允许不得转载：任鹏个人博客 » Linux 面试题：iostat、iotop、blktrace 如何定位 I/O 瓶颈
