Linux FIO

FIO是测试IOPS的非常好的工具，用来对硬件进行压力测试和验证，支持13种不同的I/O引擎，包括:sync,mmap, libaio, posixaio, SG v3, splice, null, network, syslet,guasi, solarisaio 等等。
fio 官网地址：http://freecode.com/projects/fio

FIO用法：

随机读：

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

说明：

filename=/dev/sdb1       测试文件名称，通常选择需要测试的盘的data目录。

direct=1                     测试过程绕过机器自带的buffer。使测试结果更真实。

rw=randwrite             测试随机写的I/O

rw=randread             测试顺序读的I/O

rw=randrw                测试随机写和读的I/O

rw=write                   测试顺序写的I/O

rw=read                    测试顺序读的I/O

bs=16k                   单次io的块文件大小为16k

bsrange=512-2048         同上，提定数据块的大小范围

size=5g   本次的测试文件大小为5g，以每次4k的io进行测试。

numjobs=30               本次的测试线程为30.

runtime=1000             测试时间为1000秒，如果不写则一直将5g文件分4k每次写完为止。

ioengine=psync           io引擎使用pync方式

rwmixwrite=30            在混合读写的模式下，写占30%

group_reporting          关于显示结果的，汇总每个进程的信息。

这个工具最大的特点是使用简单，支持的文件操作非常多, 可以覆盖到我们能见到的文件使用方式:
sync：Basic read(2) or write(2) I/O. fseek(2) is used to position the I/O location.
psync：Basic pread(2) or pwrite(2) I/O.
vsync: Basic readv(2) or writev(2) I/O. Will emulate queuing by coalescing adjacents iOS into a single submission.
libaio: Linux native asynchronous I/O.
posixaio: glibc POSIX asynchronous I/O using aio_read(3) and aio_write(3).
mmap: File is memory mapped with mmap(2) and data copied using memcpy(3).
splice： splice(2) is used to transfer the data and vmsplice(2) to transfer data from user-space to the kernel.
syslet-rw： Use the syslet system calls to make regular read/write asynchronous.
sg：SCSI generic sg v3 I/O.
net ： Transfer over the network. filename must be set appropriately to `host/port’ regardless of data direction. If receiving,
only the port argument is used.
netsplice： Like net, but uses splice(2) and vmsplice(2) to map data and send/receive.
guasi The GUASI I/O engine is the Generic Userspace Asynchronous Syscall Interface approach to asycnronous I/O.

此外

lockmem=1g               只使用1g内存进行测试。

zero_buffers             用0初始化系统buffer。

nrfiles=8                每个进程生成文件的数量。

顺序读：

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

随机写：

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

顺序写：

fio -filename=/dev/sdb1 -direct=1 -iodepth=1 -thread -rw=write -ioengine=psync -bs=16k -size=200G -numjobs=30-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=30 -runtime=100 -group_reporting -name=mytest -ioscheduler=noop

FIO输出内容的内容解释

翻译原文来源

https://tobert.github.io/post/2014-04-17-fio-output-explained.html

fio，又称为Flexible IO Tester，是Jens Axboe编写的应用程序。Jens是linux Kernel中block IO subsystem的维护者。fio从多个方面来看类似于更古老的ffsb工具，但他们之间似乎没有任何关系。作为一个强大的工具，fio可以产生足够多的任意类型的负载 (arbitrary load)。作为权衡，fio不容易学习，这就是这篇文章的目的。

• config
• raw output

config

以下是一个50/50读写的垃圾处理IO (Trashing IO)负载，对于多个盘进行的读写。

5分钟，磁盘垃圾处理测试，50/50读写在每个盘上产生相同数量的随机读和写IO，为每个盘产生测试数据。

raw output

以上链接可打开上述fio配置的原始输出。

接下来按照每个部分分析输出内容。这里显示的数据是Samsung 840 Pro SSD，其他盘的数据稍后再深入研究。

对于每一个部分的描述在输出文字下面。

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

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

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

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

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

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

clat percentiles (usec):
     |  .00th=[   ],  .00th=[   ], .00th=[   ], .00th=[   ],
     | .00th=[   ], .00th=[   ], .00th=[   ], .00th=[   ],
     | .00th=[   ], .00th=[   ], .00th=[   ], .00th=[   ],
     | .00th=[   ], .50th=[   ], .90th=[   ], .95th=[  ],
     | .99th=[  ]  

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

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

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

Seagate 7200RPM SAS 512G ST9500430SS

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

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

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

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

IO depths    : =100.0%, =0.0%, =0.0%, =0.0%, =0.0%, =0.0%, >==0.0%  

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

submit    : =0.0%, =100.0%, =0.0%, =0.0%, =0.0%, =0.0%, >==0.0%
complete  : =0.0%, =100.0%, =0.0%, =0.0%, =0.0%, =0.0%, >==0.0%  

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

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

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

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

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

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

Run status group  (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，我会发布更多关于配置，输出和图表代码的例子。