blktrace工具定位硬盘时延高问题
先贴一个工具介绍，如下
Blktrace简介
blktrace是一个针对Linux内核中块设备IO层的跟踪工具，用来收集磁盘IO信息中当IO进行到块设备层（block）时的详细信息（如IO请求提交、入队、合并、完成等信息），是由Linux内核块设备层的维护者开发的，目前已经集成到内核2.6.17及其后内核版本中。blktrace可以获取IO请求队列的各种详细的情况，包括进行读写的进程名称、进程号、执行时间、读写的物理块号、块大小等。 blktrace工作原理
（1）blktrace测试时会分配物理机上逻辑CPU数量个线程，并且每一个线程绑定一个逻辑CPU来收集数据。 （2）blktrace在debugfs挂载的路径（默认/sys/kernel/debug）下每个线程产生一个文件，然后调用ioctl函数，通过系统调用交由内核处理，由内核经由debugfs文件系统往文件描述符写入数据。 （3）blktrace需要结合blkparse使用，由blkparse来解析blktrace产生的特定格式的二进制数据。 （4）blkparse仅打开blktrace产生的文件，从文件里面取数据进行解析展示。
下面先描述怎么使用工具判断问题的，最后再罗列整理下这个工具的其它用途，平时也没用过，也不大熟悉它的其它功能和各个参数，就是这次学到了这种定位判断方法
用这个工具可以很好的定位硬盘时延高的相关问题，比如本次涉及到这个工具的使用是因为遇到了现场nvme盘带宽和利用率异常的问题，如下图。应客户要求服务器厂商参与问题定位
1.png
接下来的blktrace，blkparse，bbt都属于blktrace包里的工具，首先直接获取一个存储设备或者文件系统的I/O数据,没设置时间的话需要手动ctrl C停止
blktrace –d /dev/xxxxx
然后当前执行目录下就有很多文件，如下图
2.png
我们把它合并统计一下，用下面这个命令
blkparse -i nvme0n1 -d nvme0n1.blktrace.bin
然后用bbt工具转化分析一下
btt -i nvme0n1.blktrace.bin > btt.log
然后直接查看这个文件，就有如下结果了
3.png
在看这个图之前需要了解一些原理，如下
数据中相关字母的含义，每个字母都是一个阶段
Q – 即将生成IO请求
|
G – IO请求生成
|
I – IO请求进入IO Scheduler队列
|
D – IO请求进入driver
|
C – IO请求执行完毕
根据以上步骤对应的时间戳就可以计算出I/O请求在每个阶段所消耗的时间：
Q2G – 生成IO请求所消耗的时间，包括remap和split的时间；
G2I – IO请求进入IO Scheduler所消耗的时间，包括merge的时间；
I2D – IO请求在IO Scheduler中等待的时间；
D2C – IO请求在driver和硬件上所消耗的时间；
Q2C – 整个IO请求所消耗的时间(Q2I + I2D + D2C = Q2C)，相当于iostat的await。
如果I/O性能慢的话，以上指标有助于进一步定位缓慢发生的地方：
D2C可以作为硬件性能的指标；
I2D可以作为IO Scheduler性能的指标
那么我这个数据中D2C占的比较多是比较合理的，设备层确实会占据较多时间，但是客户现场的结果如下，明显是应用层面的问题，最终客户确实在集群策略方面找到了问题原因
4.png
如下图就是IO 调度器的问题，所以I2D耗时比较大
5.png
其它原理和工具使用可以到网上写的比较好的博客上学习下
链接：
