fio常见使用方法
- fio简介
fio是一个性能测试工具，可以针对文件系统或者裸盘进行性能测试。本教程以裸盘进行说明。
- fio的安装
对于centos系统，执行执行yum install fio即可，其它系统请自行查找资料安装。
fio测试不同设备的方法：
测试iscsi：使用iscsi将lun挂载给客户端，然后客户端使用fio对多路径设备/dev/mapper/mpathX进行读写测试即为iscsi性能测试：
fio --ioengine=libaio -filename=/dev/mapper/mpatha
测试krbd：在存储管理界面将lun映射给本地客户端，然后对/dev/rbdX进行读写即为krbd性能测试
fio --ioengine=libaio -filename=/dev/rbd0
测试librbd（对fio有版本要求，2.X有部分不支持）：需要先在客户端安装rbd-client，安装完rbd-client之后，需要将存储节点/var/lib/ceph/etc/ceph/XXXXX.conf 文件scp到客户端节点的相同目录下，在客户端节点与存储public网络连接之后即可使用librbd进行测试：
fio --ioengine=rbd -rbdname=120845d0-438b-11eb-81fc-246e9609b932 -pool=4eb9c4b0-433e-11eb-b68a-246e9609b932 -clientname=admin
- fio的使用
读写注意事项：没有写过的数据的盘做读操作之前需要进行写一遍的操作，否则会存在读空数据的情况，估计读到bitmap就返回数据了，性能会超级高，不能代表存储实际性能。特殊场景需要构造磁盘存在空穴的情况，也可以使用fio进行进行构造。
首先，我们来把磁盘写一遍
fio --ioengine=libaio -filename=/dev/mapper/mpatha -direct=1 -rw=rw -bs=1024k -rwmixread=0 -iodepth=128 -numjobs=1 -group_reporting -name=test
ioengine fio3.7版本中就支持25种不同的引擎模式，其中常用的为libaio（linux原生异步io，我们的测试也基本上是在这个模型下测试的）；rbd即使用librbd方式来执行读写（相比iscsi方式访问压力会更稳定）。默认的ioengine为sync，即一个io写下去了之后会确认完成读写才会执行下一个io。还有一个是psync，比sync又多了个原子操作的概念。
Filename即你要测试裸磁盘或者文件系统里的文件
Direct 通常和libaio一起使用，=1即不使用缓存
Rw定义读写模型，有9个定义，常用的有read write randread randwrite rw(readwrite) randrw
Rwmixread/rwmixwrite 读写模型种读和写的比例，默认为50，只定义一个即可。配合rw定义的rw模型使用
Bs 单个io读写的块大小
Iodepth 读写的队列深度，类似于一个车道上排队的车辆数
Numjobs 读写的job个数，类似于有几个车道
Group_reporting -name=两个一起用，通常用来区分不同的fio任务
这个命令就会把指定的盘用1m的块大小顺序写一遍。为啥要用这种方式写呢，我们想快速的把盘写一遍肯定是大块比小块速度要块，所以我们用的是1024k。然后iodepth为啥设置的128呢，iodepth设置小了，喂不饱磁盘的处理能力，太大了磁盘也只能慢慢处理，io响应的时间就比较长。Numjobs设置的为1，就是只有一个进程去执行这个写的操作，要是设置成4个numjob的话它会把磁盘写四次（同时写，非写一遍再写第二遍）
接下来我们测试一下4k的7读3写的随机混合读写：
先想想我们想观察啥：1、假设我一个6T的卷4k读写要到猴年马月才能执行完啊？所以我们加了个-runtime=1800 -time_based两个参数，让它只跑1800秒；当然你也可以指定-size=10G，限定只在10G的大小空间里进行读写，执行完就停止；要是把两个参数都写上了会是啥样呢，fio就会在限定的空间里多次进行读写，直到到达runtime限制。2、我一个6T的卷，有ssd缓存呢，缓存内性能和缓存外性能肯定不一样，我要记录一下每秒的性能数据？也有办法，-write_iops_log=/dir/prefix -ite_bw_log=/dir/prefix -write_lat_log=/dir/prefix -log_avg_msec=5000,这样就会在dir目录下生成prefix开头_iops.x.log _bw.x.log _lat.x.log结尾的log文件，每个文件里按照5000ms统计一次数据。
fio --ioengine=libaio -filename=/dev/mapper/mpatha -direct=1 -rw=randrw -bs=4k -rwmixread=70 -iodepth=128 -numjobs=4 -group_reporting -name=4K_randrw_test -runtime=60 -time_based -write_iops_log=./randwrite_4k_0_128_8 -write_bw_log=./log/randwrite_4k_0_128_8 -write_lat_log=./randwrite_4k_0_128_8 -log_avg_msec=5000 -offset_increment=2m
这个模型就会用4k的块大小执行7读3写的操作。同时每5s记录一次性能数据。最后一个offset_increment=2m指的是每个job开始的偏移量，实测对randrw影响不大，对顺序读写建议加上改选项防止多个job同时访问一个对象，存在读写合并的情况。
- fio结果说明
fio执行完成之后会生成下面这个类似的结果，我们找一个rw模型的来看看，主要关注的数据标黄：
test: (g=0): rw=randrw, bs=(R) 8192B-8192B, (W) 8192B-8192B, (T) 8192B-8192B, ioengine=rbd, iodepth=64
fio-3.7
Starting 4 processes
test: (groupid=0, jobs=4): err= 0: pid=47275: Tue Feb 23 20:31:47 2021
read: IOPS=14.6k, BW=114MiB/s (119MB/s)(200GiB/1800007msec)
#表示这个是读的数据，平均iops是14.6k，平均带宽114MiB
slat (nsec): min=761, max=2532.7k, avg=4352.02, stdev=2719.80
clat (usec): min=259, max=196339, avg=2885.07, stdev=2217.53
lat (usec): min=263, max=196349, avg=2889.42, stdev=2217.56
#平均时延2889.42usec
clat percentiles (usec):
| 1.00th=[ 734], 5.00th=[ 1270], 10.00th=[ 1582], 20.00th=[ 1958],
| 30.00th=[ 2245], 40.00th=[ 2474], 50.00th=[ 2704], 60.00th=[ 2966],
| 70.00th=[ 3228], 80.00th=[ 3556], 90.00th=[ 4178], 95.00th=[ 4817],
| 99.00th=[ 6325], 99.50th=[ 7111], 99.90th=[27395], 99.95th=[56886],
| 99.99th=[85459]
bw ( KiB/s): min=20075, max=33998, per=25.00%, avg=29104.45, stdev=2078.91, samples=1439
iops : min= 2509, max= 4249, avg=3637.69, stdev=259.86, samples=1439
#前面那个iops是这个avg 3637.69*4（numjobs）=14550.76，centos7的fio3.7版本是这样乘的，centos8的fio3.19这个avg和前面那个iops是一样的。
write: IOPS=43.7k, BW=341MiB/s (358MB/s)(600GiB/1800007msec)
#写的数据，含义同读一致
slat (usec): min=2, max=4047, avg= 9.53, stdev= 4.52
clat (usec): min=852, max=318674, avg=4888.70, stdev=5090.93
lat (usec): min=863, max=318690, avg=4898.23, stdev=5091.07
clat percentiles (msec):
| 1.00th=[ 3], 5.00th=[ 3], 10.00th=[ 4], 20.00th=[ 4],
| 30.00th=[ 4], 40.00th=[ 5], 50.00th=[ 5], 60.00th=[ 5],
| 70.00th=[ 5], 80.00th=[ 6], 90.00th=[ 7], 95.00th=[ 8],
| 99.00th=[ 12], 99.50th=[ 24], 99.90th=[ 87], 99.95th=[ 101],
| 99.99th=[ 138]
bw ( KiB/s): min=60548, max=101632, per=25.00%, avg=87316.05, stdev=6232.11, samples=1439
iops : min= 7568, max=12704, avg=10914.15, stdev=779.02, samples=1439
lat (usec) : 500=0.07%, 750=0.20%, 1000=0.34%
lat (msec) : 2=5.02%, 4=42.79%, 10=50.43%, 20=0.73%, 50=0.13%
lat (msec) : 100=0.26%, 250=0.04%, 500=0.01%
cpu : usr=23.23%, sys=10.93%, ctx=71605963, majf=0, minf=573525
IO depths : 1=0.1%, 2=0.1%, 4=0.1%, 8=0.1%, 16=0.1%, 32=0.1%, >=64=100.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.1%, >=64=0.0%
issued rwts: total=26193847,78582372,0,0 short=0,0,0,0 dropped=0,0,0,0
latency : target=0, window=0, percentile=100.00%, depth=64
Run status group 0 (all jobs):
READ: bw=114MiB/s (119MB/s), 114MiB/s-114MiB/s (119MB/s-119MB/s), io=200GiB (215GB), run=1800007-1800007msec
WRITE: bw=341MiB/s (358MB/s), 341MiB/s-341MiB/s (358MB/s-358MB/s), io=600GiB (644GB), run=1800007-1800007msec
Disk stats (read/write):
dm-0: ios=1/213, merge=0/0, ticks=0/17, in_queue=17, util=0.00%, aggrios=1/253, aggrmerge=0/18, aggrticks=0/15, aggrin_queue=15, aggrutil=0.00%
sdb: ios=1/253, merge=0/18, ticks=0/15, in_queue=15, util=0.00%
如果你前面有打点数据，目录和这样类似（2.X版本多numjobs只记录一个iops文件）：
我们找一个iops文件进去看看记录的啥东西
5001, 958, 0, 0
5001, 2840, 1, 0
10000, 945, 0, 0
10000, 2851, 1, 0
15000, 923, 0, 0
15000, 2766, 1, 0
20000, 951, 0, 0
20000, 2877, 1, 0
25000, 952, 0, 0
25000, 2751, 1, 0
30001, 902, 0, 0
30001, 2643, 1, 0
35000, 832, 0, 0
35000, 2490, 1, 0
40000, 896, 0, 0
40000, 2637, 1, 0
45000, 867, 0, 0
45000, 2560, 1, 0
第一列是msec，我们统计的是5000msec记录一次，它也基本上是5000msec记录一次，虽然5001有一点点出入。然后第二列是iops。第三列的0和1是指读和写；然后这个结果是25读，75写的数据，每个打点都会记录读和写的iops，比例也差不多是25：75；要是测试模型是只读或者只写，那样一个时间就只有一行即一个打点数据；然后这是一个numjob里面的数据，要是有多个，计算iops的时候要把每个iops文件的iops的数据都加起来统计进去。Bw文件里记录的是类似的。