使用 fio 进行 IO 性能测试

发表于:2018-5-04 11:41

字体: | 上一篇 | 下一篇 | 我要投稿

 作者: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,我们需要根据业务的实际情况选择不同的类型,主要几个:
  ●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 的理解就更加深刻,同时也能让我们更好的根据硬件资源来调优系统。




上文内容不用于商业目的,如涉及知识产权问题,请权利人联系博为峰小编(021-64471599-8017),我们将立即处理。
《2023软件测试行业现状调查报告》独家发布~

关注51Testing

联系我们

快捷面板 站点地图 联系我们 广告服务 关于我们 站长统计 发展历程

法律顾问:上海兰迪律师事务所 项棋律师
版权所有 上海博为峰软件技术股份有限公司 Copyright©51testing.com 2003-2024
投诉及意见反馈:webmaster@51testing.com; 业务联系:service@51testing.com 021-64471599-8017

沪ICP备05003035号

沪公网安备 31010102002173号