定位Linux IO瓶颈需先用iostat -x识别设备级异常（%util>80%、await远高于svctm、avgqu-sz>1），再用blktrace分析Q2I/I2D/D2C各阶段耗时，精准定位调度层、驱动层或硬件层问题。
定位 Linux IO 瓶颈不能只看 iostat 的 %util 或 await，它们只能告诉你“有没有问题”，无法说明“问题出在哪一层”。iostat 给的是设备级汇总结果，blktrace 则能拆解单个 I/O 请求从生成到完成的完整生命周期——这才是精准定位调度层、驱动层还是硬件层瓶颈的关键。
iostat 快速识别设备级异常
iostat -x 2 是第一步，重点关注三项：
- %util > 80%：设备持续忙碌，已接近饱和，但不等于硬件慢（可能是大量小 IO 堆积在队列）
- await 显著高于 svctm（或 r_await/w_await 分离后仍高）：说明请求在进入设备前等待时间长，大概率是调度器排队或队列深度过大
- avgqu-sz（平均队列长度）持续大于 1：尤其在 SSD 上仍 >2，提示上层下发过载或调度策略不匹配
注意：svctm 在现代内核中已弃用，实际应结合 blktrace 的 D2C（driver to complete）时间判断真实硬件响应能力。
blktrace 拆解 I/O 路径各阶段耗时
blktrace 不是替代 iostat，而是补全它的盲区。它按事件类型标记 I/O 所处阶段：
- Q：I/O 请求被提交到 block layer（应用层发出）
- G：generic request 生成（可能含 remap 或 split）
- I：进入 I/O scheduler 队列（如 mq-deadline、bfq）
- D：由 scheduler 下发给 driver（关键分界点）
- C：硬件完成并返回（completion）
通过时间戳差值可精确计算：
- Q2I：生成到入队时间 → 反映内核路径开销（如文件系统、页缓存）
- I2D：队列等待时间 → 直接体现调度器效率与并发压力
- D2C：驱动到完成时间 → 真实硬件服务时间（不含传输链路延迟）
- Q2C = await（iostat 中的值），即端到端总延迟
例如：若 Q2C=50ms，I2D=42ms，D2C=8ms，说明瓶颈在调度队列，而非磁盘本身。
配合使用：从宏观到微观的排查链
典型操作流程如下：
- 先跑 iostat -x 2 5，确认 /dev/sdb %util 持续 95%、await 达 60ms
- 再执行 blktrace -d /dev/sdb -w 30 -o sdb_trace 抓取 30 秒数据
- 用 blkparse -i sdb_trace 查看原始事件流，或用 btt -i sdb_trace 生成汇总报告（含 Q2C、I2D、D2C 平均值与分布）
- 若 btt 显示 I2D 占 Q2C 90%，则调优方向是更换 IO scheduler（如从 deadline 改为 bfq）、调整 nr_requests 或关闭 noop 的 queue depth 限制
- 若 D2C 本身超过 15ms（对 NVMe 应
注意前提与常见陷阱
使用 blktrace 前必须确保：
- debugfs 已挂载：mount -t debugfs debugfs /sys/kernel/debug
- 目标设备未被 LVM/MD 层隐藏；若用了 device mapper，需追踪底层物理盘（如 dm-0 对应的 sda）
- 避免在高负载生产环境长时间运行；建议用 -w 限定时间，-b 控制缓冲大小（如 -b 2M）防内存溢出
- blktrace 输出按 CPU 分文件（如 sdb_trace.0、sdb_trace.1），需用 blkparse -i 统一处理或 btt -i 自动聚合
它不复杂但容易忽略。
