blktrace工具源码
1.1.1 关于blktrace
我们知道,在iostat工具中,await表示单个I/O所需的平均时间,但它同时包含了I/O Scheduler所消耗的时间和硬件所消耗的时间,所以不能作为硬件性能的指标,至于iostat的svctm更是一个废弃的指标。而blktrace可以在这种场合就能派上用场,从中可以分析是IO Scheduler慢还是硬件响应慢。
Blktrace是一个用户态的工具,用来收集磁盘IO信息中当IO进行到块设备层(block层,所以叫blk trace)时的详细信息(如IO请求提交,入队,合并,完成等等一些列的信息)。使用者可以获取I/O请求队列的各种详细的情况,包括进行读写的进程名称、进程号、执行时间、读写的物理块号、块大小等等,是一个Linux下分析I/O相关内容的很好的工具。
目前已经集成到内核2.6.17及其之后的内核版本中。
1.1.2 关于blktrace源码
blktrace代码下载地址:
git clone git://git.kernel.dk/blktrace.git
或者从快照站点下载:
可以直接执行make 命令。
PS:需要安装libaio-dev包。
1.1.3 blktrace原理即io栈
一个I/O请求进入block layer之后,会经历下面的过程:
l  Remap: 可能被DM(Device Mapper)或MD(Multiple Device, Software RAID) remap到其它设备
l  Split: 可能会因为I/O请求与扇区边界未对齐、或者size太大而被分拆(split)成多个物理I/O
l  Merge: 可能会因为与其它I/O请求的物理位置相邻而合并(merge)成一个I/O
l  被IO Scheduler依照调度策略发送给driver
l  被driver提交给硬件,经过HBA、电缆(光纤、网线等)、交换机(SAN或网络)、最后到达存储设备,设备完成IO请求之后再把结果发回。
l blkparse显示的各指标点示意:
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。
D2C可以作为硬件性能的指标;
I2D可以作为IO Scheduler性能的指标。
其他见下表:
Act | Description |
A | IO was remapped to a different device |
B | IO bounced |
C | IO completion |
D | IO issued to driver |
F | IO front merged with request on queue |
G | Get request |
I | IO inserted onto request queue |
M | IO back merged with request on queue |
P | Plug request |
Q | IO handled by request queue code |
S | Sleep request |
T | Unplug due to timeout |
U | Unplug request |
X | Split |
1.1.4 btrecord、btreplay
btrecord用于记录由blktrace产生的I/O负载。其将会解析由blktrace产生的每一个文件,提取出将会用于I/O回放的I/O描述信息。
#blktrace /dev/vda -w 100
用blktrace产生负载文件,生成文件在当前目录下,默认文件名为vda.blktrace.0,vda为被测试设备。
btrecored -d ./ vda -v
注意命令中的空格,记录当前目录下,文件名为vda.blktrace.0 的Trace文件数据,输出文件名默认为:vda.replay.0。
btreplay -d ./ vda -W -v
btreplay用于重放I/O。其基于btrecord产生的数据文件。回放当前目录下的trace文件,默认为:vda.replay.0文件,-W表示允许写操作。
1.1.5 blkiomon
使用blkiomon来动态显示IO栈情况,命令如下:
./blktrace /dev/vda -a issue -a complete -w 10 -o - | ./blkiomon -I 1 -h -
1.1.6 btt
#blktrace -w 100 /dev/vda
blkparse查看的数据量比较大,不利于查看,通过btt可以对blktrace数据进行自动分析。先用blkparse可以把原本按CPU分别保存的文件合并成一个,文件名为vda.bin:
./blkparse -i vda -d vda.bin
执行btt对vda.bin进行分析:
#btt -i vdb.bin
1.1.7 blktrace工具使用
可以直接使用如下命令进行监控:
blktrace -d /dev/nvme0n1 -o test1
注意的是文件里面存的是二进制数据,需要blkparse来解析。
或者直接如下命令,实时解析输出,不过这个存在一个风险就是需要实时的将大量的事件进行排序:
blktrace -d /dev/nvme0n1 -o - | blkparse -i –
另外,blktrace也能使用C/S模式,
被测机器SUT上运行blktrace -l,然后在客户机上运行:
blktrace -d /dev/sda -h <server hostname>
此外还有工具verify_blkparse,用于检测blkparse工具输出的文件在时间上是否是正确的。Blkrawverfity用于blktrace工具输出的文件数据是否正确。
1.1.8 参考
1.2 (可)blktrace工具源码——下篇
上篇中介绍了blktrace工具,以及工具的使用和原理。
接下来我们一起剖析下blktrace工具源码。
直接来看main函数,调用setlocale函数设置地域化信息。调用getpagesize函数来获取页大小,继而获取在线CPU数量。
接着调用signal来设置信号处理函数:
signal(SIGINT, handle_sigint);
signal(SIGHUP, handle_sigint);
signal(SIGTERM, handle_sigint);
signal(SIGALRM, handle_sigint);
signal(SIGPIPE, SIG_IGN);
信号处理函数主要作用是快速停止跟踪,说白了就是调用ioctl来修改配置:
(void)ioctl(dpp->fd, BLKTRACESTOP);
然后通过函数handle_args来处理参数,根据执行参数设置相关静态变量.当然如果没有参数就调用show_usage函数来显示使用帮助。
最后调用run_tracers函数来启动磁盘跟踪.
1.2.1 工作模式
blktrace支持3中工作模式,代码中定义如下,主要参数是-l和-h来激活后面两个,默认就是第一个模式。
enum {
Net_none = 0,
Net_server,
Net_client,
};
1.2.2 blktrace架构
其实很多时候代码只是实现,虽然其中包含了架构的思想,但是在代码这层,架构看上去非常的扁平,缺少立体感。来看下blktrace的架构图,大体如下:
整体架构比较清晰,在IO栈中将相关事件给blktrace进行记录,最后由blkparse进行翻译成可读。
因为blktrace工具的作者本身就是内核中块I/O的maintainer.
重要的数据结构有blk_io_trace,位于blktrace_api.h文件中:
/*
* The trace itself
*/
struct blk_io_trace {
__u32 magic; /* MAGIC << 8 | version */
__u32 sequence; /* event number */
__u64 time; /* in nanoseconds */
__u64 sector; /* disk offset */
__u32 bytes; /*
__u32 action; /* what happened */
__u32 pid; /* who did it */
__u32 device; /* device identifier (dev_t) */
__u32 cpu; /* on what cpu did it happen */
__u16 error; /* completion error */
__u16 pdu_len; /* length of data after this trace */
};
其他的,待大家自己去挖掘发现了,祝玩得开心。
低调大师中文资讯倾力打造互联网数据资讯、行业资源、电子商务、移动互联网、网络营销平台。
持续更新报道IT业界、互联网、市场资讯、驱动更新,是最及时权威的产业资讯及硬件资讯报道平台。
转载内容版权归作者及来源网站所有,本站原创内容转载请注明来源。
- 上一篇
blktrace工具源码——上篇
1.1.1 关于blktrace 我们知道,在iostat工具中,await表示单个I/O所需的平均时间,但它同时包含了I/O Scheduler所消耗的时间和硬件所消耗的时间,所以不能作为硬件性能的指标,至于iostat的svctm更是一个废弃的指标。而blktrace可以在这种场合就能派上用场,从中可以分析是IO Scheduler慢还是硬件响应慢。 Blktrace是一个用户态的工具,用来收集磁盘IO信息中当IO进行到块设备层(block层,所以叫blk trace)时的详细信息(如IO请求提交,入队,合并,完成等等一些列的信息)。使用者可以获取I/O请求队列的各种详细的情况,包括进行读写的进程名称、进程号、执行时间、读写的物理块号、块大小等等,是一个Linux下分析I/O相关内容的很好的工具。 目前已经集成到内核2.6.17及其之后的内核版本中。 1.1.2 关于blktrace源码 blktrace代码下载地址: git clone git://git.kernel.dk/blktrace.git 或者从快照站点下载: http://brick.kernel.dk/snaps...
- 下一篇
使用last命令找出是谁重启了你的服务器(linux)
在运维过程中,经常出现推锅的情况,在我运维Azure的时候,有时会发生服务器重启,因为厂商没有把服务设置成开机自启的状态,在夜间重启后,到中午才发现服务有问题(MD,我想问问你们是干什么吃的),发现服务有问题,怀疑服务器重启啦,推锅活动开始了,厂商开发推锅运维,运维推锅监控,然后在推锅Azure,不过有多一半的问题是因为Azure虚机所在的物理节点故障导致虚机迁移(我不是在黑Azure,说实话易用性比不上国内的阿里云,但是如果你用的是全windwos架构,那你选择Azure是没错的,因为它可以和你本地的服务无缝迁移)说了这么多,就是一个服务器重启的事,还有一个就是就是因为服务崩了,导致服务不能正常工作,但是厂商就会推锅给运维,说是服务器重启了,没办法,你就要给他证明不是服务器的问题,现在的运维工作往往就是这样,所以我们可以使用last命令去查看重启记录还有登陆记录。 image.png 其中: 第一列:用户名 第二列:终端位置。(pts/0通过ssh或者telnet远程连接的用户,tty:直接连接到计算机或者本地用户) 第三列:登陆IP或者内核(看到0.0或者什么都没有,意味着用户通过...
相关文章
文章评论
共有0条评论来说两句吧...
文章二维码
点击排行
-
Docker使用Oracle官方镜像安装(12C,18C,19C)
- Springboot2将连接池hikari替换为druid,体验最强大的数据库连接池
- CentOS8编译安装MySQL8.0.19
- Docker快速安装Oracle11G,搭建oracle11g学习环境
- SpringBoot2配置默认Tomcat设置,开启更多高级功能
- MySQL8.0.19开启GTID主从同步CentOS8
- CentOS7,8上快速安装Gitea,搭建Git服务器
- Jdk安装(Linux,MacOS,Windows),包含三大操作系统的最全安装
- SpringBoot2编写第一个Controller,响应你的http请求并返回结果
推荐阅读
最新文章
- SpringBoot2整合Redis,开启缓存,提高访问速度
- Jdk安装(Linux,MacOS,Windows),包含三大操作系统的最全安装
- SpringBoot2配置默认Tomcat设置,开启更多高级功能
- Springboot2将连接池hikari替换为druid,体验最强大的数据库连接池
- SpringBoot2整合MyBatis,连接MySql数据库做增删改查操作
- Hadoop3单机部署,实现最简伪集群
- Docker使用Oracle官方镜像安装(12C,18C,19C)
- MySQL8.0.19开启GTID主从同步CentOS8
- SpringBoot2编写第一个Controller,响应你的http请求并返回结果
- Windows10,CentOS7,CentOS8安装MongoDB4.0.16