FIO测试在不同内核IO参数配置下性能变化情况实验数据记录

最新推荐文章于 2024-07-17 18:34:59 发布

「已注销」

最新推荐文章于 2024-07-17 18:34:59 发布

阅读量1.6k

点赞数 1

本文链接：https://blog.csdn.net/qq_39785575/article/details/114781130

版权

本文记录了一次使用FIO进行的IO性能测试实验，探讨了不同内核参数如ioengine、iodepth、预读参数read_ahead_kb以及脏数据参数dirty_ratio、dirty_background_ratio、dirty_expire_centisecs对系统性能的影响。实验表明，适当调整预读值可以提升顺序读性能，而对随机读影响较小；增大dirty_ratio能提高写数据性能。此外，还讨论了带宽竞争实验，分析了不同带宽限制下的IO行为。

摘要由CSDN通过智能技术生成

实验环境为：四核八线程core i5 CPU，16G内存，350G HDD硬盘
可以在系统盘测试文件系统读写性能，不能测试裸盘的性能！！！测试的时候先利用fio写一个大文件，然后再做读的测试，防止读测试出错。

部分参数的定义

ioengine：定义job怎么给文件提交I/O，也就是如何下发I/O请求，sync使用read和write做同步IO；libaio是Linux上原生异步I/O引擎，Linux仅支持非缓存I/O(设置direct=1(设置O_DIRECT标志，数据直写，默认为0)或buffered=0)的队列行为；io_uring是快速Linux异步I/O引擎，它支持缓存和非缓存的异步I/O； mmap对应于文件是用mmap映射到内存的这种情况，数据是用memcpy复制到内存。
iodepth：I/O队列深度，针对文件保留的I/O单元数量，有博客解释说是定义每个进程/线程可以同时下发的I/O数量。使用这个参数可以充分利用设备，提高效率。官方文档说在使用libaio引擎的同时要设置direct为1才可以使用，因为Linux可能仅仅支持非缓冲I/O时的队列行为，但在我的测试当中发现缓存I/O也能设置使用这个参数。
Linux上的缓存I/O不是异步的？使用缓存的情况下只能使用多线程的方式来加大压力吗？
iodepth_batch：定义一次提交多少个I/O，默认为1
runtime：在读写完size的时间小于这个指定的时间时，当size制定的数据全部读写完成fio就结束；但当读写完size的数据所需的时间大于runtime指定的时间时，fio在运行runtime指定的时间后结束。
输出结果中的lat表示从fio创建一个I/O单元到I/O操作完成所花费的时间；slat表示fio提交一个I/O单元花费的时间；clat表示I/O单元提交之后到完成所花费的时间。输出结果中的cpu信息这一部分也有比较有意思的东西，ctx表示对应线程/进程在执行I/O过程中上下文切换的次数。

测试情况

不同场景下测试公式基本一致，主要调整的是bs、rw、iodepth、numjobs、ioengine等几个参数.
在测试顺序读时，bs的大小影响IOPS：基本上bs增大一倍，IOPS就减小一倍。
fio -filename=/tmp/testfile -ioengine=libaio -iodepth=16 -direct=0 -bs=32k -rw=randwrite -numjobs=8 -size=10G -group_reporting -thread -runtime=100 -name=mytest
上述参数设置刚好触及dirty_ratio的阈值，上述参数做缓存I/O在I/O结束的时候会生成大量Dirty，因此在fio结束后磁盘利用率还是很高直到把Dirty全部写入到磁盘以后，这种应该就是要避免的IO峰值，把Dirty调大确实会有这样的问题，只能把writeback相关的参数调小；而直接I/O在fio结束之后磁盘的利用率就立刻减小了。
随机读写和顺序读写在HDD上速度差别巨大，差不多差了有几百倍；缓存I/O和直接I/O的性能差异也很大。
不太明白为什么在第一次fio用缓存I/O读取某个文件的时候速度就很快(远快于直接I/O)，和后面每一次fio用同样参数读取文件的速度一样快，第一次读内存中应该没有缓存，速度不应该是比较慢的吗？
在测试预读参数的时候，调整预读参数，数据读性能没有改变，于是将bs参数从4改为128，将线程数量从4改为8，就看到一个相对合理的结果，因此，读写的压力对测试结果有比较大的影响。

测试数据分析

使用如下参数测试同步顺序读文件的性能： fio -name=mytest -ioengine=sync -direct=0 -size=10G -filename=/tmp/testfile -group_reporting -thread -numjobs=8 -bs=64k -rw=read
测试结果：不管是在本地机器上测试还是在腾讯云服务器上面测试，把numjobs(线程数量)参数成倍的增大，IOPS和BW都会随着线程数量成倍地增大，直到某一个值为止，但是磁盘的利用率util却会下降。增加远超过核心数量的线程数量IOPS和BW能够增加的原因可能是使用的ioengine为sync同步模式，它使用read和write来读写，每一个线程一次只能提交一个I/O任务就被阻塞，因此线程数量越多就有更多的线程在其他线程被阻塞的时候被CPU调度，因此可以提高IOPS和BW。IOPS和BW一直增加说明没有达到磁盘的最大负载。
既然IOPS和BW都在增大，说明磁盘传