fio测试服务器和结果解释

一、下载

wget http://brick.kernel.dk/snaps/fio-2.1.7.tar.bz2

 

 

 

二、安装

要先安装libaio-devel, centos下

 

$ yum install libaio-devel

$ ./configure

$ make

$ make install

 

若要启动gfio，需安装gtk2，configure时加上--enable-gfio

 

$ yum install libaio-devel

$ yum install gtk2

$ yum install gtk2-devel

$ ./configure --enable-gfio

$ make

$ make install

 

[root@oracle gg]# tar -xvf fio-2.1.7.tar.bz2 

[root@oracle gg]# cd fio-2.1.7

[root@oracle fio-2.1.7]# ./configure 

[root@oracle fio-2.1.7]# make && make install

 

三、使用样例

顺序读：

fio -filename=/dev/sdb1 -direct=1 -iodepth 1 -thread -rw=read -ioengine=psync -bs=16k -size=200G -numjobs=10 -runtime=1000 -group_reporting -name=mytest

随机写：

fio -filename=/dev/sdb1 -direct=1 -iodepth 1 -thread -rw=randwrite -ioengine=psync -bs=16k -size=200G -numjobs=10 -runtime=1000 -group_reporting -name=mytest

顺序写：

fio -filename=/dev/sdb1 -direct=1 -iodepth 1 -thread -rw=write -ioengine=psync -bs=16k -size=200G -numjobs=10 -runtime=1000 -group_reporting -name=mytest

混合随机读写：

fio -filename=/dev/sdb1 -direct=1 -iodepth 1 -thread -rw=randrw -rwmixread=70 -ioengine=psync -bs=16k -size=200G -numjobs=10 -runtime=1000 -group_reporting -name=mytest -ioscheduler=noop

参数说明

filename：测试的系统盘目录。

direct：测试绕过机器自带的buffer，使测试结果更真实。

iodepth：设置IO队列的深度。

rw：测试读写类型。

ioengine：io引擎方式。

bs：数据块大小。

size：测试文件的大小。

numjobs：测试次数。

runtime：测试时间。

rwmixwrite：在混合读写的模式下，写占的权重。

group_reporting：测试结果汇总每个进程的信息。

lockmem：测试使用内存大小。

zero_buffers：测试过程使用0初始化系统buffer。

nrfiles：测试过程中每个进程生成文件的数量。

 

四、测试

[root@oracle fio-2.1.7]# fio -filename=/dev/sdb2 -direct=1 -iodepth 1 -rw=randread -ioengine=sync -bs=16k -size=2G -numjobs=10 -runtime=1000 -group_reporting -name=mytest

mytest: (g=0): rw=randread, bs=16K-16K/16K-16K/16K-16K, ioengine=sync, iodepth=1

...

fio-2.1.7

Starting 10 processes

Jobs: 2 (f=2): [____r___r_] [99.6% done] [20666KB/0KB/0KB /s] [1291/0/0 iops] [eta 00m:04s]s]

mytest: (groupid=0, jobs=10): err= 0: pid=15148: Mon Dec 14 08:53:40 2015

  read : io=20148MB, bw=20631KB/s, iops=1289, runt=1000009msec

    clat (usec): min=0, max=172813, avg=7759.95, stdev=5650.98

     lat (usec): min=0, max=172814, avg=7760.55, stdev=5650.98

    clat percentiles (usec):

     |  1.00th=[  241],  5.00th=[ 1352], 10.00th=[ 2416], 20.00th=[ 3792],

     | 30.00th=[ 4832], 40.00th=[ 5728], 50.00th=[ 6560], 60.00th=[ 7456],

     | 70.00th=[ 8768], 80.00th=[10688], 90.00th=[14272], 95.00th=[18304],

     | 99.00th=[28288], 99.50th=[33024], 99.90th=[45824], 99.95th=[51968],

     | 99.99th=[73216]

    bw (KB  /s): min=  734, max=617746, per=10.46%, avg=2157.36, stdev=7736.12

    lat (usec) : 2=0.07%, 50=0.01%, 100=0.68%, 250=0.32%, 500=2.79%

    lat (usec) : 750=0.35%, 1000=0.17%

    lat (msec) : 2=3.32%, 4=14.10%, 10=54.98%, 20=19.50%, 50=3.63%

    lat (msec) : 100=0.06%, 250=0.01%

  cpu          : usr=0.15%, sys=0.38%, ctx=1290338, majf=0, minf=322

  IO depths    : 1=100.0%, 2=0.0%, 4=0.0%, 8=0.0%, 16=0.0%, 32=0.0%, >=64=0.0%

     submit    : 0=0.0%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.0%, 64=0.0%, >=64=0.0%

     complete  : 0=0.0%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.0%, 64=0.0%, >=64=0.0%

     issued    : total=r=1289469/w=0/d=0, short=r=0/w=0/d=0

     latency   : target=0, window=0, percentile=100.00%, depth=1

 

Run status group 0 (all jobs):

   READ: io=20148MB, aggrb=20631KB/s, minb=20631KB/s, maxb=20631KB/s, mint=1000009msec, maxt=1000009msec

 

Disk stats (read/write):

  sdb: ios=1289181/2177, merge=0/2172, ticks=9977871/104, in_queue=9977596, util=99.89%

 

五、结果读取说明

1.read : io=10240MB, bw=63317KB/s, iops=15829, runt=165607msec

第一行很容易读懂。fio做了10GB的IO，速率63.317MB/s，总IOPS 15829 (默认4k block size)，运行了2分钟45秒。

你看到的第一个延迟(Latency)数据是slat，或称为submission latency。这个值和他的名字很相像，代表“盘需要多久将IO提交到kernel做处理?”。

 

slat (usec): min=3, max=335, avg= 9.73, stdev= 5.76

我起初认为submission latency对于性能调试没有用，但是下面的数据让我改变了观点。269usec或1/4 ms看起来是噪音(noise)，需要关注一下。我还没有做任何调试，所以我猜测改变scheduler以告诉kernel这不是机械硬盘会有效果。

以下是从其他盘上得到的更多例子。

slat (usec): min=3, max=335, avg= 9.73, stdev= 5.76 (SATA SSD) slat (usec): min=5, max=68, avg=26.21, stdev= 5.97 (SAS 7200) slat (usec): min=5, max=63, avg=25.86, stdev= 6.12 (SATA 7200) slat (usec): min=3, max=269, avg= 9.78, stdev= 2.85 (SATA SSD) slat (usec): min=6, max=66, avg=27.74, stdev= 6.12 (MDRAID0/SAS) clat (usec): min=1, max=18600, avg=51.29, stdev=16.79

接下来是completion latency。这是命令提交到kernel到IO做完之间的时间，不包括submission latency。在老版本的fio中，这是估计应用级延迟的最好指标。

 

lat (usec): min=44, max=18627, avg=61.33, stdev=17.91

在我看来，'lat'是一个新的指标，在man或者文档中都没有描述。分析C代码，似乎这个值是从IO结构体创建时刻开始，直到紧接着clat完成，这个算法最好地表现出了应用程序的行为。

 

1. clat percentiles (usec):
2. | 1.00th=[ 42], 5.00th=[ 45], 10.00th=[ 45], 20.00th=[ 46],
3. | 30.00th=[ 47], 40.00th=[ 47], 50.00th=[ 49], 60.00th=[ 51],
4. | 70.00th=[ 53], 80.00th=[ 56], 90.00th=[ 60], 95.00th=[ 67],
5. | 99.00th=[ 78], 99.50th=[ 81], 99.90th=[ 94], 99.95th=[ 101],
6. | 99.99th=[ 112]

Completion latency百分数的解释一目了然，可能是输出信息中最有用的部分。我看了代码，这不是slat+clat，而是用了单独的结构体记录。

这个列表可以在config文件中配置。在精简输出模式下有20个这样的格式，%f=%d; %f=%d;... 解析这样的输出格式会很有趣。

 

作为比较，这里列出一个7200RPM SAS硬盘运行完全相同的负载的统一部分数据。

Seagate 7200RPM SAS 512G ST9500430SS

clat percentiles (usec): | 1.00th=[ 3952], 5.00th=[ 5792], 10.00th=[ 7200], 20.00th=[ 8896], | 30.00th=[10304], 40.00th=[11456], 50.00th=[12608], 60.00th=[13760], | 70.00th=[15168], 80.00th=[16768], 90.00th=[18816], 95.00th=[20608], | 99.00th=[23424], 99.50th=[24192], 99.90th=[26752], 99.95th=[28032], | 99.99th=[30080] bw (KB /s): min=52536, max=75504, per=67.14%, avg=63316.81, stdev=4057.09

带宽(bandwidth)的意思显而易见，而per=part就不是很好理解。文档上说这个值是指在单个盘上跑多个负载，可以用来看每个进程消耗了多少IO。对于我这样把fio跑在多个盘的情况，这个值意义不大。但由于SSD和机械硬盘混合使用，这个值挺有趣。

下面是另一个SAS硬盘，占测试的所有4个盘总IO的0.36%。

bw (KB /s): min= 71, max= 251, per=0.36%, avg=154.84, stdev=18.29 lat (usec) : 2= 0.01%, 4=0.01%, 10=0.01%, 20=0.01%, 50=51.41% lat (usec) : 100=48.53%, 250=0.06%, 500=0.01%, 1000=0.01% lat (msec) : 2= 0.01%, 4=0.01%, 10=0.01%, 20=0.01%

 

latency分布部分我看了几遍才理解。这是一组数据。与三行使用一样的单位不同，第三行使用了毫秒(ms)，使得文本宽度可控。把第三行读成2000, 4000, 10000, 20000微秒(us)就更清晰了。

这组数据表示latency的分布，说明了51.41%的request延迟小于50微秒，48.53%的延迟小于100微秒(但是大于50微秒)，以此类推。

 

lat (msec) : 4=1.07%, 10=27.04%, 20=65.43%, 50=6.46%, 100=0.01%

如果想用快速脚本解析这些繁琐的数据，你可能需要知道，最后一部分会省略那些没有数据的项。例如，我使用的SAS盘没有IO可以在1毫秒中完成，所以只有一行。 

 

cpu : usr=5.32%, sys=21.95%, ctx=2829095, majf=0, minf=21

这是用户/系统CPU占用率，进程上下文切换(context switch)次数，主要和次要(major and minor)页面错误数量(page faults)。由于测试是配置成使用直接IO，page faults数量应该极少。 

 

IO depths : 1=100.0%, 2=0.0%, 4=0.0%, 8=0.0%, 16=0.0%, 32=0.0%, >=64=0.0%

Fio有一个iodepth设置，用来控制同一时刻发送给OS多少个IO。这完全是纯应用层面的行为，和盘的IO queue不是一回事。这里iodepth设成1，所以IO depth在全部时间都是1。

 

submit : 0=0.0%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.0%, 64=0.0%, >=64=0.0% complete : 0=0.0%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.0%, 64=0.0%, >=64=0.0%

submit和complete代表同一时间段内fio发送上去和已完成的IO数量。对于产生这个输出的垃圾回收测试用例来说，iodepth是默认值1，所以100%的IO在同一时刻发送1次，放在1-4栏位里。通常来说，只有iodepth大于1才需要关注这一部分数据。

我会找时间测试多种调度策略，这些数据会变得更有趣。

 

issued : total=r=2621440/w=0/d=0, short=r=0/w=0/d=0

发送的IO数量。这里出现了奇怪的现象，因为这是50/50的读写负载，照道理应该有相同数量的write。我猜测把unified_rw_reporting打开是的fio把所有的IO都认为是read。

如果你在直接IO测试是看到了IO值很低，那么可能是出问题了。我在Linux kernel中找到参考说这种现象发生在文件末尾EOL或可能是设备的尾端。

 

latency : target=0, window=0, percentile=100.00%, depth=1

Fio可以配置一个延迟目标值，这个值可以调节吞吐量直到达到预设的延迟目标。我还没有太多深入了解这部分。在基于时间或和容量的测试中，这行通常看起来一样。四个值分别代表预设的latency_target, latency_window, latency_percentile和iodepth。 

 

Run status group 0 (all jobs):

Fio支持把不同的测试聚合。例如，我可以用一个配置文件混合包含SSD和HDD，但是设置分组(group)把IO单独汇总。我现在还没涉及这个功能，但未来会用到。 

 

MIXED: io=12497MB, aggrb=42653KB/s, minb=277KB/s, maxb=41711KB/s, mint=300000msec, maxt=300012msec

 

最后，汇总输出吞吐量和时间。io=表示总共完成的IO数量。在基于时间的测试中这是一个变量，在基于容量的测试中，这个值能匹配size参数。aggrb是所有进程/设备的汇总带宽。minb/maxb表示测量到的最小/最大带宽。mint/maxt表示测试的最短和最长耗时。和io=参数类似，时间值对于基于时间的测试应该能匹配runtime参数，对于基于容量的测试是一个变量。

 

由于我设置了unified_rw_reporting参数运行测试，所以只看到MIXED一行。如果禁用这个参数，对于读和写会有单独的行。

够简单吧？我未来的几周会花更多的时间研究fio，我会发布更多关于配置，输出和图表代码的例子。