【测试】linux FIO命令详解(一):磁盘IO测试工具 fio (并简要介绍iostat工具) |
您所在的位置:网站首页 › 硬盘测试机怎么看数据 › 【测试】linux FIO命令详解(一):磁盘IO测试工具 fio (并简要介绍iostat工具) |
目录 随看随用 FIO介绍 FIO 工具常用参数: fio工作参数可以写入配置文件 IO状态监控: Iostat介绍 与FIO相似的工具 fio测试脚本 提取iops和bw gunplot画图 Fio 输出内容的解释 随看随用FIO用法: 随机读:(可直接用,向磁盘写一个2G文件,10线程,随机读1分钟,给出结果) 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 说明: 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每次写完为止 time_based: 如果在runtime指定的时间还没到时文件就被读写完成,将继续重复直到runtime时间结束。 ioengine=psync io引擎使用pync方式,如果要使用libaio引擎,需要yum install libaio-devel包 rwmixwrite=30 在混合读写的模式下,写占30% group_reporting 关于显示结果的,汇总每个进程的信息 此外 lockmem=1g 只使用1g内存进行测试 zero_buffers 用0初始化系统buffer nrfiles=8 每个进程生成文件的数量read 顺序读 write 顺序写 rw,readwrite 顺序混合读写 randwrite 随机写 randread 随机读 randrw 随机混合读写 io总的输入输出量 bw:带宽 KB/s iops:每秒钟的IO数 runt:总运行时间 lat (msec):延迟(毫秒) msec: 毫秒 usec: 微秒 顺序读: fio -filename=/dev/sdb1 -direct=1 -iodepth 1 -thread -rw=read -ioengine=psync -bs=16k -size=2G -numjobs=10 -runtime=60 -group_reporting -name=mytest 随机写: fio -filename=/dev/sdb1 -direct=1 -iodepth 1 -thread -rw=randwrite -ioengine=psync -bs=16k -size=2G -numjobs=10 -runtime=60 -group_reporting -name=mytest 顺序写: fio -filename=/dev/sdb1 -direct=1 -iodepth 1 -thread -rw=write -ioengine=psync -bs=16k -size=2G -numjobs=10 -runtime=60 -group_reporting -name=mytest 混合随机读写: fio -filename=/dev/sdb1 -direct=1 -iodepth 1 -thread -rw=randrw -rwmixread=70 -ioengine=psync -bs=16k -size=2G -numjobs=10 -runtime=60 -group_reporting -name=mytest -ioscheduler=noop 原文:https://blog.csdn.net/don_chiang709/article/details/92628623 FIO介绍FIO是测试IOPS的非常好的工具,用来对磁盘进行压力测试和验证。磁盘IO是检查磁盘性能的重要指标,可以按照负载情况分成照顺序读写,随机读写两大类。 FIO是一个可以产生很多线程或进程并执行用户指定的特定类型I/O操作的工具,IO 是一个多线程io生成工具,可以生成多种IO模式,用来测试磁盘设备的性能(也包含文件系统:如针对网络文件系统 NFS 的IO测试)。 fio在github上的坐标:https://github.com/axboe/fio 。 查看当前 fio 已支持的 IO 引擎 # fio --enghelp Available IO engines: cpuio mmap sync psync vsync pvsync null net netsplice libaio rdma posixaio falloc e4defrag splice rbd mtd sg binject FIO 工具常用参数:参数说明: filename=/dev/sdb1 测试文件名称,通常选择需要测试的盘的data目录。direct=1 是否使用directIO,测试过程绕过OS自带的buffer,使测试磁盘的结果更真实。Linux读写的时候,内核维护了缓存,数据先写到缓存,后面再后台写到SSD。读的时候也优先读缓存里的数据。这样速度可以加快,但是一旦掉电缓存里的数据就没了。所以有一种模式叫做DirectIO,跳过缓存,直接读写SSD。 rw=randwrite 测试随机写的I/Orw=randrw 测试随机写和读的I/O bs=16k 单次io的块文件大小为16kbsrange=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测试。fio默认会使用fork()创建job,如果这个选项设置的话,fio将使用pthread_create来创建线程。 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 如果‘numjobs’设置的话,我们感兴趣的可能是打印group的统计值,而不是一个单独的job。这在‘numjobs’的值很大时,一般是设置为true的,可以减少输出的信息量。如果‘group_reporting’设置的话,fio将会显示最终的per-groupreport而不是每一个job都会显示。 此外lockmem=1g 只使用1g内存进行测试。zero_buffers 用0初始化系统buffer。nrfiles=8 每个进程生成文件的数量。 a.loops=int 重复运行某个job多次,默认是1。 loops与runtime是两个不能同时存在的两个参数,loops主要是定义硬盘执行的圈数,而runtime只是定义fio执行的时间。b.time_based 如果设置的话,即使file已被完全读写或写完,也要执行完runtime规定的时间。它是通过循环执行相同的负载来实现的,与runtime相对应。c.ramp_time=time 设定在记录任何性能信息之前要运行特定负载的时间。这个用来等性能稳定后,再记录日志结果,因此可以减少生成稳定的结果需要的运行时间。d.randrepeat=bool 对于随机IO负载,配置生成器的种子,使得路径是可以预估的,使得每次重复执行生成的序列是一样的。 磁盘读写常用测试点: 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%随机写) fio例子: fio --ioengine=rbd --iodepth=10 --numjobs=1 --pool=.rbdpool.rbd --rbdname=lun14 --name=write5 --rw=randwrite --bs=1M --size=6G --group_reporting --direct=1& [root@rdma63 hsx]# write5: (g=0): rw=randwrite, bs=1M-1M/1M-1M/1M-1M, ioengine=rbd, iodepth=10 fio-2.2.10 Starting 1 process rbd engine: RBD version: 1.12.0 Jobs: 1 (f=0): [w(1)] [100.0% done] [0KB/109.3MB/0KB /s] [0/109/0 iops] [eta 00m:00s] write5: (groupid=0, jobs=1): err= 0: pid=4074401: Wed Jan 27 10:17:15 2021 write: io=6144.0MB, bw=108918KB/s, iops=106, runt= 57763msecslat (usec): min=254, max=20470, avg=512.86, stdev=635.57clat (msec): min=14, max=273, avg=91.68, stdev=32.76lat (msec): min=15, max=274, avg=92.20, stdev=32.76clat percentiles (msec): | 1.00th=[ 37], 5.00th=[ 49], 10.00th=[ 55], 20.00th=[ 64], | 30.00th=[ 71], 40.00th=[ 79], 50.00th=[ 87], 60.00th=[ 95], | 70.00th=[ 106], 80.00th=[ 121], 90.00th=[ 139], 95.00th=[ 151], | 99.00th=[ 182], 99.50th=[ 194], 99.90th=[ 233], 99.95th=[ 269], | 99.99th=[ 273] bw (KB /s): min=58810, max=138686, per=100.00%, avg=109173.18, stdev=10441.08 lat (msec) : 20=0.03%, 50=6.04%, 100=58.74%, 250=35.11%, 500=0.08% cpu : usr=4.28%, sys=1.12%, ctx=920, majf=0, minf=272282 IO depths : 1=2.9%, 2=12.6%, 4=43.1%, 8=41.5%, 16=0.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=90.1%, 8=5.5%, 16=4.5%, 32=0.0%, 64=0.0%, >=64=0.0% issued : total=r=0/w=6144/d=0, short=r=0/w=0/d=0, drop=r=0/w=0/d=0 latency : target=0, window=0, percentile=100.00%, depth=10 Run status group 0 (all jobs): WRITE: io=6144.0MB, aggrb=108918KB/s, minb=108918KB/s, maxb=108918KB/s, mint=57763msec, maxt=57763msec Disk stats (read/write): sdq: ios=0/1805, merge=0/52, ticks=0/77, in_queue=76, util=0.11% bw=平均IO带宽 io=执行了多少M的IOiops=IOPSrunt=线程运行时间 slat=提交延迟,提交该IO请求到kernel所花的时间(不包括kernel处理的时间)clat=完成延迟, 提交该IO请求到kernel后,处理所花的时间lat=响应时间 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完延迟的分布 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 有很多测试任务配置文件,在git工程 examples 文件夹中,我们可以使用命令行参数进行直接配置,也可以直接通过配置文件配置一次测试的内容。 更详细对fio输出说明请参考博文:Fio Output Explained [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 //提交延迟,提交该IO请求到kernel所花的时间(不包括kernel处理的时间) clat (usec): min=90, max=63760, avg=698.08, stdev=240.83 //完成延迟, 提交该IO请求到kernel后,处理所花的时间 (stdev:标准差) lat (usec): min=97, max=63762, avg=705.17, stdev=240.81 //响应时间 clat percentiles (usec): //clat (提交延时)的排名分布 | 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=120iops : min=15536, max=22888, avg=22667.27, stdev=883.44, samples=120lat (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% //IO depths=io队列submit : 0=0.0%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.0%, 64=0.0%, >=64=0.0% //单个IO提交要提交的IO数complete : 0=0.0%, 4=100.0%, 8=0.0%, 16=0.1%, 32=0.0%, 64=0.0%, >=64=0.0% //Like the above submit number, but for completions instead.issued rwts: total=1360097,0,0,0 short=0,0,0,0 dropped=0,0,0,0 //The number of read/write requests issued, and how many of them were short.latency : target=0, window=0, percentile=100.00%, depth=16 //IO完延迟的分布 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%(磁盘利用率) fio工作参数可以写入配置文件http://xiaqunfeng.cc/2017/07/12/fio-test-ceph/ 测试librbd 1、创建一个image rbd -p rbd create --size 2048 fio_test 2、撰写 job file:rbd.fio ###################################################################### # Example test for the RBD engine. # # Runs a 4k random write test agains a RBD via librbd # # NOTE: Make sure you have either a RBD named 'fio_test' or change # the rbdname parameter. ###################################################################### [global] #logging #write_iops_log=write_iops_log #write_bw_log=write_bw_log #write_lat_log=write_lat_log ioengine=rbd clientname=admin pool=rbd rbdname=fio_test invalidate=0 # mandatory rw=randwrite bs=4k [rbd_iodepth32] iodepth=32以上 job file 将执行整个RBD大小的100%随机写入测试(将通过librbd确定),Ceph用户 admin 使用Ceph 默认 pool rbd和刚刚创建的空的 RBD fio_test,写的 blocksize 为 4k 和 iodepth 为32 。 引擎正在使用异步IO。 当前实施限制: invalidate = 0 现在是强制需要的,engine 现在没有这个会返回失败。测试完成后 rbd 引擎不会被清除。完成测试运行后,给定的RBD将被填充。(我们现在使用它进行预填充测试,并在需要时重新创建RBD。)部分参考:Ceph Performance Analysis: fio and RBD 3、测试 fio rbd.fio IO状态监控:进行磁盘测试的时候,我们可以使用iostat 等监控工具,查看所有磁盘当前的读写状态(fedora 系统上 sysstat-11.7.3-2.fc29.x86_64 收录了此工具)。 监控磁盘IO命令:iostat –mx 1 Iostat介绍iostat主要用于监控系统设备的IO负载情况,iostat首次运行时显示自系统启动开始的各项统计信息,之后运行iostat将显示自上次运行该命令以后的统计信息。用户可以通过指定统计的次数和时间来获得所需的统计信息。 语法 iostat [ -c ] [ -d ] [ -h ] [ -N ] [ -k | -m ] [ -t ] [ -V ] [ -x ] [ -z ] [ device [...] | ALL ] [ -p [ device [,...] | ALL ] ] [ interval [ count ] ] iostat使用范例: iostat -d -x -k 1 10 Device: rrqm/s wrqm/s r/s w/s rsec/s wsec/s rkB/s wkB/s avgrq-sz avgqu-sz await svctm %util sda 1.56 28.31 7.80 31.49 42.51 2.92 21.26 1.46 1.16 0.03 0.79 2.62 10.28 Device: rrqm/s wrqm/s r/s w/s rsec/s wsec/s rkB/s wkB/s avgrq-sz avgqu-sz await svctm %util sda 2.00 20.00 381.00 7.00 12320.00 216.00 6160.00 108.00 32.31 1.75 4.50 2.17 84.20 -d: 显示该设备的状态的参数; -x:是一个比较常用的选项,该选项将用于显示和io相关的扩展数据。 -k: 静态显示每秒的统计(单位kilobytes ) 1: 第一个数字表示每隔1秒刷新一次数据显示。 10:第二个数字表示总共的刷新次数 输出信息的含义 rrqm/s:每秒这个设备相关的读取请求有多少被Merge了(当系统调用需要读取数据的时候,VFS将请求发到各个FS,如果FS发现不同的读取请求读取的是相同Block的数据,FS会将这个请求合并Merge); wrqm/s:每秒这个设备相关的写入请求有多少被Merge了。 r/s: 该设备的每秒完成的读请求数(merge合并之后的) w/s: 该设备的每秒完成的写请求数(merge合并之后的) rsec/s:每秒读取的扇区数; wsec/:每秒写入的扇区数。 rKB/s:每秒发送给该设备的总读请求数 wKB/s:每秒发送给该设备的总写请求数 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%,因为磁盘的并发能力,所以磁盘使用未必就到了瓶颈)。 参考: linux 磁盘IO测试工具:FIO (同时简要介绍dd工具测试) Linux IO实时监控iostat命令详解 SSD测试第一神器——FIO 与FIO相似的工具vdbench 、mdtest、dd fio测试脚本 #!/bin/bash set -e ioengine="libaio" iodepth=128 direct=1 fsync=1 runtime=600 size="10G" mntdir="/mnt/fio-data/" mkdir -p /mnt/fio-data mount /dev/vdb /mnt/fio-data || true for m in seq rand do prefix="" if [ "$m" == "seq" ] ; then bs="1024K" else bs="4K" prefix="rand" fi for op in read write do cat /dev/null 2>&1|| true echo "test case: $c" outdir=`pwd`/result-`date "+%Y%m%d%H%M"` mkdir -p $outdir for p in `ls -1 $mntdir/*.fio` do f=`basename $p` echo 3 > /proc/sys/vm/drop_caches cmd="docker run --name=$f -v $mntdir:/tmp/fio-data -e JOBFILES=/tmp/fio-data/$f \ clusterhq/fiotools-aio bash /opt/run.sh \ | tee -a $outdir/$f.log" echo $cmd eval $cmd sleep 1 done 提取iops和bw #!/usr/bin/python2.7 import os import re from pathlib import Path def get_perf(file, type, perf): m = re.compile('\s*{}\s*: .* {}=(\d+)'.format(type, perf)) with open(file) as f: for line in f.readlines(): g = m.search(line) if g is not None and len(g.groups()) == 1: return g.groups()[0] raise Exception("{} {} not found".format(type, perf)) def parse(dir, perf): data = [] perf_type = 'rand' if perf == 'iops' else 'seq' dirs = Path(dir).glob('result-*/') for d in dirs: f = os.path.join(d.name, 'fio-%s-read.fio.log' % perf_type) read = get_perf(f, "read", perf) f = os.path.join(d.name, 'fio-%s-write.fio.log' % perf_type) write = get_perf(f, "write", perf) data.append((read, write)) return data if __name__ == '__main__': cwd = os.path.dirname(os.path.realpath(__file__)) data = parse(cwd, "iops") with open("iops.txt", "w") as f: i = 1 for l in data: f.write('{} {} {}\n'.format(i, l[0], l[1])) i = i + 1 data = parse(cwd, "bw") with open("bw.txt", "w") as f: i = 1 for l in data: f.write('{} {} {}\n'.format(i, l[0], l[1])) i = i + 1 gunplot画图 iops #!/bin/bash data=iops.txt pic=iops.png /usr/local/bin/gnuplot =64=0.0%Fio有一个iodepth设置,用来控制同一时刻发送给OS多少个IO。这完全是纯应用层面的行为,和盘的IO queue不是一回事。这里iodepth设成1,所以IO depth在全部时间都是1。 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.0%, 32=0.0%, 64=0.0%, >=64=0.0%通常来说,只有iodepth大于1才需要关注这一部分数据。,submit和complete代表同一时间段内fio发送和已完成的IO数量。对于产生这个输出的垃圾回收测试用例来说,iodepth是默认值1,所以100%的IO在同一时刻发送1次,放在1-4栏位里。 issued : total=r=2621440/w=0/d=0, short=r=0/w=0/d=0发送的IO数量。这里出现了奇怪的现象,因为这是50/50的读写负载,照道理应该有相同数量的write。我猜测把unified_rw_reporting打开是的fio把所有的IO都认为是read。 如果你在直接IO测试是看到了IO值很低,那么可能是出问题了。我在Linux kernel中找到参考说这种现象发生在文件末尾EOL或可能是设备的尾端。 latency : target=0, window=0, percentile=100.00%, depth=1Fio可以配置一个延迟目标值,这个值可以调节吞吐量直到达到预设的延迟目标。我还没有太多深入了解这部分。在基于时间或和容量的测试中,这行通常看起来一样。四个值分别代表预设的latency_target, latency_window, latency_percentile和iodepth。 Run status group 0 (all jobs):Fio支持把不同的测试聚合。例如,我可以用一个配置文件混合包含SSD和HDD,但是设置分组(group)把IO单独汇总。我现在还没涉及这个功能,但未来会用到。 MIXED: io=12497MB, aggrb=42653KB/s, minb=277KB/s, maxb=41711KB/s, mint=300000msec, maxt=300012msec最后,汇总输出吞吐量和时间。 io=表示总共完成的IO数量。在基于时间的测试中这是一个变量,在基于容量的测试中,这个值能匹配size参数。 aggrb是所有进程/设备的汇总带宽。 minb/maxb表示测量到的最小/最大带宽。 mint/maxt表示测试的最短和最长耗时。和io=参数类似,时间值对于基于时间的测试应该能匹配runtime参数,对于基于容量的测试是一个变量。 由于我设置了unified_rw_reporting参数运行测试,所以只看到MIXED一行。如果禁用这个参数,对于读和写会有单独的行。 够简单吧?我未来的几周会花更多的时间研究fio,我会发布更多关于配置,输出和图表代码的例子。 |
今日新闻 |
推荐新闻 |
CopyRight 2018-2019 办公设备维修网 版权所有 豫ICP备15022753号-3 |