说到I/O性能分析很多人第一反应是iostat、sar这些工具。但说实话它们只能告诉你「磁盘忙不忙」「延迟高不高」。真要定位问题根源你得深入到块设备层看看每个I/O请求到底经历了什么。这就是blktrace的用武之地。我个人习惯叫它「块设备界的strace」——它能追踪每一个I/O请求从诞生到完成的全生命周期。今天我们就来聊聊这个工具的原理和实战用法。15.1 blktrace的工作原理blktrace基于Linux内核的tracepoint机制工作。内核在块设备层的几个关键路径上埋了探针当I/O请求经过时就会触发事件记录。具体来说它追踪了五个核心事件点QQueuedI/O请求被创建并加入请求队列GGet request从请求队列中获取一个请求MMerge相邻的请求被合并成一个DDispatch请求被下发到设备驱动CComplete设备完成I/O操作返回结果这五个事件说白了就是I/O请求从生到死的完整旅程。你想想看一个读请求从应用层发出来经过VFS、文件系统、块设备层最后到磁盘控制器每一步都可能成为瓶颈。blktrace能帮你把每一步的耗时都拆开来看。核心思路blktrace记录的是内核事件不是网络抓包。它不会影响应用层的数据内容只记录I/O请求的元信息——扇区号、大小、方向、时间戳等。15.2 工具链全家桶blktrace不是单兵作战它有一套完整的工具链工具作用blktrace负责从内核采集事件数据写入文件blkparse解析blktrace生成的二进制数据输出可读格式btt对解析后的数据进行统计分析生成延迟分布blkrawverify验证采集数据的完整性我一般的工作流是先用blktrace采集再用blkparse看明细最后用btt做统计。三步走基本能把问题定位清楚。15.3 实战采集与分析先看一个最简单的例子。假设我们要监控/dev/sda的I/O行为# 采集数据持续10秒 blktrace -d /dev/sda -o trace -w 10 # 解析数据 blkparse -i trace -o trace.txt # 查看前几行 head -20 trace.txt输出大概长这样8,0 3 1 0.000000000 12345 A R 123456 1024 - (8,1) 789012 8,0 3 2 0.000001234 12345 Q R 123456 1024 [dd] 8,0 3 3 0.000002345 12345 G R 123456 1024 [dd] 8,0 3 4 0.000003456 12345 D R 123456 1024 [dd] 8,0 3 5 0.010002345 12345 C R 123456 1024 [dd]每一列的含义依次是设备号、CPU编号、序列号、时间戳、进程PID、事件类型、读写方向、起始扇区、长度、进程名。嗯这里要注意时间戳的单位是纳秒。你看上面这个例子从Q到D只用了3微秒左右但D到C用了10毫秒——说明瓶颈在设备端而不是内核的I/O调度。我的经验如果Q到D的延迟很高通常是I/O调度器的问题或者请求队列太长。如果D到C的延迟高那就是存储设备本身慢比如磁盘寻道、SSD垃圾回收等。15.4 用btt做统计分析看原始日志太费眼我更喜欢用btt直接出统计结果btt -i trace.blktrace.0 -o btt_output输出会包含每个阶段的平均延迟、最大延迟、I/O深度分布等。举个例子 All Devices Device | Q2G | G2M | M2D | D2C | Q2C --------|-------|-------|-------|-------|------- sda | 0.001 | 0.002 | 0.001 | 8.345 | 8.349 sdb | 0.002 | 0.001 | 0.002 | 3.210 | 3.215你看sda的D2C设备处理时间是8.3毫秒sdb只有3.2毫秒。这说明sda这台设备明显更慢。我在项目中遇到过类似情况最后发现是sda连在了一个共享的SAN上带宽被其他业务抢了。15.5 高级用法按进程过滤有时候你只关心某个进程的I/O行为。可以用-t参数按PID过滤blktrace -d /dev/sda -o trace -w 30 -t 12345或者采集完再用blkparse过滤blkparse -i trace -o trace_filtered.txt -t 12345这个功能特别实用。有一次我怀疑某个Java进程在做大量随机写用blktrace一抓果然它的I/O模式全是4KB的随机写而且Q2C延迟高达50ms。后来发现是它的WAL日志没做批量提交。15.6 避坑指南我曾经踩过的坑blktrace需要root权限普通用户跑不了采集期间会产生大量数据尤其是高IOPS场景。我曾经在SSD上抓了1分钟生成了2GB的trace文件blktrace本身有性能开销大约5%-10%。生产环境慎用建议在低峰期采集多盘场景下每个盘会生成独立的trace文件注意不要搞混15.7 知识体系总览下面这张图总结了blktrace的核心逻辑我建议你收藏一下以后排查问题时对照着看这张图把I/O请求的完整路径画出来了。从应用层一路往下经过VFS、文件系统最后进入块设备层。blktrace就是在块设备层的那五个事件点做记录。你排查问题时只要盯着Q2G、G2M、M2D、D2C这四个阶段的延迟基本就能定位瓶颈在哪。15.8 小结blktrace是我工具箱里最常用的块设备级工具。它不像iostat那样只给个平均值而是把每个I/O请求的细节都扒出来给你看。说白了它就是块设备层的「显微镜」。我个人建议你养成一个习惯在部署新业务或者调整存储配置后用blktrace跑一次基线数据。这样以后出问题时你就有对比的基准了。我在多个项目中都是靠这个办法快速定位问题的。一句话总结blktrace看细节blkparse看日志btt看统计。三件套配合使用块设备I/O问题无处遁形。
