使用 fio 进行 IO 性能测试

网上关于 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 的理解就更加深刻,同时也能让我们更好的根据硬件资源来调优系统。

©著作权归作者所有,转载或内容合作请联系作者
  • 序言:七十年代末,一起剥皮案震惊了整个滨河市,随后出现的几起案子,更是在滨河造成了极大的恐慌,老刑警刘岩,带你破解...
    沈念sama阅读 160,108评论 4 364
  • 序言:滨河连续发生了三起死亡事件,死亡现场离奇诡异,居然都是意外死亡,警方通过查阅死者的电脑和手机,发现死者居然都...
    沈念sama阅读 67,699评论 1 296
  • 文/潘晓璐 我一进店门,熙熙楼的掌柜王于贵愁眉苦脸地迎上来,“玉大人,你说我怎么就摊上这事。” “怎么了?”我有些...
    开封第一讲书人阅读 109,812评论 0 244
  • 文/不坏的土叔 我叫张陵,是天一观的道长。 经常有香客问我,道长,这世上最难降的妖魔是什么? 我笑而不...
    开封第一讲书人阅读 44,236评论 0 213
  • 正文 为了忘掉前任,我火速办了婚礼,结果婚礼上,老公的妹妹穿的比我还像新娘。我一直安慰自己,他们只是感情好,可当我...
    茶点故事阅读 52,583评论 3 288
  • 文/花漫 我一把揭开白布。 她就那样静静地躺着,像睡着了一般。 火红的嫁衣衬着肌肤如雪。 梳的纹丝不乱的头发上,一...
    开封第一讲书人阅读 40,739评论 1 222
  • 那天,我揣着相机与录音,去河边找鬼。 笑死,一个胖子当着我的面吹牛,可吹牛的内容都是我干的。 我是一名探鬼主播,决...
    沈念sama阅读 31,957评论 2 315
  • 文/苍兰香墨 我猛地睁开眼,长吁一口气:“原来是场噩梦啊……” “哼!你这毒妇竟也来了?” 一声冷哼从身侧响起,我...
    开封第一讲书人阅读 30,704评论 0 204
  • 序言:老挝万荣一对情侣失踪,失踪者是张志新(化名)和其女友刘颖,没想到半个月后,有当地人在树林里发现了一具尸体,经...
    沈念sama阅读 34,447评论 1 246
  • 正文 独居荒郊野岭守林人离奇死亡,尸身上长有42处带血的脓包…… 初始之章·张勋 以下内容为张勋视角 年9月15日...
    茶点故事阅读 30,643评论 2 249
  • 正文 我和宋清朗相恋三年,在试婚纱的时候发现自己被绿了。 大学时的朋友给我发了我未婚夫和他白月光在一起吃饭的照片。...
    茶点故事阅读 32,133评论 1 261
  • 序言:一个原本活蹦乱跳的男人离奇死亡,死状恐怖,灵堂内的尸体忽然破棺而出,到底是诈尸还是另有隐情,我是刑警宁泽,带...
    沈念sama阅读 28,486评论 3 256
  • 正文 年R本政府宣布,位于F岛的核电站,受9级特大地震影响,放射性物质发生泄漏。R本人自食恶果不足惜,却给世界环境...
    茶点故事阅读 33,151评论 3 238
  • 文/蒙蒙 一、第九天 我趴在偏房一处隐蔽的房顶上张望。 院中可真热闹,春花似锦、人声如沸。这庄子的主人今日做“春日...
    开封第一讲书人阅读 26,108评论 0 8
  • 文/苍兰香墨 我抬头看了看天上的太阳。三九已至,却和暖如春,着一层夹袄步出监牢的瞬间,已是汗流浃背。 一阵脚步声响...
    开封第一讲书人阅读 26,889评论 0 197
  • 我被黑心中介骗来泰国打工, 没想到刚下飞机就差点儿被人妖公主榨干…… 1. 我叫王不留,地道东北人。 一个月前我还...
    沈念sama阅读 35,782评论 2 277
  • 正文 我出身青楼,却偏偏与公主长得像,于是被迫代替她去往敌国和亲。 传闻我的和亲对象是个残疾皇子,可洞房花烛夜当晚...
    茶点故事阅读 35,681评论 2 272

推荐阅读更多精彩内容

  • FIO是测试IOPS的非常好的工具,用来对硬件进行压力测试和验证,支持19种不同的I/O引擎,包括:sync, m...
    聂扬帆博客阅读 13,374评论 0 4
  • feisky云计算、虚拟化与Linux技术笔记posts - 1014, comments - 298, trac...
    不排版阅读 3,754评论 0 5
  • Spring Cloud为开发人员提供了快速构建分布式系统中一些常见模式的工具(例如配置管理,服务发现,断路器,智...
    卡卡罗2017阅读 134,103评论 18 139
  • 这是我第二次来宜兴了,这座江南园林城市非常美,一路上到处是郁郁葱葱的,虽然是个县级市,可城市规划超前,非常与国际接...
    阿涛呀阅读 258评论 1 4
  • 1. 老板让我设计新项目的名片,大致说了几个点,我用了2分钟在A4纸上画出草图发给她了。过了一段时间,她说:你这次...
    杨小米阅读 2,781评论 2 13