fio与iometer
FIO是测试IOPS的非常好的工具，用来对硬件进行压力测试和验证，支持13种不同的I/O引擎，包括:sync,mmap, libaio, posixaio, SG v3, splice, null, network, syslet, guasi, solarisaio 等等。他可以通过多线程或进程模拟各种io操作。
fio这个工具实在太强大了，列举一下他的NB之处吧
1）支持十几种存储引擎，可以自定义
2）自带做图工具，调用gnuplot做图
3）支持几乎所有的存储描述参数
4）大量对CPU，内存，进程/线程，文件，IO特性的配置
5）压缩，trace回放，。。。这些都包含，灵活的配置
随着块设备的发展，特别是SSD盘的出现，设备的并行度越来越高。要想利用好这些设备，有个诀窍就是提高设备的iodepth, 一次喂给设备更多的IO请求，让电梯算法和设备有机会来安排合并以及内部并行处理，提高总体效率。
应用程序使用IO通常有二种方式：同步和异步。 同步的IO一次只能发出一个IO请求，等待内核完成才返回，这样对于单个线程iodepth总是小于1，但是可以通过多个线程并发执行来解决，通常我们会用16-32个线程同时工作把iodepth塞满。 异步的话就是用类似libaio这样的Linux native aio一次提交一批，然后等待一批的完成，减少交互的次数，会更有效率。
io队列深度通常对不同的设备很敏感，那么如何用fio来探测出合理的值呢？在fio的帮助文档里是如何解释iodepth相关参数的
iodepth=int iodepth_batch=int iodepth_batch_complete=int iodepth_low=int fsync=int direct=bool
这几个参数在libaio的引擎下的作用，会用iodepth值来调用io_setup准备一个可以一次提交iodepth个IO的上下文，同时申请一个io请求队列用于保持IO。 在压测进行的时候，系统会生成特定的IO请求，往io请求队列里面扔，当队列里面的IO数量达到iodepth_batch值的时候，就调用io_submit批次提交请求，然后开始调用io_getevents开始收割已经完成的IO。 每次收割多少呢？由于收割的时候，超时时间设置为0，所以有多少已完成就算多少，最多可以收割iodepth_batch_complete值个。随着收割，IO队列里面的IO数就少了，那么需要补充新的IO。 什么时候补充呢？当IO数目降到iodepth_low值的时候，就重新填充，保证OS可以看到至少iodepth_low数目的io在电梯口排队着。
[root@vmforDB05 ~]# fio -filename=/dev/mapper/cachedev -direct=1 -rw=randread -bs=8k -size 1G -numjobs=8 -runtime=30 -group_reporting -name=file
fio -filename=/tmp/test_randread -direct=1 -iodepth 1 -thread -rw=randread -ioengine=psync -bs=16k -size=2G -numjobs=10 -runtime=60 -group_reporting -name=mytest
fio可以通过配置文件来配置压力测试的方式，可以用选项 --debug=io来检测fio是否工作
[root@vmforDB05 tmp]# cat fio_test [global] bsrange=512-2048 ioengine=libaio userspace_reap rw=randrw rwmixwrite=20 time_based runtime=180 direct=1 group_reporting randrepeat=0 norandommap ramp_time=6 iodepth=16 iodepth_batch=8 iodepth_low=8 iodepth_batch_complete=8 exitall [test] filename=/dev/mapper/cachedev numjobs=1
常用参数说明 bsrange=512-2048 //数据块的大小范围，从512bytes到2048 bytes ioengine=libaio //指定io引擎 userspace_reap //配合libaio，提高异步io的收割速度 rw=randrw //混合随机对写io，默认读写比例5:5 rwmixwrite=20 //在混合读写的模式下，写占20% time_based //在runtime压力测试周期内，如果规定数据量测试完，要重复测试 runtime=180 //在180秒，压力测试将终止 direct=1 //设置非缓冲io group_reporting //如果设置了多任务参数numjobs，用每组报告代替每job报告 randrepeat=0 //设置产生的随机数是不可重复的 norandommap ramp_time=6 iodepth=16 iodepth_batch=8 iodepth_low=8 iodepth_batch_complete=8 exitall //一个job完成，就停止所有的 filename=/dev/mapper/cachedev //压力测试的文件名 numjobs=1 //job的默认数量，也就是并发数，默认是1 size=200G //这job总共的io大小 refill_buffers //每次提交后都重复填充io buffer overwrite=1 //设置文件可覆盖 sync=1 //设置异步io fsync=1 //一个io就同步数据 invalidate=1 //开始io之前就失效buffer-cache directory=/your_dir // fielname参数值的前缀 thinktime=600 //在发布io前等待600秒 thinktime_spin=200 //消费cpu的时间，thinktime的剩余时间sleep thinktime_blocks=2 //在thinktime之前发布的block数量
bssplit=4k/30:8k/40:16k/30 //随机读4k文件占30%、8k占40%、16k占30% rwmixread=70 //读占70%
-------end-------
fio任务配置里面有几个点需要非常注意：
1. libaio工作的时候需要文件direct方式打开。
2. 块大小必须是扇区的倍数。
3. userspace_reap提高异步IO收割的速度。
4. ramp_time的作用是减少日志对高速IO的影响。
5. 只要开了direct,fsync就不会发生。
IOMETER
官方网站：http://www.iometer.org/
Iometer的用户指南上说，Iometer是一个单机或者集群的I/O子系统的测量和描述工具。它最初是由英特尔公司在1998年2月17日的英特尔开发者论坛（IDF）宣布，自那时以来，在行业内广泛的蔓延，成为了标准。与此同时，英特尔已经停止Iometer的开发工作并把开放源码交给了OSDL。 2001年11月，Iometer在SourceForge.net注册，开发项目从2003年月2月起又重新启动，当然项目维护者变成了独立的一个内部工作组。（而非Intel）
相比之前3个测试软件，Iometer属于测试软件中比较自由的，可以按照用户需要去调节测试的范围，数据块大小，处理模式等等，当然初学者一开始会比较晕。Iometer当前稳定版为2006，而SandForce主控的SSD厂商却普遍喜欢用Iometer 2008做测试（道理我后面会讲），最新版本为iometer-1.1.0-rc1。这里我会拿最新版来解释。（选项更多)
Iometer包括2个程序，Iometer.exe和Dynamo.exe。其中Iometer是控制程序，是图形界面，让你轻松的调节参数和显示测试结果，而Dynamo就是让测试盘产生压力测试的主程序了，用Iometer来控制Dynamo程序。在Windows下运行Iometer时，会自动打开Dynamo程序（仔细观察会发现开了2个窗口，那个Dos的命令行程序就是Dynamo了。）
1）Topology/Workers:
Worker的数量取决于当前机器上的CPU核心数（我的CPU是2600K，4核8线程,所以有8个Worker)，每个Worker可以让你制定硬盘同时执行的线程数，不过一般我们家用测试只跑一个Worker即可，所以只需要1个Worker即可，多线程测试适合高性能服务器或者企业级的存储设备用的。这里多余的Worker我们可以在测试前删除。 2）Targets:（在设置Disk Target时会有3种不同的图标来表示不同类型的硬盘情况）
黄×××标的表示的是”Logical drive 逻辑磁盘“，意思就是已经分过区的，格式化的并且上面拥有文件系统的磁盘。（会显示硬盘分区卷标和卷标名）
如果黄×××标上加了红色删除的线，则代表的是这块逻辑硬盘上没有iobw.tst文件。Iometer在对逻辑硬盘测试前，会生成一个iobw.tst的测试文件，通过对这个文件进行”读取/写入“操作来计算IO成绩和传输率。
蓝色的图标表示的是”原始(RAW)硬盘“的意思，指的是这块硬盘上文件系统无法识别或者没分区和格式化，测试文件不能在上面创建。（会显示硬盘的型号）
这里有一点需要注意，如果之前做过Iometer逻辑硬盘测试，并在这个分区里已经有iobw.tst文件，则在下次做测试前必须先删除，不然是不能改变这个之前测试生成的iobw.txt文件大小的。（也就是说会影响到下次测试的准确性） 3）Maximum Disk Size / Starting Disk Sector / # of Outstanding IO:
一般的机械硬盘sector（扇区）大小为512字节（扇区为硬盘最小存储单位）。如果这里使用默认的0时，意思就是写满这块硬盘的所有扇区，如果你想测的是固定大小时，可以透过设置Maximum Disk Size这个参数来达到。输入1000就代表会在测试前生成一个大小为1000X512字节的iobw.tst测试文件。Starting Disk Sector指的是由硬盘的第几个扇区开始写入。（这里要强调一点，如果你设置的Maximun Disk Size数字比当前磁盘系统的缓冲区小的话，测试成绩很可能是缓冲区性能，速度会爆高，所以适当设大点吧。）
# of Outstanding I/O 指的是同时发送的IO请求（聪明人知道这个就是体现NCQ的作用了），预设值是1，一般家用测试不会去修改这个项目的，只有厂家秀分数做广告时会去改成32来跑最大IOPS忽悠用户。 4）Write IO Data Pattern（新版Iometer相比2006和2008版多出来的项目）
Repeating Bytes: 生成的IO数据是重复的，比如第一批IO数据是全”A”，第二批是全”B”，这个数据模型是Iometer 2008里默认使用的，也是最适合SandForce主控压缩算法的，所以SandForce做广告时都是用Iometer 2008的数据。
Peseudo random: 缓冲区里用随机的数据模型填满，写入完后再重新生成新的随机数据到缓冲区，造成每次写入IO都不同。这个数据模型是从最初的版本一直到Iometer 2006默认采用的，非常不适合SandForce主控进行压缩算法。
Full random：生成一套随机的16MB大小的数据模型到缓冲区。每次写入IO都会使用这套缓冲区的随机数据模型。（虽然是随机数据，但是由于每次的随机数据都一样，所以对采用了副本压缩技术的SandForce控制器，相当于每次只需要更新随机数据的索引部分即可，还是能够压缩部分数据。）
iometer 1.1.0 GA版本已经正式采用Native kernel AIO方式，抛弃了争议颇多的Glibc AIO方式。
该方式允许所有IO请求直接提交给I/O Scheduler。当I/O请求数较多时，I/O Scheduler 采用不同的电梯算法来处理这些请求。但是Kernel AIO 目前支持Direct IO模式，而非Direct IO（buffer/cache）因为会增加block points，无法做到非阻塞。
iometer 1.1.0 GA版本采用了Linux Kernel AIO方式，同时仅支持Direct IO。所以说，该版本也并非完美的异步IO解决方案应用。但是，由于iometer 仅关注RAW 设备性能，所以即便目前AIO不支持Buffered IO，也没有什么大的影响。如果非要考虑存储系统cache 对性能的影响大小，可以采用其他的IO测试工具，如vdbench；也可以自行patch iometer 源代码。
一般平常测试都用FIO，参数多测的类型丰富也比较准确。
本文转载自网络