使用 fio 进行 IO 性能测试

2018-04-22  本文已影响1939人  siddontang

网上关于 fio 的介绍已经太多了，要用的时候都是直接拿来就跑了，我们通常使用 fio -ioengine=libaio -bs=4k -direct=1 -thread -rw=write -size=10G -filename=test -name="Max throughput" -iodepth=4 -runtime=60 这些
来测试，但最近在一些用户那边，发现使用 fio 测试，用户的盘非常的好，能达到几百 MB 的吞吐，但我们才跑到 100 MB，iostat 里面的 IO Util 就 100% 了。虽然清楚 IO Util 100% 并不是意味着盘吃死了，但从另一个方面，也让我突然意识到，我们应该更加多维度的对盘进行性能测试，也就重新回顾了下 fio。

参数

Fio 的使用真的是非常简单，我们主要关注几个重要的参数类别就可以了。

首先就是 I/O engine，这个就是告诉 fio 使用什么样的方式去测试 I/O，我们需要根据业务的实际情况选择不同的类型，主要几个：

其他的当然还有很多种，但实际我们这边没用到，没准以后会用。因为我们使用的是 RocksDB，所以为了更好的测试应用程序对盘的影响，我们应该使用 sync，vsync 那边的 engine 进行操作。

在要注意的就是 I/O type，譬如是否使用 direct，还是 buffered，如果是 buffered，我们多少次 I/O 之后使用 fsync 或者 fdatasync 来进行强制 sync 操作。我们还需要选择合适的 I/O pattern 来进行测试，这个主要是 readwrite 来确定，包括：

如果我们使用混合模式，我们还可以设置读写的比例，通常是读写各半，但实际很多场景应该是读多写少，我们可以使用 rwmixread = 90 来设置 90% 的读，10 % 的写，我们也可以通过 rwmixwrite = 90 来设置，这两个参数其实有点冲突，如果加起来没到 100，那么 fio 会用后面的一个。

对于随机读写来说，另一个需要考虑的指标就是操作分布，我们使用 random_distribution 来设置，主要包括 random, zipf, normal 等，默认是 random。

另外还需要注意的就是 block size，也就是一次 I/O 操作的大小，通常我们都是读写使用相同的 block，譬如 bs=4k，但实际还会不一样，我们可以用 bs=4k,16k 来设置读是 4k，但写是 16k。

对于 libaio engine 来说，还需要考虑设置 iodepth，对于 sync 等来说，还需要设置 jobnum，来让 fio 用多个线程并发的对盘进行测试。测试多了，就会很悲催的发现，libaio 很容易就把盘给打死，但 sync 这些还需要启动几个线程。。。

结果分析

当 fio 跑完之后，会生成相应的结果，譬如执行 fio -ioengine=psync -filename=iotest -bs=8k -fdatasync=1 -rw=write -size=10g -runtime=60 -name="pingcap" 会输出：

pingcap: (g=0): rw=write, bs=(R) 8192B-8192B, (W) 8192B-8192B, (T) 8192B-8192B, ioengine=psync, iodepth=1
fio-3.1
Starting 1 process
Jobs: 1 (f=1): [W(1)][100.0%][r=0KiB/s,w=296MiB/s][r=0,w=37.8k IOPS][eta 00m:00s]
pingcap: (groupid=0, jobs=1): err= 0: pid=39086: Thu Apr 12 16:49:02 2018
  write: IOPS=37.0k, BW=297MiB/s (311MB/s)(10.0GiB/34510msec)
    clat (usec): min=3, max=159, avg= 5.28, stdev= 1.58
     lat (usec): min=3, max=159, avg= 5.40, stdev= 1.59
    clat percentiles (nsec):
     |  1.00th=[ 4048],  5.00th=[ 4192], 10.00th=[ 4256], 20.00th=[ 4384],
     | 30.00th=[ 4448], 40.00th=[ 4512], 50.00th=[ 4768], 60.00th=[ 5344],
     | 70.00th=[ 5472], 80.00th=[ 5664], 90.00th=[ 6176], 95.00th=[ 8512],
     | 99.00th=[10688], 99.50th=[11328], 99.90th=[21632], 99.95th=[22912],
     | 99.99th=[27520]
   bw (  KiB/s): min=291856, max=348720, per=100.00%, avg=317689.68, stdev=14463.28, samples=66
   iops        : min=36482, max=43590, avg=39711.20, stdev=1807.88, samples=66
  lat (usec)   : 4=0.37%, 10=96.95%, 20=2.51%, 50=0.17%, 100=0.01%
  lat (usec)   : 250=0.01%
  cpu          : usr=8.55%, sys=43.65%, ctx=1310832, majf=0, minf=149
  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 rwt: total=0,1310720,0, short=0,0,0, dropped=0,0,0
     latency   : target=0, window=0, percentile=100.00%, depth=1

Run status group 0 (all jobs):
  WRITE: bw=297MiB/s (311MB/s), 297MiB/s-297MiB/s (311MB/s-311MB/s), io=10.0GiB (10.7GB), run=34510-34510msec

Disk stats (read/write):
  nvme0n1: ios=0/1306428, merge=0/22, ticks=0/18431, in_queue=17280, util=50.11%

可以看到，在一个非常强悍的 Optane 盘上面，使用 sync engine，每次都 sync 写盘，性能还是很差的，吞吐不到 300 MB，其他的盘可能就更差了。我们主要关注几个指标：

slat / clat / lat：这几个是 latency 指标，slat 就是 Submission latency，也就是提交到实际执行 I/O 的时间，在 sync 测试里面这个是没有的，因为 slat 就是 clat。clat 就是 Completion latency，也就是从提交到完成的时间。lat 就是 Total latency，包括 fio 从创建这个 I/O 单元到完成的总的时间。

另外需要关注的指标就是 BW，和 IOPS，这两这个很直观了，就不解释了。最下面是 ios，也就是总的 I/O 操作次数，merge 就是被 I/O 调度合并的次数，ticks 就是让磁盘保持忙碌的次数，in_queue 就是总的在磁盘队列里面的耗时，而 util 则是磁盘的利用率。

其他

除了在控制台输出最后的汇总信息，fio 还支持将中间的操作输出到文件，然后使用工具绘制图表展示，通常就是设置 write_bw_log，write_bw_log 和 write_iops_log，然后使用 fio_generate_plots 来绘图，另外也可以用 fio2gnuplot 来绘制，网上有太多的教程，这里就不说了。

另外，fio 还可以对 blktrace 生成的文件进行回放，然后让我们去定位实际系统的 I/O 问题，这个以后可以好好研究一下。

总的来说，fio 是非常强大的一款工具，用好了，个人对 I/O 的理解就更加深刻，同时也能让我们更好的根据硬件资源来调优系统。

上一篇下一篇

猜你喜欢

热点阅读