Linux下FIO测试

#!/bin/bash

for blocksize in 4k 512k

do

for pattern in read write randread randwrite

do

fio --name=/dev/sdb --name=/dev/sdc --name=/dev/sdd --name=/dev/sde --name=/dev/sdf --name=/dev/sdg --name=/dev/sdh --name=/dev/sdi --name=/dev/sdj --name=/dev/sdh --name=/dev/sdl --direct=1 --bs=$blocksize --rw=$pattern --iodepth=32 --runtime=120 --time_based

done

done

Summary : Multithreaded IO generation tool

Description : fio is an I/O tool that will spawn a number of threads or processes doing a particular type of io action as specified by the user.  fio takes a number of global parameters, each inherited by the thread unless otherwise parameters given to them overriding that setting is given.

The typical use of fio is to write a job file matching the io load one wants to simulate.

多线程IO生成工具

fio是一个I / O工具，它将产生许多线程或正在执行的进程 ，由用户指定的特定类型的io *** 作。 

fio需要一个 全局参数的数量，每个参数都由线程继承，否则给他们的参数将覆盖该设置。 

fio的典型用法是编写与io负载匹配的需要模拟的作业文件 。

官网地址： http://freecode.com/projects/fio

# yum -y install libaio gtk2 libaio-devel gtk2-devel

# yum -y install fio

# yum info fio

# rpm -ql fio | grep "bin"

应用使用IO通常有二种方式：同步和异步。 

同步的IO一次只能发出一个IO请求，等待内核完成才返回，这样对于单个线程iodepth总是小于1，但是可以透过多个线程并发执行来解决，通常我们会用16-32根线程同时工作把iodepth塞满。

异步的话就是用类似libaio这样的Linux native aio一次提交一批，然后等待一批的完成，减少交互的次数，会更有效率。

注意 : 性能测试建议直接通过写裸盘的方式进行测试，会得到较为真实的数据，但直接测试裸盘会破坏文件系统结构，导致数据丢失，请在测试前确认磁盘中数据已备份。

# fio   -direct=1  -iodepth=64  -rw=read  -ioengine=libaio  -bs=4k  -size=10G  -numjobs=1  -name=./fio.test

"-direct=1"，代表采用非 buffered I/O 文件读写的方式，避免文件读写过程中内存缓冲对性能的影响

"-iodepth=64"和"-ioengine=libaio"这两个参数，这里指文件读写采用异步 I/O（Async I/O）的方式，也就是进程可以发起多个 I/O 请求，并且不用阻塞地等待 I/O 的完成。稍后等 I/O 完成之后，进程会收到通知。这种异步 I/O 很重要，因为它可以极大地提高文件读写的性能。在这里我们设置了同时发出 64 个 I/O 请求

"-rw=read，-bs=4k，-size=10G"，这几个参数指这个测试是个读文件测试，每次读 4KB 大小数块，总共读 10GB 的数据。最后一个参数是"-numjobs=1"，指只有一个进程 / 线程在运行。所以，这条 fio 命令表示我们通过异步方式读取了 10GB 的磁盘文件，用来计算文件的读取性能。

我们看到在 上图中测试中， I/O 性能是 15.9MB/s 的带宽，IOPS（I/O per second）是 4076 左右。

fio压测工具和io队列深度理解和误区

http://blog.yufeng.info/archives/2104

fio – IO压力测试工具

https://younger.blog.csdn.net/article/details/71129541

fio安装使用方法

https://www.kclouder.cn/fio

fio模拟MySQL服务器IO压力脚本

http://blog.yufeng.info/archives/1497

fio使用详解

https://blog.csdn.net/m0_37972390/article/details/80019762

Fio Output Explained

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

摘要： 本文就将通过对磁盘性能测试指标及参数的介绍，来理解以上两个原因为什么会对测试结果有影响。

近日工作中遇到了一个磁盘压测时性能上不去的问题，经排查，发现原因有以下几个方面：

1 测试参数的选择

2 业务逻辑未关闭

本文就将通过对磁盘性能测试指标及参数的介绍，来理解以上两个原因为什么会对测试结果有影响。

首先来介绍一下磁盘性能的测试指标。

最常用的磁盘性能评价指标有两个：IOPS和吞吐量（throughput）。IOPS是Input/Output Per Second的缩写，它表示单位时间内系统能处理的I/O请求数量，即每秒钟系统能处理的读写次数。

吞吐量衡量单位时间内系统能处理的数据的体量，即每秒钟磁盘上能读写出的数据量的大小，通常以kB/s或MB/s为单位。

两个指标相互独立，又相互关联，在不同业务场景下，侧重关注的指标也有所不同。

对于文件尺寸小，随机读写比较多的场合，比如在线交易处理系统，我们倾向于更关注IOPS，因为我们更在乎的是每秒钟能处理多少条交易。

而对于文件尺寸较大，顺序读写比较多的场合，比如视频播放服务，数据吞吐量将会成为我们主要的考量指标。

举个例子来帮助我们更好的理解这两个指标。磁盘IO就相当于我们有货物（数据）需要从A处（系统）与B处（磁盘）之间往返。货物（数据量）有多有少，因此运货车也有大有小。B处有装卸工人负责将货物卸载到仓库的指定位置，或者从仓库指定位置提取货物装载到货车上。

每次货车运输一趟货物就相当于处理一个IO请求，工人装卸货物就相当于磁盘对IO的读写处理。在工人数量和工人装卸货物速度（磁盘数据处理速度）保持一定的情况下，装卸大车上货物的时间一定会比小车上的时间长，装卸一大车货物的时间，可能已经够小车运输若干趟货物（IOPS高）。但是小车由于多次往返，其花在路上的时间要比大车多，同时每次装卸货物工人需要寻找正确的位置存取货物（磁盘寻址时间），比起大车的一次寻址，小车运货就也浪费了更多时间。因此在相同时间内，采用大车运输的货物总量是比小车要多的（吞吐量高）。

这也是为什么我们在做磁盘性能测试的时候，通常一次只关注一个指标，追求IOPS，就用小车运输少量货物，多次往返。追求吞吐量，就用大车运送大量货物，节省路上及寻址所花费的时间。

下面再说一下磁盘测试的影响因素。

实际测量中，IOPS会受到很多因素的影响，比如：

1 数据块大小

相当于我们前面说的大车和小车运货的情况

2 顺序和随机

顺序就是我们的货物都按顺序安排在仓库的一处，随机则意味着货物随机的分配在仓库的不同地点，可以想见，货物地点存放比较随机的情况下，存取货物一定是更费时间的。

3 队列深度

如果我们每次只发一辆货车在AB之间往返，那么当货车在A处处理货物或者在AB之间的路上跑的时候，B处的工人就处于闲置的状态，压力测试时，我们绝对不希望这种情况发生，我们需要工人（磁盘）一直工作，从而得出磁盘的最高性能。想实现这一点，我们可以通过一次发多辆车来解决，保持始终有车辆在等待处理的队伍里，这样装卸工人就一直有工作可做了。

队列深度就是等待处理的队伍里的货车以及正在被装卸的货车的总数量。

4 线程数

测试时，增加线程数也可以增加并发度，从而使装卸工人一直处于有工作可做的状态。

5 读写比例

读 *** 作相当于我们将货从B中的仓库取出来，运到A处就结束了。而写 *** 作意味着货物在A处经过一番处理之后还要再运回B处并存储在仓库中。因此不同的读写比例也会造成测试结果的不同。

正是由于这些不同影响因素的存在，我们在对磁盘进行性能测试时，需要仔细选择测试参数，否则将无法测出磁盘的最优性能。同时应将测试参数和方法定性定量，否则测试结果将失去比较的价值。

以 云盘参数和性能测试方法：

https://help.aliyun.com/document_detail/25382.html

一文中介绍的测试IOPS的方法为例，我们来看一下linux常用测试工具fio的参数如何体现以上影响因素。

测试随机写IOPS：fio-direct=1-iodepth=128-rw=randwrite-ioengine=libaio-bs=4k-size=1G-numjobs=1-runtime=1000-group_reporting-filename=/dev/[device]-name=Rand_Write_Testing测试随机读IOPS：fio-direct=1-iodepth=128-rw=randread-ioengine=libaio-bs=4k-size=1G-numjobs=1-runtime=1000-group_reporting-filename=/dev/[device]-name=Rand_Read_Testing测试写吞吐量：fio-direct=1-iodepth=64-rw=write-ioengine=libaio-bs=1024k-size=1G-numjobs=1-runtime=1000-group_reporting-filename=/dev/[device]-name=Write_PPS_Testing测试读吞吐量：fio-direct=1-iodepth=64-rw=read-ioengine=libaio-bs=1024k-size=1G-numjobs=1-runtime=1000-group_reporting-filename=/dev/[device]-name=Read_PPS_Testing

其中：

iodepth：队列深度。异步引擎下起作用。

rw: 读写模式，可选模式有顺序写write、顺序读read、随机写randwrite、随机读randread、混合随机读写randrw。

ioengine: 负载引擎。libaio引擎用于发起异步IO请求。

bs: IO块大小。

numjobs 测试线程数。

对比四个测试方法的参数我们可以看到，测试IOPS时我们采用小数据块（bs=4k），测试吞吐量时则用大数据块（bs=1024k）。这和我们前面说到的大货车小货车的选择原理是一致的。

队列深度对IOPS的影响要大于对吞吐量的影响，因为我们测试IOPS时选择的iodepth更大。但iodepth也不是越大越好，因为当装卸工人数量、装卸货物速度、仓库寻址时间一定之后，单位时间内所能处理的最大货物量也就确定了，即磁盘的能力确定了。一味增加队列深度，增加的只能是货物在队列里的等待时间，即平均IO响应时间。

我们可以通过查看装卸工人的忙碌程度来决定是否要增加队列深度。如果磁盘的busy%为100%，那就表示所有工人都在一刻不停歇的装卸货物了，已经不再有提升的空间，此时再增加队列深度或是数据量大小对测试结果都将是徒劳。反之，则表示磁盘压力尚未到极限，得出的数据不能代表磁盘性能最高水平。

磁盘压测时如果有其他业务逻辑在运行会怎样呢？这种情况就相当于有一部分货车装运的是业务逻辑的数据，而这些货车也会占用我们的队列和装卸工人，测试引擎将无法百分之百的使用全部队列和装卸工人，那么我们的测试结果将不能体现整个磁盘的能力。尤其是当业务逻辑所涉及的IO是同步（synchronous）请求的时候，对测试结果的影响将更大，因为同步IO就相当于前面说到的一次只让一辆车在路上跑，只有等它跑完才会发下一辆车。因此在压力测试的时候，我们需要将业务逻辑关闭的。

原文链接

---