Linux Command fio测试磁盘io工具

简介: Linux Command fio测试磁盘io工具

Linux Command fio测试磁盘io工具

文章目录

1. 简介

FIO是测试IOPS的非常好的工具,用来对磁盘进行压力测试和验证。磁盘IO是检查磁盘性能的重要指标,可以按照负载情况分成照顺序读写,随机读写两大类。FIO是一个可以产生很多线程或进程并执行用户指定的特定类型I/O操作的工具,FIO的典型用途是编写和模拟的I/O负载匹配的作业文件。也就是说FIO 是一个多线程io生成工具,可以生成多种IO模式,用来测试磁盘设备的性能(也包含文件系统:如针对网络文件系统 NFS 的IO测试)。

2. 参数

filename=/dev/sdb1 测试文件名称,通常选择需要测试的盘的data目录。
direct=1 是否使用directIO,测试过程绕过OS自带的buffer,使测试磁盘的结果更真实。Linux读写的时候,内核维护了缓存,数据先写到缓存,后面再后台写到SSD。读的时候也优先读缓存里的数据。这样速度可以加快,但是一旦掉电缓存里的数据就没了。所以有一种模式叫做DirectIO,跳过缓存,直接读写SSD。 
rw=randwrite 测试随机写的I/O
rw=randrw 测试随机写和读的I/O
bs=16k 单次io的块文件大小为16k
bsrange=512-2048 同上,提定数据块的大小范围
size=5G 每个线程读写的数据量是5GB。
numjobs=1 每个job(任务)开1个线程,这里用了几,后面每个用-name指定的任务就开几个线程测试。所以最终线程数=任务数(几个name=jobx)* numjobs。 
name=job1:一个任务的名字,重复了也没关系。如果fio -name=job1 -name=job2,建立了两个任务,共享-name=job1之前的参数。-name之后的就是job2任务独有的参数。 
thread  使用pthread_create创建线程,另一种是fork创建进程。进程的开销比线程要大,一般都采用thread测试。 
runtime=1000 测试时间为1000秒,如果不写则一直将5g文件分4k每次写完为止。
ioengine=libaio 指定io引擎使用libaio方式。libaio:Linux本地异步I/O。请注意,Linux可能只支持具有非缓冲I/O的排队行为(设置为“direct=1”或“buffered=0”);rbd:通过librbd直接访问CEPH Rados 
iodepth=16 队列的深度为16.在异步模式下,CPU不能一直无限的发命令到SSD。比如SSD执行读写如果发生了卡顿,那有可能系统会一直不停的发命令,几千个,甚至几万个,这样一方面SSD扛不住,另一方面这么多命令会很占内存,系统也要挂掉了。这样,就带来一个参数叫做队列深度。
Block Devices(RBD),无需使用内核RBD驱动程序(rbd.ko)。该参数包含很多ioengine,如:libhdfs/rdma等
rwmixwrite=30 在混合读写的模式下,写占30%
group_reporting 关于显示结果的,汇总每个进程的信息。
此外
lockmem=1g 只使用1g内存进行测试。
zero_buffers 用0初始化系统buffer。
nrfiles=8 每个进程生成文件的数量。
磁盘读写常用测试点:
1. Read=100% Ramdon=100% rw=randread (100%随机读)
2. Read=100% Sequence=100% rw=read (100%顺序读)
3. Write=100% Sequence=100% rw=write (100%顺序写)
4. Write=100% Ramdon=100% rw=randwrite (100%随机写)
5. Read=70% Sequence=100% rw=rw, rwmixread=70, rwmixwrite=30
(70%顺序读,30%顺序写)
6. Read=70% Ramdon=100% rw=randrw, rwmixread=70, rwmixwrite=30
(70%随机读,30%随机写)

3. 示例

[root@docker sda]# fio -ioengine=libaio -bs=4k -direct=1 -thread -rw=read -filename=/dev/sda -name="BS 4KB read test" -iodepth=16 -runtime=60
BS 4KB read test: (g=0): rw=read, bs=(R) 4096B-4096B, (W) 4096B-4096B, (T) 4096B-4096B, ioengine=libaio, iodepth=16
fio-3.7
Starting 1 thread
Jobs: 1 (f=1): [R(1)][100.0%][r=89.3MiB/s,w=0KiB/s][r=22.9k,w=0 IOPS][eta 00m:00s]
BS 4KB read test: (groupid=0, jobs=1): err= 0: pid=18557: Thu Apr 11 13:08:11 2019
   read: IOPS=22.7k, BW=88.5MiB/s (92.8MB/s)(5313MiB/60001msec)
    slat (nsec): min=901, max=168330, avg=6932.34, stdev=1348.82
    clat (usec): min=90, max=63760, avg=698.08, stdev=240.83
     lat (usec): min=97, max=63762, avg=705.17, stdev=240.81
    clat percentiles (usec):
     |  1.00th=[  619],  5.00th=[  627], 10.00th=[  627], 20.00th=[  635],
     | 30.00th=[  635], 40.00th=[  685], 50.00th=[  717], 60.00th=[  725],
     | 70.00th=[  725], 80.00th=[  725], 90.00th=[  734], 95.00th=[  816],
     | 99.00th=[ 1004], 99.50th=[ 1020], 99.90th=[ 1057], 99.95th=[ 1057],
     | 99.99th=[ 1860]
   bw (  KiB/s): min=62144, max=91552, per=100.00%, avg=90669.02, stdev=3533.77, samples=120
   iops        : min=15536, max=22888, avg=22667.27, stdev=883.44, samples=120
  lat (usec)   : 100=0.01%, 250=0.01%, 500=0.01%, 750=93.85%, 1000=5.14%
  lat (msec)   : 2=0.99%, 4=0.01%, 10=0.01%, 50=0.01%, 100=0.01%
  cpu          : usr=5.35%, sys=23.17%, ctx=1359692, majf=0, minf=17
  IO depths    : 1=0.1%, 2=0.1%, 4=0.1%, 8=0.1%, 16=100.0%, 32=0.0%, >=64=0.0%
     submit    : 0=0.0%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.0%, 64=0.0%, >=64=0.0%
     complete  : 0=0.0%, 4=100.0%, 8=0.0%, 16=0.1%, 32=0.0%, 64=0.0%, >=64=0.0%
     issued rwts: total=1360097,0,0,0 short=0,0,0,0 dropped=0,0,0,0
     latency   : target=0, window=0, percentile=100.00%, depth=16
 - List item
Run status group 0 (all jobs):
   READ: bw=88.5MiB/s (92.8MB/s), 88.5MiB/s-88.5MiB/s (92.8MB/s-92.8MB/s), io=5313MiB (5571MB), run=60001-60001msec
Disk stats (read/write):
  sda: ios=1357472/0, merge=70/0, ticks=949141/0, in_queue=948776, util=99.88%

io=执行了多少M的IO

bw=平均IO带宽

iops=IOPS

runt=线程运行时间

slat=提交延迟,提交该IO请求到kernel所花的时间(不包括kernel处理的时间)

clat=完成延迟, 提交该IO请求到kernel后,处理所花的时间

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=磁盘利用率

更多阅读:


fio(1) - Linux man page

fio - Flexible I/O tester rev. 3.30

Sample FIO Commands for Block Volume Performance Tests on Linux-based Instances


相关文章
|
23天前
|
Ubuntu Linux Shell
Linux系统中如何查看磁盘情况
【9月更文挑战第3天】在Linux系统中,有多种方式查看磁盘情况。可通过命令行工具`df`查看文件系统磁盘使用情况,选项`-h`以人类可读格式显示,`-T`显示文件系统类型;`du`命令显示目录或文件磁盘使用情况,`-h`以人类可读格式显示,`-s`仅显示总计;`fdisk -l`列出磁盘和分区信息。此外,图形界面的磁盘管理工具和文件管理器也可用于查看磁盘使用情况。这些方法有助于更好地管理磁盘空间。
|
19小时前
|
存储 Linux 5G
Linux 基于 LVM 逻辑卷的磁盘管理【简明教程】
这篇文章介绍了LVM(逻辑卷管理)如何提供灵活的磁盘管理方式,允许动态调整逻辑卷的大小而不会丢失数据。
Linux 基于 LVM 逻辑卷的磁盘管理【简明教程】
|
9天前
|
测试技术
基于LangChain手工测试用例转App自动化测试生成工具
在传统App自动化测试中,测试工程师需手动将功能测试用例转化为自动化用例。市面上多数产品通过录制操作生成测试用例,但可维护性差。本文探讨了利用大模型直接生成自动化测试用例的可能性,介绍了如何使用LangChain将功能测试用例转换为App自动化测试用例,大幅节省人力与资源。通过封装App底层工具并与大模型结合,记录执行步骤并生成自动化测试代码,最终实现高效自动化的测试流程。
24 4
|
26天前
|
监控 安全 Linux
如何利用Kali Linux进行网站渗透测试:最常用工具详解
如何利用Kali Linux进行网站渗透测试:最常用工具详解
65 6
|
26天前
|
安全 Linux 测试技术
Kali Linux预装的自动化渗透测试工具
Kali Linux预装的自动化渗透测试工具
39 2
|
29天前
|
测试技术
基于LangChain手工测试用例转Web自动化测试生成工具
该方案探索了利用大模型自动生成Web自动化测试用例的方法,替代传统的手动编写或录制方式。通过清晰定义功能测试步骤,结合LangChain的Agent和工具包,实现了从功能测试到自动化测试的转换,极大提升了效率。不仅减少了人工干预,还提高了测试用例的可维护性和实用性。
41 4
|
1月前
|
消息中间件 Kafka 测试技术
【Azure 事件中心】使用Kafka的性能测试工具(kafka-producer-perf-test)测试生产者发送消息到Azure Event Hub的性能
【Azure 事件中心】使用Kafka的性能测试工具(kafka-producer-perf-test)测试生产者发送消息到Azure Event Hub的性能
|
1月前
|
存储 监控 Linux
|
15天前
|
移动开发 JSON Java
Jmeter实现WebSocket协议的接口测试方法
WebSocket协议是HTML5的一种新协议,实现了浏览器与服务器之间的全双工通信。通过简单的握手动作,双方可直接传输数据。其优势包括极小的头部开销和服务器推送功能。使用JMeter进行WebSocket接口和性能测试时,需安装特定插件并配置相关参数,如服务器地址、端口号等,还可通过CSV文件实现参数化,以满足不同测试需求。
77 7
Jmeter实现WebSocket协议的接口测试方法
|
15天前
|
JSON 移动开发 监控
快速上手|HTTP 接口功能自动化测试
HTTP接口功能测试对于确保Web应用和H5应用的数据正确性至关重要。这类测试主要针对后台HTTP接口,通过构造不同参数输入值并获取JSON格式的输出结果来进行验证。HTTP协议基于TCP连接,包括请求与响应模式。请求由请求行、消息报头和请求正文组成,响应则包含状态行、消息报头及响应正文。常用的请求方法有GET、POST等,而响应状态码如2xx代表成功。测试过程使用Python语言和pycurl模块调用接口,并通过断言机制比对实际与预期结果,确保功能正确性。
75 3
快速上手|HTTP 接口功能自动化测试