IO测试工具之fio详解

目前主流的第三方IO测试工具有fio、iometer和Orion,这三种工具各有千秋。

fio在Linux系统下使用比较方便,iometer在window系统下使用比较方便,Orion是oracle的IO测试软件,可在没有安装oracle数据库的情况下模拟oracle数据库场景的读写。

如下是在Linux系统上采用fio工具来对SAN存储进行的IO测试。

1、安装fio

在fio官网下载fio-2.1.10.tar文件,解压后./configure、make、make install之后就可以使用fio了。

2、fio参数解释

可以使用fio -help查看每个参数,具体的参数左右可以在官网查看how to文档,如下为几个常见的参数描述

filename=/dev/emcpowerb 支持文件系统或者裸设备,-filename=/dev/sda2或-filename=/dev/sdb
direct=1                 测试过程绕过机器自带的buffer,使测试结果更真实
rw=randwread             测试随机读的I/O
rw=randwrite             测试随机写的I/O
rw=randrw                测试随机混合写和读的I/O
rw=read                  测试顺序读的I/O
rw=write                 测试顺序写的I/O
rw=rw                    测试顺序混合写和读的I/O
bs=4k                    单次io的块文件大小为4k
bsrange=512-2048         同上,提定数据块的大小范围
size=5g                  本次的测试文件大小为5g,以每次4k的io进行测试
numjobs=30               本次的测试线程为30
runtime=1000             测试时间为1000秒,如果不写则一直将5g文件分4k每次写完为止
ioengine=psync           io引擎使用pync方式,如果要使用libaio引擎,需要yum install libaio-devel包
rwmixwrite=30            在混合读写的模式下,写占30%
group_reporting          关于显示结果的,汇总每个进程的信息
此外
lockmem=1g               只使用1g内存进行测试
zero_buffers             用0初始化系统buffer
nrfiles=8                每个进程生成文件的数量

3、fio测试场景及生成报告详解

测试场景:

100%随机,100%读, 4K
fio -filename=/dev/emcpowerb -direct=1 -iodepth 1 -thread -rw=randread -ioengine=psync -bs=4k -size=1000G -numjobs=50 -runtime=180 -group_reporting -name=rand_100read_4k

100%随机,100%写, 4K
fio -filename=/dev/emcpowerb -direct=1 -iodepth 1 -thread -rw=randwrite -ioengine=psync -bs=4k -size=1000G -numjobs=50 -runtime=180 -group_reporting -name=rand_100write_4k

100%顺序,100%读 ,4K
fio -filename=/dev/emcpowerb -direct=1 -iodepth 1 -thread -rw=read -ioengine=psync -bs=4k -size=1000G -numjobs=50 -runtime=180 -group_reporting -name=sqe_100read_4k

100%顺序,100%写 ,4K
fio -filename=/dev/emcpowerb -direct=1 -iodepth 1 -thread -rw=write -ioengine=psync -bs=4k -size=1000G -numjobs=50 -runtime=180 -group_reporting -name=sqe_100write_4k

100%随机,70%读,30%写 4K
fio -filename=/dev/emcpowerb -direct=1 -iodepth 1 -thread -rw=randrw -rwmixread=70 -ioengine=psync -bs=4k -size=1000G -numjobs=50 -runtime=180 -group_reporting -name=randrw_70read_4k

结果报告查看:

io=执行了多少M的IO
bw=平均IO带宽
iops=IOPS
runt=线程运行时间
slat=提交延迟
clat=完成延迟
lat=响应时间
bw=带宽
cpu=利用率
IO depths=io队列
IO submit=单个IO提交要提交的IO数
IO complete=Like the above submit number, but for completions instead.
IO issued=The number of read/write requests issued, and how many of them were short.
IO latencies=IO完延迟的分布

io=总共执行了多少size的IO
aggrb=group总带宽
minb=最小.平均带宽.
maxb=最大平均带宽.
mint=group中线程的最短运行时间.
maxt=group中线程的最长运行时间.

ios=所有group总共执行的IO数.
merge=总共发生的IO合并数.
ticks=Number of ticks we kept the disk busy.
io_queue=花费在队列上的总共时间.
util=磁盘利用率

4、扩展之IO队列深度

在某个时刻,有N个inflight的IO请求,包括在队列中的IO请求、磁盘正在处理的IO请求。N就是队列深度。
加大硬盘队列深度就是让硬盘不断工作,减少硬盘的空闲时间。
加大队列深度 -> 提高利用率 -> 获得IOPS和MBPS峰值 ->注意响应时间在可接受的范围内,
增加队列深度的办法有很多,使用异步IO,同时发起多个IO请求,相当于队列中有多个IO请求,多线程发起同步IO请求,相当于队列中有多个IO请求。
增大应用IO大小,到达底层之后,会变成多个IO请求,相当于队列中有多个IO请求 队列深度增加了。
队列深度增加了,IO在队列的等待时间也会增加,导致IO响应时间变大,这需要权衡。
让我们通过增加IO大小来增加dd的队列深度,看有没有效果:

dd if=/dev/zero of=/dev/sdd bs=2M count=1000 oflag=direct

记录了1000+0 的读入 记录了1000+0 的写出 2097152000字节(2.1 GB)已复制,10.6663 秒,197 MB/秒

Device: rrqm/s   wrqm/s   r/s   w/s   rsec/s   wsec/s   avgrq-sz   avgqu-sz   await   svctm   %util
sdd      0.00     0.00   0.00  380.60  0.00    389734.40  1024.00  2.39       6.28    2.56    97.42

可以看到2MB的IO到达底层之后,会变成多个512KB的IO,平均队列长度为2.39,这个硬盘的利用率是97%,MBPS达到了197MB/s。
(为什么会变成512KB的IO,你可以去使用Google去查一下内核参数 max_sectors_kb的意义和使用方法 )也就是说增加队列深度,是可以测试出硬盘的峰值的。

5、Linux系统中查看IO命令iostat详解

[[email protected] /]# iostat -xd 3
Linux 3.8.13-16.2.1.el6uek.x86_64 (rac01-node01)     05/27/2017     _x86_64_    (40 CPU)

Device:         rrqm/s   wrqm/s     r/s     w/s   rsec/s   wsec/s avgrq-sz avgqu-sz   await  svctm  %util
sda               0.05     0.75    2.50    0.50    76.59    69.83    48.96     0.00    1.17   0.47   0.14
scd0              0.00     0.00    0.02    0.00     0.11     0.00     5.25     0.00   21.37  20.94   0.05
dm-0              0.00     0.00    2.40    1.24    75.88    69.83    40.00     0.01    1.38   0.38   0.14
dm-1              0.00     0.00    0.02    0.00     0.14     0.00     8.00     0.00    0.65   0.39   0.00
sdc               0.00     0.00    0.01    0.00     0.11     0.00    10.20     0.00    0.28   0.28   0.00
sdb               0.00     0.00    0.01    0.00     0.11     0.00    10.20     0.00    0.15   0.15   0.00
sdd               0.00     0.00    0.01    0.00     0.11     0.00    10.20     0.00    0.25   0.25   0.00
sde               0.00     0.00    0.01    0.00     0.11     0.00    10.20     0.00    0.14   0.14   0.00
sdf               0.00     0.00    0.01    0.00     0.11     0.00    10.20     0.00    0.14   0.14   0.00
sdg               0.00     0.00    0.01    0.00     0.11     0.00    10.20     0.00    0.23   0.23   0.00
sdh               0.00     0.00    0.01    0.00     0.11     0.00    10.20     0.00    0.25   0.25   0.00
sdi               0.00     0.00    0.01    0.00     0.11     0.00    10.20     0.00    0.14   0.14   0.00

输出参数描述:

rrqms:每秒这个设备相关的读取请求有多少被Merge了(当系统调用需要读取数据的时候,VFS将请求发到各个FS,如果FS发现不同的读取请求读取的是相同Block的数据,FS会将这个请求合并Merge)
wrqm/s:每秒这个设备相关的写入请求有多少被Merge了。
rsec/s:每秒读取的扇区数;
wsec/s:每秒写入的扇区数。
rKB/s:The number of read requests that were issued to the device per second;
wKB/s:The number of write requests that were issued to the device per second;
avgrq-sz:平均请求扇区的大小
avgqu-sz:是平均请求队列的长度。毫无疑问,队列长度越短越好。
await:每一个IO请求的处理的平均时间(单位是微秒毫秒)。这里可以理解为IO的响应时间,一般地系统IO响应时间应该低于5ms,如果大于10ms就比较大了。这个时间包括了队列时间和服务时间,也就是说,一般情况下,await大于svctm,它们的差值越小,则说明队列时间越短,反之差值越大,队列时间越长,说明系统出了问题。
svctm:表示平均每次设备I/O操作的服务时间(以毫秒为单位)。如果svctm的值与await很接近,表示几乎没有I/O等待,磁盘性能很好。如果await的值远高于svctm的值,则表示I/O队列等待太长,系统上运行的应用程序将变慢。
%util: 在统计时间内所有处理IO时间,除以总共统计时间。例如,如果统计间隔1秒,该设备有0.8秒在处理IO,而0.2秒闲置,那么该设备的%util = 0.8/1 = 80%,所以该参数暗示了设备的繁忙程度,一般地,如果该参数是100%表示磁盘设备已经接近满负荷运行了(当然如果是多磁盘,即使%util是100%,因为磁盘的并发能力,所以磁盘使用未必就到了瓶颈)。
时间: 2024-11-09 03:08:04

IO测试工具之fio详解的相关文章

(总结)Web性能压力测试工具之WebBench详解

PS:在运维工作中,压力测试是一项很重要的工作.比如在一个网站上线之前,能承受多大访问量.在大访问量情况下性能怎样,这些数据指标好坏将会直接影响用户体验.但是,在压力测试中存在一个共性,那就是压力测试的结果与实际负载结果不会完全相同,就算压力测试工作做的再好,也不能保证100%和线上性能指标相同.面对这些问题,我们只能尽量去想方设法去模拟.所以,压力测试非常有必要,有了这些数据,我们就能对自己做维护的平台做到心中有数. Webbench是知名的网站压力测试工具,它是由Lionbridge公司(h

Web 性能压力测试工具之 Siege 详解

Siege是一款开源的压力测试工具,设计用于评估WEB应用在压力下的承受能力.可以根据配置对一个WEB站点进行多用户的并发访问,记录每个用户所有请求过程的相应时间,并在一定数量的并发访问下重复进行.siege可以从您选择的预置列表中请求随机的URL.所以siege可用于仿真用户请求负载,而ab则不能.但不要使用siege来执行最高性能基准调校测试,这方面ab就准确很多. Siege官网:http://www.joedog.org/Siege下载:http://www.joedog.org/pub

Web性能压力测试工具之WebBench详解

PS:在运维工作中,压力测试是一项很重要的工作.比如在一个网站上线之前,能承受多大访问量.在大访问量情况下性能怎样,这些数据指标好坏将会直接影响用户体验.但是,在压力测试中存在一个共性,那就是压力测试的结果与实际负载结果不会完全相同,就算压力测试工作做的再好,也不能保证100%和线上性能指标相同.面对这些问题,我们只能尽量去想方设法去模拟.所以,压力测试非常有必要,有了这些数据,我们就能对自己做维护的平台做到心中有数. Webbench是知名的网站压力测试工具,它是由Lionbridge公司(h

JMeter测试工具.jmx文件详解

摘要:了解.jmx文件格式类型,对jmeter二次开发与拓展有很大的帮助,当然也可以利用python对其进行一些处理(生成一些测试用例,对jmx文件进行 ”增删改查“). 一个完整用例的.jmx文件基本结构是这样,类似于xml结构(树状结构)(文章标红处 均是 可以修改的 地方(也可以说就是一个可控变量)): python 处理xml文件的模块,bs4 , xml.dom: 下面按结构自上而下讲解各个部分再.jmx文件中的表示: 测试计划  root <TestPlan guiclass="

第130讲:Hadoop集群管理工具DataBlockScanner 实战详解学习笔记

第130讲:Hadoop集群管理工具DataBlockScanner 实战详解学习笔记 DataBlockScanner在datanode上运行的block扫描器,定期检测当前datanode节点上所有的block,从而在客户端读到有问题的块前及时检测和修复有问题的块. 它有所有维护的块的列表,通过对块的列表依次的扫描,查看是否有校验问题或错误问题,它还有截流机制. 什么叫截流机制?DataBlockScanner扫描时会消耗大量的磁盘带宽,如果占用磁盘带宽太大,会有性能问题.所以它会只占用一小

IO测试工具 - 用于IO测试 ; linux benchmarks

IO测试工具,用于磁盘IO测试,下面进行使用列表进行记录: iozone fio dd ioping iotop iostat bonnie++ crystalDisk Atto as-ssd-benchmark hdtune 文件系统测试工具:https://www.cnblogs.com/xuyaowen/p/filesystem-test-suites.html bench工具:https://github.com/haydenjames/bench-scripts 可用于磁盘IO测试和文

Protobuf 文件生成工具 Prototool 命令详解

Protobuf 文件生成工具 Prototool 命令详解 简介 Prototool 是 Protobuf 文件的生成工具, 目前支持go, php, java, c#, object c 五种语言包的生成. 详情参考Github: https://github.com/uber/prototool docker 方式使用 prototool 工具 使用方式 // prototool 的使用 docker run --rm -v $(pwd):/work "uber/prototool&quo

java io系列12之 BufferedInputStream详解

目录1. BufferedInputStream 介绍2. BufferedInputStream 源码分析(基于jdk1.7.40)3. 示例代码 BufferedInputStream 是缓冲输入流.它继承于FilterInputStream. BufferedInputStream 的作用是为另一个输入流添加一些功能,例如,提供"缓冲功能"以及支持"mark()标记"和"reset()重置方法".BufferedInputStream 本质

从技巧、案例和工具入手,详解性能优化怎么做

颜圣杰,.NET平台软件工程师,对DDD领域驱动设计感兴趣,目前在研究ABP框架,热爱写作与分享. 最近一段时间系统新版本要发布,在beta客户测试期间,暴露了很多问题,除了一些业务和异常问题外,其它都集中在性能上.有幸接触到这些性能调优的机会,这里跟大家归纳交流一下. 性能优化是一个老生常谈的问题了,典型的性能问题如页面响应慢.接口超时,服务器负载高.并发数低,数据库频繁死锁等.而造成性能问题又有很多种,比如磁盘I/O.内存.网络.算法.大数据量等.我们可以大致把性能问题分为四个层次:代码层次