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

Fio 是个强大的IO压力测试工具，我之前写过不少fio的使用和实践，参见这里。

随着块设备的发展，特别是SSD盘的出现，设备的并行度越来越高。利用好这些设备，有个诀窍就是提高设备的iodepth, 一把喂给设备更多的IO请求，让电梯算法和设备有机会来安排合并以及内部并行处理，提高总体效率。

应用使用IO通常有二种方式：同步和异步。同步的IO一次只能发出一个IO请求，等待内核完成才返回，这样对于单个线程iodepth总是小于1，但是可以透过多个线程并发执行来解决，通常我们会用16-32根线程同时工作把iodepth塞满。异步的话就是用类似libaio这样的linux native aio一次提交一批，然后等待一批的完成，减少交互的次数，会更有效率。

io队列深度通常对不同的设备很敏感，那么如何用fio来探测出合理的值呢？

让我们先来看下和iodepth相关的参数：

iodepth=int
Number of I/O units to keep in flight against the file. Note that increasing iodepth beyond 1 will not affect synchronous ioengines
(except for small degress when verify_async is in use). Even async engines my impose OS restrictions causing the desired depth not to be
achieved. This may happen on Linux when using libaio and not setting direct=1, since buffered IO is not async on that OS. Keep an eye on
the IO depth distribution in the fio output to verify that the achieved depth is as expected. Default:
1.

iodepth_batch=int
Number of I/Os to submit at once. Default: iodepth.

iodepth_batch_complete=int
This defines how many pieces of IO to retrieve at once. It defaults to 1 which
means that we’ll ask for a minimum of 1 IO in the retrieval process from the kernel. The IO retrieval will go on until we hit the limit
set by iodepth_low. If this variable is set to 0, then fio will always check for completed events before queuing more IO. This helps
reduce IO latency, at the cost of more retrieval system calls.

iodepth_low=int
Low watermark indicating when to start filling the queue again. Default: iodepth.

direct=bool
If true, use non-buffered I/O (usually O_DIRECT). Default: false.

fsync=int
How many I/Os to perform before issuing an fsync(2) of dirty data. If 0, don’t sync. Default: 0.

这几个参数在libaio的引擎下的作用，文档写的挺明白，但容我再罗嗦下IO请求的流程：

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在电梯口排队着。

注意：这些参数在文档里面描述的有点小问题，比如说默认值什么的是不太对的，所以我的建议是这些参数要去显示的写。

如何确认fio安装我们的配置在工作呢？ fio提供了诊断办法 --debug=io ，我们来演示下：

# cat nvdisk-test

[global]

bs=512

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/nvdisk0

numjobs=1

fio任务配置里面有几个点需要非常注意：
1. libaio工作的时候需要文件direct方式打开。
2. 块大小必须是扇区(512字节)的倍数。
3. userspace_reap提高异步IO收割的速度。
4. ramp_time的作用是减少日志对高速IO的影响。
5. 只要开了direct,fsync就不会发生。

# fio nvdisk-test --debug=io

fio: set debug option io

io 22441 load ioengine libaio

test: (g=0): rw=randrw, bs=512-512/512-512, ioengine=libaio, iodepth=16

fio 2.0.5

Starting 1 process

io 22444 invalidate cache /dev/nvdisk0: 0/8589926400

io 22444 fill_io_u: io_u 0x6d3210: off=3694285312/len=512/ddir=0//dev/nvdisk0

io 22444 prep: io_u 0x6d3210: off=3694285312/len=512/ddir=0//dev/nvdisk0

io 22444 ->prep(0x6d3210)=0

io 22444 queue: io_u 0x6d3210: off=3694285312/len=512/ddir=0//dev/nvdisk0

io 22444 fill_io_u: io_u 0x6d2f80: off=4595993600/len=512/ddir=0//dev/nvdisk0

io 22444 prep: io_u 0x6d2f80: off=4595993600/len=512/ddir=0//dev/nvdisk0

io 22444 ->prep(0x6d2f80)=0

io 22444 queue: io_u 0x6d2f80: off=4595993600/len=512/ddir=0//dev/nvdisk0

io 22444 fill_io_u: io_u 0x6d2cb0: off=3825244160/len=512/ddir=0//dev/nvdisk0

io 22444 prep: io_u 0x6d2cb0: off=3825244160/len=512/ddir=0//dev/nvdisk0

io 22444 ->prep(0x6d2cb0)=0

io 22444 queue: io_u 0x6d2cb0: off=3825244160/len=512/ddir=0//dev/nvdisk0

io 22444 fill_io_u: io_u 0x6d29a0: off=6994864640/len=512/ddir=0//dev/nvdisk0

io 22444 prep: io_u 0x6d29a0: off=6994864640/len=512/ddir=0//dev/nvdisk0

io 22444 ->prep(0x6d29a0)=0

io 22444 queue: io_u 0x6d29a0: off=6994864640/len=512/ddir=0//dev/nvdisk0

io 22444 fill_io_u: io_u 0x6d2710: off=2572593664/len=512/ddir=0//dev/nvdisk0

io 22444 prep: io_u 0x6d2710: off=2572593664/len=512/ddir=0//dev/nvdisk0

io 22444 ->prep(0x6d2710)=0

io 22444 queue: io_u 0x6d2710: off=2572593664/len=512/ddir=0//dev/nvdisk0

io 22444 fill_io_u: io_u 0x6d2400: off=3267822080/len=512/ddir=0//dev/nvdisk0

io 22444 prep: io_u 0x6d2400: off=3267822080/len=512/ddir=0//dev/nvdisk0

io 22444 ->prep(0x6d2400)=0

io 22444 queue: io_u 0x6d2400: off=3267822080/len=512/ddir=0//dev/nvdisk0

io 22444 fill_io_u: io_u 0x6d2130: off=7099489280/len=512/ddir=0//dev/nvdisk0

io 22444 prep: io_u 0x6d2130: off=7099489280/len=512/ddir=0//dev/nvdisk0

io 22444 ->prep(0x6d2130)=0

io 22444 queue: io_u 0x6d2130: off=7099489280/len=512/ddir=0//dev/nvdisk0

io 22444 fill_io_u: io_u 0x6d1ea0: off=7682447872/len=512/ddir=0//dev/nvdisk0

io 22444 prep: io_u 0x6d1ea0: off=7682447872/len=512/ddir=0//dev/nvdisk0

io 22444 ->prep(0x6d1ea0)=0

io 22444 queue: io_u 0x6d1ea0: off=7682447872/len=512/ddir=0//dev/nvdisk0

io 22444 calling ->commit(), depth 8

io 22444 fill_io_u: io_u 0x6d1b90: off=5983331840/len=512/ddir=0//dev/nvdisk0

io 22444 prep: io_u 0x6d1b90: off=5983331840/len=512/ddir=0//dev/nvdisk0

io 22444 ->prep(0x6d1b90)=0

io 22444 queue: io_u 0x6d1b90: off=5983331840/len=512/ddir=0//dev/nvdisk0

io 22444 fill_io_u: io_u 0x6cdfa0: off=6449852928/len=512/ddir=0//dev/nvdisk0

...

我们可以看到详细的IO工作过程，这个方法不需要对OS非常的熟悉，比较实用。

还有个方法就是透过strace来跟踪系统调用的情况, 更直观点。

# pstree -p

init(1)─┬─agent_eagleye(22296)

├─screen(13490)─┬─bash(18324)─┬─emacs(19429)

│ │ ├─emacs(20365)

│ │ ├─emacs(21268)

│ │ ├─fio(22452)─┬─fio(22454)

│ │ │ └─{fio}(22453)

│ │ └─man(20385)───sh(20386)───sh(20387)───less(20391)

├─sshd(1834)───sshd(13115)───bash(13117)───screen(13662)

└─udevd(705)─┬─udevd(1438)

└─udevd(1745

# strace -p 22454

...

io_submit(140534061244416, 8, {{(nil), 0, 1, 0, 3}, {(nil), 0, 0, 0, 3}, {(nil), 0, 0, 0, 3}, {(nil), 0, 0, 0, 3}, {(nil), 0, 0, 0, 3}, {(nil), 0, 1, 0, 3}, {(nil), 0, 1, 0, 3}, {(nil), 0, 0, 0, 3}}) = 8

io_getevents(140534061244416, 8, 8, {{(nil), 0x6d3210, 512, 0}, {(nil), 0x6d2f80, 512, 0}, {(nil), 0x6d2cb0, 512, 0}, {(nil), 0x6d29a0, 512, 0}, {(nil), 0x6d2710, 512, 0}, {(nil), 0x6d2400, 512, 0}, {(nil), 0x6d2130, 512, 0}, {(nil), 0x6d1ea0, 512, 0}}, NULL) = 8

...

最后有效的一招就是用iostat -dx 1来确认你的iodepth是符合设备特性的。

(由于我用的是nvram卡，这个卡的设备驱动没有队列，iostat看不到队列深度，就用了其他的设备的图代替，表明可以用看iostat看IO队列深度,谢谢网友Uranus指出)
通过这些方法确认你的配置是对的，之后分析出来的数据才会有意义。

Fio压测工具和io队列深度理解和误区相关推荐

Fio工具详解【强大的IO性能压测工具】
文章目录 Fio压测工具操作常用参数 [time] [I/O tpye] [Blocks size] [Job description] [Threads, processes and job sy ...
多线程与高并发（九）：单机压测工具JMH，单机最快MQ - Disruptor原理解析
单机压测工具JMH JMH Java准测试工具套件什么是JMH 官网 http://openjdk.java.net/projects/code-tools/jmh/ 创建JMH测试 1.创建Mav ...
locust压测工具【学习】
locust压测工具[学习] 1.安装:pip3 install locust 检验版本:locust -V 2.使用脚本: from locust import task, HttpUser, co ...
常用性能压测工具实战总结
### 一.压测背景 >以前:未出社会之前经常用AB工具来压测自己的 nginx 欢迎页面,看着服务器的资源从20%到100%,发现原来一个开源的工具都可以把一台4C8G的虚拟机压爆满,然后就陷 ...
MeterSphere在开源压测工具JMeter上的分布式优化和实践
Apache JMeter是一款100%纯Java的开源软件,旨在加载测试功能行为和测量性能.它可以用来测试静态和动态资源的性能,例如静态文件.Java Servlet.CGI Scripts.Jav ...
Http压测工具wrk使用指南【转】
用过了很多压测工具,却一直没找到中意的那款.最近试了wrk感觉不错,写下这份使用指南给自己备忘用,如果能帮到你,那也很好. 安装 wrk支持大多数类UNIX系统,不支持windows.需要操作系统支持 ...
Http压测工具wrk使用指南
用过了很多压测工具,却一直没找到中意的那款.最近试了wrk感觉不错,写下这份使用指南给自己备忘用,如果能帮到你,那也很好. 安装 wrk支持大多数类UNIX系统,不支持windows.需要操作系统支持 ...
python服务端多进程压测工具
本文描述一个python实现的多进程压测工具,这个压测工具的特点如下: 多进程在大多数情况下,压测一般适用于IO密集型场景(如访问接口并等待返回),在这种场景下多线程多进程的区分并不明显(详情请参见 ...
web版本开源压测工具_Web压测工具之Webbench和http_load
Webbench简介是知名的网站压力测试工具,能测试处在相同硬件上,不同服务的性能以及不同硬件上同一个服务的运行状况. webbench的标准测试可以向我们展示服务器的两项内容:每秒钟相应请求数和每 ...

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

Fio压测工具和io队列深度理解和误区相关推荐

最新文章

热门文章