一、如何正确分析IO性能
1.1 BLKTRACE分析IO性能
之前的文章已经说明，要是系统发生I/O性能问题，我们常用的命令是无法精确定位问题（内核I/O调度器消耗的时间和硬件消耗的时间，这个不能作为性能指标），这时候blktrace就可以用来分析，它记录了I/O整个过程，从中可以分析是I/O调度器慢还是硬件响应慢。
1.2 BLKTRACE原理
# man blktrace DESCRIPTION： blktrace is a block layer IO tracing mechanism which provides detailed information about request queue operations up to user space. There are three major components: a kernel component, a utility to record the i/o trace information for the kernel to user space, andutilities to analyse and view the trace information. # 大概意思就是说： # blktrace是一个块层(block layer)IO跟踪机制，将请求队列的详细信息发送到用户空间 # 主要有三个组件： # 1. 内核组件 # 2. 记录内核到用户空间的I/O追踪信息的程序 # 3. 分析、展示I/O追踪信息的程序
1.2.1 执行过程分析
- 可能会被Device Mapper映射到其它设备 ➡ Remap
- 可能会因为I/O请求size太大而被拆分成多个I/O请求 ➡ Split
- 可能因为与其它I/O请求的物理位置相邻而合并 ➡ Merge
- 然后通过Device driver交给硬件；如：分布式存储经过HBA、光纤、SAN交换机（网络）等最后到达存储设备，设备完成I/O请求之后再把结果返回给用户空间。如下图：
1.3 执行过程解析
通过blktrace将结果输出到屏幕，然后用blkparse将屏幕中的结果作为输入，最后将分析结果输出到屏幕，需要注意的是blktrace不具备分析功能，需要借助blkparse进行分析！！！
# blktrace -d /dev/sda -o - | blkparse -i - 8,0 0 1 0.000000000 8702 A WS 13104216 + 8 <- (8,3) 11258968 8,0 0 2 0.000001717 8702 Q WS 13104216 + 8 [mysqld] 8,0 0 3 0.000003721 8702 G WS 13104216 + 8 [mysqld] 8,0 0 4 0.000004734 8702 I WS 13104216 + 8 [mysqld] 8,0 0 5 0.000006124 8702 D WS 13104216 + 8 [mysqld] 8,0 0 6 0.000035396 0 C WS 13104216 + 8 [0] 8,0 0 7 1.000409841 8702 A WS 13104216 + 8 <- (8,3) 11258968 8,0 0 8 1.000410566 8702 Q WS 13104216 + 8 [mysqld] 8,0 0 9 1.000412044 8702 G WS 13104216 + 8 [mysqld] 8,0 0 10 1.000412785 8702 I WS 13104216 + 8 [mysqld] 8,0 0 11 1.000413498 8702 D WS 13104216 + 8 [mysqld] 8,0 0 12 1.000438822 0 C WS 13104216 + 8 [0] 8,0 0 13 1.018085707 20501 A W 96409432 + 8 <- (8,3) 94564184 8,0 0 14 1.018085964 20501 Q W 96409432 + 8 [kworker/u32:0] 8,0 0 15 1.018086720 20501 G W 96409432 + 8 [kworker/u32:0] 8,0 0 16 1.018087010 20501 I W 96409432 + 8 [kworker/u32:0] 8,0 0 17 1.018087394 20501 D W 96409432 + 8 [kworker/u32:0] 8,0 0 18 1.018093866 20501 A W 96411880 + 8 <- (8,3) 94566632 8,0 0 19 1.018094103 20501 Q W 96411880 + 8 [kworker/u32:0] 8,0 0 20 1.018094495 20501 G W 96411880 + 8 [kworker/u32:0] 8,0 0 21 1.018094639 20501 I W 96411880 + 8 [kworker/u32:0] 8,0 0 22 1.018094963 20501 D W 96411880 + 8 [kworker/u32:0] 8,0 0 23 1.018106915 0 C W 96409432 + 8 [0]
1.3.1 字段解释
- 第一列：主次设备号
- 第二列：CPU
- 第三列：序列号
- 第四列：时间戳
- 第五列：PID进程号
- 第六列：具体事件 ➡ 后续详解
- 第七列：具体的动作(读、写等)
- 第八列：磁盘起始块 + 操作的块的数量
- 第九列：进程名和具体的命令
1.3.2 第六列解释
- A：IO被重新映射到不同的设备
- C：IO请求执行完毕
- D：IO请求进入Driver
- G：IO请求生成
- I：IO请求进入IO调度器队列
- M：IO返回与队列中的请求合并
- P： 当一个I/O入队一个空队列时，Linux会锁住这个队列，不处理该I/O，这样做是为了等待一会，看有没有新的I/O进来，可以合并
- Q：即将生成IO请求
- S：没有可用的request结构体，也就是I/O满了，只能等待有request结构体完成释放
- T：超时断开
- U：当队列中已经有I/O request时，会放开这个队列，准备向磁盘驱动发送该I/O。
- X： 对于做了Raid或进行了device mapper(dm)的设备，进来的IO可能需要切割，然后发送给不同的设备
1.3.3 第六列代表了IO经过的各阶段
1.3.4 IO的生命周期以及计算方法
- Q2G：生成IO请求所消耗的时间，包括remap和split的时间
- G2I：IO请求进入IO调度器所消耗的时间，包括了merge的时间
- I2D：IO请求在IO调度器中等待的时间
- D2C：IO请求在Driver上和硬件上所消耗的时间
- Q2C：整个IO请求所消耗的时间即：Q2I + I2D + D2C = Q2C
- 以上指标有助于进一步定位缓慢发生的地方
- D2C：可以作为硬件性能的指标
- I2D：可以作为IO调度器的性能指标
后续通过写脚本可以非常值观的统计IO读写数量、延迟、块大小等信息！