fio使用good blog

【Linux应用】磁盘IO读写测试工具-FIO详解_协议森林的博客-CSDN博客_fio读写测试

编译安装，常用参数，实例，结果说明

SSD测试第一神器——FIO

磁盘IO体系架构与存储解决方案-pudn.com

磁盘性能指标——IOPS与吞吐量

 

 

 

线程指的是同时有多少个读或写任务在并行执行，一般来说，CPU里面的一个核心同一时间只能运行一个线程。如果只有一个核心，要想运行多线程，只能使用时间切片，每个线程跑一段时间片，所有线程轮流使用这个核心。Linux使用Jiffies来代表一秒钟被划分成了多少个时间片，一般来说Jiffies是1000或100，所以时间片就是1毫秒或10毫秒。

为了提高并行性，大部分情况下SSD读写采用的是异步模式。就是用几微秒发送命令，发完线程不会傻傻的在那里等，而是继续发后面的命令。如果前面的命令执行完了，SSD通知会通过中断或者轮询等方式告诉CPU，CPU来调用该命令的回调函数来处理结果。这样的好处是，SSD里面几十上百个并行单元大家都能分到活干，效率暴增。

不过，在异步模式下，CPU不能一直无限的发命令到SSD。比如SSD执行读写如果发生了卡顿，那有可能系统会一直不停的发命令，几千个，甚至几万个，这样一方面SSD扛不住，另一方面这么多命令会很占内存，系统也要挂掉了。这样，就带来一个参数叫做队列深度。举个例子，队列深度64就是说，系统发的命令都发到一个大小为64的队列，如果填满了就不能再发。等前面的读写命令执行完了，队列里面空出位置来，才能继续填命令。

Linux读写SSD等块设备使用的是BIO，Block-IO，这是个数据结构，包含了数据块的逻辑地址LBA，数据大小和内存地址等。

–numjobs=1：每个job是1个线程，这里用了几，后面每个用-name指定的任务就开几个线程测试。所以最终线程数=任务数* numjobs。

–output TestResult.log：日志输出到TestResult.log。

用FIO可以检验写入数据是否出错。用-verify=str来选择校验算法，有md5 crc16 crc32 crc32c crc32c-intel crc64 crc7 sha256 sha512 sha1等。为了校验，需要用do_verify参数。如果是写，那么do_verify=1就意味着写完再读校验，这种会很占内存，因为FIO会把每个数据块的校验数据保存在内存里。do_verify=0时只写校验数据，不做读校验。

 

读的时候do_verify=1，那么读出来的数据都会做校验值检查，do_verify=0的话，只读数据，不做检查。

另外，verify=meta时，fio会在数据块内写入时间戳、逻辑地址等，此时还能verify_pattern指定写入数据pattern。

可以多个-name来并行执行多个task

ipdepth vs numjobs

fio工具中的iodepth参数与numjobs参数-对测试结果的影响_半遮雨的博客-CSDN博客_fio numjobs

此次测试结果中，使用numjobs参数测试出的效果要好，更能够增加集群客户端测试压力，使测试结果更准确。而iodepth参数设置后，集群带宽值几乎不变，反而延时随着iodepth增加而成倍增加。混合设置后也同样如此，随着iodepth的值增加，带宽值没有增加，反而延时成倍增加。所有延时增加的倍数刚好是iodepth增加的倍数。

一般情况下，为了达到磁盘的最高性能，通常会选择较高的iodepth（128或256）。对于P4XXX的硬盘，通常可能一个CPU core无法达到满IOPS，此时并不是由于一个core的能力不够，而是由于硬盘中硬件队列本身限制的问题。因此，通常需要使用两个CPU core才能够达到specification中的满IOPS。此外，对于以3D Xpoint为介质的Optane(Intel P4800X),通常只需要一个core并使用较小的iodepth即可达到满IOPS，此时已经达到硬盘的上限，若再次增大iodepth只会是latency变大而IOPS不再增长。