在之前的文章中介绍了如何使用blktrace 以及其工作原理和架构。我们知道blktrace 跟踪块设备的统计信息,每个CPU会有一个文件存储,然后通过blkparse可以将这些文件整合成一个文件来显示。
不过blkparse显示的文件过于庞大,而通过btt分析后会发现监控数据变得更加有意义。
监控获得数据
#blktrace -d /dev/sda -o sdatest
合并多个文件
#blkparse -i sdatest -d sdatest.bin
#btt -i sdatest.bin
IO时间主要是分为三个区域:
n  插入或合并IO到请求队列的时间,计算从块层到插入,即Q2I(Q2I=Q2G+G2I)
n  请求队列到驱动的时间,即是I2D。
n  驱动和设备时间,即是D2C.
此外还有还有Q2Q表示IO交到块层的时间。系统等待请求的时间在Q2G中。一般情况下Q2C=Q2I+I2D+D2C,说一般情况因为有些IO会会执行merge。
把大写字母函数的表,再次方便查找:
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 |
显示所有IO的平均时间,如下
==================== All Devices ====================
ALL MIN AVG MAX N
--------------- ------------- ------------- ------------- -----------
Q2Q 0.000001946 0.091683105 2.044408235 23
Q2G 0.000000414 0.000033828 0.000674679 25
G2I 0.000000102 0.000144889 0.002673577 25
Q2M 0.000000182 0.000000856 0.000002371 4
I2D 0.000000470 0.004403646 0.005128490 16
M2D 0.000004614 0.003767183 0.005123517 4
D2C 0.000103260 0.003153379 0.043896995 20
Q2C 0.000105885 0.007446862 0.043903980 20
第一部分中得到设备的平均延时,第二部分得到各个阶段消耗比例得到定性分析,如下图:
==================== Device Overhead ====================
DEV | Q2G G2I Q2M I2D D2C
---------- | --------- --------- --------- --------- ---------
( 8, 0) | 0.5678% 2.4320% 0.0023% 47.3074% 42.3451%
---------- | --------- --------- --------- --------- ---------
Overall | 0.5678% 2.4320% 0.0023% 47.3074% 42.3451%
==================== Device Merge Information ====================
DEV | #Q #D Ratio | BLKmin BLKavg BLKmax Total
---------- | -------- -------- ------- | -------- -------- -------- --------
( 8, 0) | 25 25 1.0 | 1 672 2560 16808
Q表示传入的IO请求,D表示合并后发出的请求,此外还能看到平均IO块大小为672。
用于显示连续队列和提交IO之间的扇区距离。NSEEKS表示提交到驱动的IO寻道次数, MEAS表示IO之间距离,MEDIA为0表示向前和向后寻道次数一样,MODE中数值表示块IO中连续的扇区,这部分比较晦涩。
包含Q2Q和D2D两部分,Q2Q是到达的IO请求之间,D2D是驱动中处理的IO.请求
==================== Device Q2Q Seek Information ====================
DEV | NSEEKS MEAN MEDIAN | MODE
---------- | --------------- --------------- --------------- | ---------------
( 8, 0) | 24 5406419.2 0 | 0(8)
---------- | --------------- --------------- --------------- | ---------------
Overall | NSEEKS MEAN MEDIAN | MODE
Average | 24 5406419.2 0 | 0(8)
==================== Device D2D Seek Information ====================
DEV | NSEEKS MEAN MEDIAN | MODE
---------- | --------------- --------------- --------------- | ---------------
( 8, 0) | 25 5190101.0 0 | 0(9)
---------- | --------------- --------------- --------------- | ---------------
Overall | NSEEKS MEAN MEDIAN | MODE
Average | 25 5190101.0 0 | 0(9)
队列不是无限的的,必然存在队列阻塞情况,这个就是现实队列阻塞,不能被驱动处理。这里的统计信息就是现实不能被处理的比例,如下图:
==================== Plug Information ====================
DEV | # Plugs # Timer Us | % Time Q Plugged
---------- | ---------- ---------- | ----------------
( 8, 0) | 12( 0) | 0.032358934%
DEV | IOs/Unp IOs/Unp(to)
---------- | ---------- ----------
( 8, 0) | 2.1 0.0
---------- | ---------- ----------
Overall | IOs/Unp IOs/Unp(to)
Average | 2.1 0.0
有时候需要关注请求在IO调度上花费的时间。
DEV | Avg Reqs @ Q
---------- | -------------
( 8, 0) | 4.4
使用--all-data或-A可以显示更详细信息。
可以显示每个设备的在各个阶段的统计数据。
活动数据文件的格式容易被画图和分析,如下:
# Total System
# Total System : q activity
0.000000624 0.0
0.000000624 0.4
0.004054842 0.4
0.004054842 0.0
2.048463077 0.0
2.048463077 0.4
2.108712044 0.4
2.108712044 0.0
文件中数据是划分成对的,每对包含队列信息和完成信息。