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

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

 随着块设备的发展,特别是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. 块大小必须是扇区的倍数。

     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
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是符合设备特性的。

     

    通过这些方法确认你的配置是对的,之后分析出来的数据才会有意义。

【编辑推荐】

  1. Clojure世界:如何做性能测试
  2. Windows安全最高境界
  3. IE8安全新功能实测,到底给不给力?
责任编辑:赵宁宁
相关推荐

2023-02-22 08:15:13

压测模拟计算

2023-10-19 08:23:50

wrkOpenResty工具

2024-03-21 10:39:24

CIOAI

2010-04-09 13:16:03

2010-07-14 10:53:20

Web应用

2021-02-03 14:51:34

MySQL数据库压测工具

2021-03-05 13:30:51

MySQL数据库压测工具

2020-12-03 09:57:34

MySQL压测工具数据库

2016-01-14 13:07:20

美团压测工具工具

2022-11-25 18:49:11

云原生

2019-08-19 00:14:12

网络测试带宽网络流量

2021-11-15 11:03:09

接口压测工具

2023-10-31 18:12:03

压测工具测试

2019-02-13 19:00:01

深度学习机器学习人工神经

2012-10-15 09:47:06

BYODRSA大会

2014-11-25 11:37:17

压测 软件测试

2016-08-08 18:11:50

服务器压力测试

2019-11-17 22:11:11

TCPSYN队列Accept队列

2022-01-17 09:18:28

JMeter分布式压测

2023-01-16 08:09:22

PulsarMQ
点赞
收藏

51CTO技术栈公众号