美文网首页
使用 fio 进行 IO 性能测试

使用 fio 进行 IO 性能测试

作者: siddontang | 来源:发表于2018-04-22 02:05 被阅读1939次

    网上关于 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,我们需要根据业务的实际情况选择不同的类型,主要几个:

    • libaio - Linux 原生的异步 I/O,这也是通常我们这边用的最多的测试盘吞吐和延迟的方法
    • sync - 也就是最通常的 read / write 操作
    • vsync - 使用 readv / writev,主要是会将相邻的 I/O 进行合并
    • psync - 对应的 pread / pwrite
    • pvsync / pvsync2 - 对应的 preadv / pwritev,以及 preadv2 / p writev2

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

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

    • read - 顺序读
    • write - 顺序写
    • trim - 顺序裁剪
    • randread - 随机读
    • randwrite - 随机写
    • randtrim - 随机裁剪
    • rw, readwrite - 混合顺序读写
    • randrw - 混合的随机读写
    • trimwrite - 顺序的裁剪 + 顺序写

    如果我们使用混合模式,我们还可以设置读写的比例,通常是读写各半,但实际很多场景应该是读多写少,我们可以使用 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 的理解就更加深刻,同时也能让我们更好的根据硬件资源来调优系统。

    相关文章

      网友评论

          本文标题:使用 fio 进行 IO 性能测试

          本文链接:https://www.haomeiwen.com/subject/bukqlftx.html