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盘带宽和利用率异常的问题，如下图。应客户要求服务器厂商参与问题定位

接下来的blktrace，blkparse，bbt都属于blktrace包里的工具，首先直接获取一个存储设备或者文件系统的I/O数据,没设置时间的话需要手动ctrl C停止

blktrace –d /dev/xxxxx

然后当前执行目录下就有很多文件，如下图

我们把它合并统计一下，用下面这个命令

blkparse -i nvme0n1 -d nvme0n1.blktrace.bin

然后用bbt工具转化分析一下

btt -i nvme0n1.blktrace.bin > btt.log

然后直接查看这个文件，就有如下结果了

在看这个图之前需要了解一些原理，如下

数据中相关字母的含义，每个字母都是一个阶段

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占的比较多是比较合理的，设备层确实会占据较多时间，但是客户现场的结果如下，明显是应用层面的问题，最终客户确实在集群策略方面找到了问题原因

如下图就是IO 调度器的问题，所以I2D耗时比较大

其它原理和工具使用可以到网上写的比较好的博客上学习下

链接：

https://blog.csdn.net/RainbowBoy/article/details/80492336

https://blog.csdn.net/qq_23929673/article/details/93176725