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，为每个盘产生测试数据。
# a 5 minute disk thrashing benchmark
# generates equal amounts of random read and write IO on every drive
# will generate metrics for each drive
[global]
ioengine=libaio
direct=1
unified_rw_reporting=1
rw=randrw
time_based=1
runtime=300s
# Seagate 7200RPM SAS 512G ST9500430SS (sdb)
[/dev/disk/by-path/pci-0000:03:00.0-sas-0x5000c5000d7f96d9-lun-0]
write_lat_log=7200RPMSAS-0x5000c5000d7f96d9
# Seagate 7200RPM Enterprise SATA 1TB ST31000340NS (sdg)
[/dev/disk/by-id/wwn-0x5000c500151229dd]
write_lat_log=7200RPMEnterpriseSATA-0x5000c500151229dd
# Samsung 840 Pro 128GB (on a 3G SATA port) (sdd)
[/dev/disk/by-id/ata-Samsung_SSD_840_PRO_Series_S1ANNSADB05219A]
write_lat_log=SSDSATA-S1ANNSADB05219A
# 2x SAS drives with GPT partition & MDRAID0 (sdi1 + sdc1)
# Seagate 7200RPM SAS 512G ST9500430SS
[/dev/disk/by-id/md-uuid-6bb71ed6:e4410fc9:b27af0b7:0afe758d]
write_lat_log=7200RPMSAS-MDRAID0raw output
以上链接可打开上述fio配置的原始输出。
接下来按照每个部分分析输出内容。这里显示的数据是Samsung 840 Pro SSD，其他盘的数据稍后再深入研究。
对于每一个部分的描述在输出文字下面。
read : io=10240MB, bw=63317KB/s, iops=15829, runt=165607msec你看到的第一个延迟(Latency)数据是slat，或称为submission latency。这个值和他的名字很相像，代表“盘需要多久将IO提交到kernel做处理?”。
slat (usec): min=3, max=335, avg= 9.73, stdev= 5.76以下是从其他盘上得到的更多例子。
slat (usec): min=3, max=335, avg= 9.73, stdev= 5.76 (SATA SSD)
slat (usec): min=5, max=68, avg=26.21, stdev= 5.97 (SAS 7200)
slat (usec): min=5, max=63, avg=25.86, stdev= 6.12 (SATA 7200)
slat (usec): min=3, max=269, avg= 9.78, stdev= 2.85 (SATA SSD)
slat (usec): min=6, max=66, avg=27.74, stdev= 6.12 (MDRAID0/SAS)
clat (usec): min=1, max=18600, avg=51.29, stdev=16.79接下来是completion latency。这是命令提交到kernel到IO做完之间的时间，不包括submission latency。在老版本的fio中，这是估计应用级延迟的最好指标。
lat (usec): min=44, max=18627, avg=61.33, stdev=17.91
在我看来，'lat'是一个新的指标，在man或者文档中都没有描述。分析C代码，似乎这个值是从IO结构体创建时刻开始，直到紧接着clat完成，这个算法最好地表现出了应用程序的行为。
clat percentiles (usec):
| 1.00th=[ 42], 5.00th=[ 45], 10.00th=[ 45], 20.00th=[ 46],
| 30.00th=[ 47], 40.00th=[ 47], 50.00th=[ 49], 60.00th=[ 51],
| 70.00th=[ 53], 80.00th=[ 56], 90.00th=[ 60], 95.00th=[ 67],
| 99.00th=[ 78], 99.50th=[ 81], 99.90th=[ 94], 99.95th=[ 101],
| 99.99th=[ 112]Completion latency百分数的解释一目了然，可能是输出信息中最有用的部分。我看了代码，这不是slat+clat，而是用了单独的结构体记录。
这个列表可以在config文件中配置。在精简输出模式下有20个这样的格式，%f=%d; %f=%d;... 解析这样的输出格式会很有趣。
作为比较，这里列出一个7200RPM SAS硬盘运行完全相同的负载的统一部分数据。
Seagate 7200RPM SAS 512G ST9500430SS
clat percentiles (usec):
| 1.00th=[ 3952], 5.00th=[ 5792], 10.00th=[ 7200], 20.00th=[ 8896],
| 30.00th=[10304], 40.00th=[11456], 50.00th=[12608], 60.00th=[13760],
| 70.00th=[15168], 80.00th=[16768], 90.00th=[18816], 95.00th=[20608],
| 99.00th=[23424], 99.50th=[24192], 99.90th=[26752], 99.95th=[28032],
| 99.99th=[30080]
bw (KB /s): min=52536, max=75504, per=67.14%, avg=63316.81, stdev=4057.09带宽(bandwidth)的意思显而易见，而per=part就不是很好理解。文档上说这个值是指在单个盘上跑多个负载，可以用来看每个进程消耗了多少IO。对于我这样把fio跑在多个盘的情况，这个值意义不大。但由于SSD和机械硬盘混合使用，这个值挺有趣。
下面是另一个SAS硬盘，占测试的所有4个盘总IO的0.36%。
bw (KB /s): min= 71, max= 251, per=0.36%, avg=154.84, stdev=18.29
lat (usec) : 2= 0.01%, 4=0.01%, 10=0.01%, 20=0.01%, 50=51.41%
lat (usec) : 100=48.53%, 250=0.06%, 500=0.01%, 1000=0.01%
lat (msec) : 2= 0.01%, 4=0.01%, 10=0.01%, 20=0.01%latency分布部分我看了几遍才理解。这是一组数据。与三行使用一样的单位不同，第三行使用了毫秒(ms)，使得文本宽度可控。把第三行读成2000, 4000, 10000, 20000微秒(us)就更清晰了。
这组数据表示latency的分布，说明了51.41%的request延迟小于50微秒，48.53%的延迟小于100微秒(但是大于50微秒)，以此类推。
lat (msec) : 4=1.07%, 10=27.04%, 20=65.43%, 50=6.46%, 100=0.01%cpu : usr=5.32%, sys=21.95%, ctx=2829095, majf=0, minf=21IO 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%submit和complete代表同一时间段内fio发送上去和已完成的IO数量。对于产生这个输出的垃圾回收测试用例来说，iodepth是默认值1，所以100%的IO在同一时刻发送1次，放在1-4栏位里。通常来说，只有iodepth大于1才需要关注这一部分数据。
我会找时间测试多种调度策略，这些数据会变得更有趣。
issued : total=r=2621440/w=0/d=0, short=r=0/w=0/d=0如果你在直接IO测试是看到了IO值很低，那么可能是出问题了。我在Linux kernel中找到参考说这种现象发生在文件末尾EOL或可能是设备的尾端。
latency : target=0, window=0, percentile=100.00%, depth=1Run status group 0 (all jobs):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，我会发布更多关于配置，输出和图表代码的例子。