使用：
blktrace工具用于分析内核块设备层以及磁盘的性能，也可用于分析在该磁盘上运行的业务IO模型，我们通常用blktrace分析虚拟机里云盘的时延以及业务IO模型。 (1) blktrace 工具安装，blktrace工具包一般会包含在系统的iso中，可以通过yum install 或rpm安装 (2) mount -t debugfs debugfs /sys/kernel/debug (3) 使用blktrace收集IO信息 blktrace -d /dev/vdb -w 30 -d: 表示收集哪个磁盘的IO，可以设置多个 -w: IO收集时间，单位为s，到时间会命令自动退出，如果不设置，可以用ctrl + c 退出 blktrace退出后，会生成多个以磁盘名开头的多个文件。 (4) 使用blkparse工具对收集到信息进行解析。 blkparse -i vdb -d vbd.blktrace.bin -d: 表示将结果输出到文件中 blkparse输出结果： 43,0 15 172150 0.323236306 3043800 M W 21102073 + 1 [kworker/u898:1] 各字段的含义见下表： 字段 含义 43,0 主设备号，次设备号，即主设备号为43，次设备号为0 15 CPU ID，当前动作在哪个CPU上执行 172150 序列号 0.323236306 当前时间发生的时间戳，s.ns 3043800 进程ID M 动作表示，M表示合并操作，其他动作下文会有解释 W R: 读 W: 写 S: 同步 D: 擦除 21102073 + 1 操作起始地址和offset，offset单位为扇区 [kworker/u898:1] 命令或进程的名字 blkparse输出非常多，不利于问题分析，我一般只关注最后这一截，其他用btt工具分析以后再看。
从这个结果可以判断出磁盘读写IO比例 (5) btt 工具分析结果 btt -i vbd.blktrace.bin
一个IO进入块层后，生命周期如下： IO 需求生成 -> IO 请求生成(G) -> 进入设备队列(I) -> 同设备 IO 请求按照文件系统优化策略合并成一个大请求(M) -> 请求交付给硬件设备处理(D) -> IO 读写完成(C) Q2Q：表示2次IO请求的时间间隔。在NetMax单并发性能分析中，我们是根据这个判断磁盘IO不是整个任务的关键路径，因为在NetMax执行单并发任务过程中，该项平均值在380ms, 最大值可能有几十s Q2G ：IO 生成开始进入 IO 队列 到为这个 IO 生成一个完整 IO 请求的时间。 G2I ： 完整 IO 请求到该请求插入设备队列的时间 Q2M ：IO 生成到在设备队列中和其他 IO 请求合并完成的时间 I2D ： IO 生成到 IO请求合并完成并开始交由设备处理的时间。如果这个时间很长，可以考虑给磁盘换一个IO调度算法试试 M2D：IO 请求合并完成到开始交由设备处理的时间 D2C ： 请求的服务时间，设备真正处理 IO 请求的总时间。对于后端为Ceph的虚拟机场景，这个时间可反应出qemu层和Ceph层总的处理时间。这个时间减去rbd的时间，基本等于qemu的处理时间。 Q2C：块设备层的整体服务时间
btt还可以加一些参数，过滤出自己想要的信息，比如常用的 btt -i vbd.blktrace.bin -B offset 按读写混合生成3个文件，表示每个读写请求时间戳，读写起始地址和offset，我们根据这个输出结果，可判断出磁盘IO是顺序还是随机，每个IO大小大概是多少。 需要注意的是，在纯读和纯写场景，是会生成两个文件。 比如，从下面这个例子中，我们可以看出来，磁盘IO是个顺序的，每个IO大小为64K。