IO mainstream third-party testing tools fio, iometer and Orion, these three tools is different.
fio in the Linux system is convenient, in the window system Iometer convenient, Orion is the oracle IO test software can simulate the scenario read in oracle database without installing oracle database.
As is the use of IO test fio tools to be stored on the SAN on Linux systems.
1, the installation fio
In fio fio-2.1.10.tar official website to download the file, you can use the fio after ./configure,make,make install unpacked.
2, fio of parameters
FIO tool method:
Parameters:
filename = / dev / sdb1 test file name, the disc to be tested is typically selected data directory.
testing direct = 1 bypass machine comes buffer. This The test results are more realistic.
rw = randwrite random write test of the I / O
RW = random randrw test writing and reading the I / O
BS = 16K block io single file size of 16K
bsrange = 512-2048 supra, mention the predetermined size range of the data block
size = 5g of this test file size 5g, io test to each of 4k.
numjobs = 30 threads of this test is 30. The
Runtime = 1000 test time of 1000 seconds, if you do not have to write the document of 5g 4k each finished so far.
ioengine = psync io engines pync way
rwmixwrite = 30 in a mixed read-write mode, write% accounted for 30
group_reporting, summary information about each process displaying results.
Further
lockmem = 1g used only for testing memory 1g.
0 zero_buffers initialize the system with buffer.
nrfiles = 8 Number of each process generated files.
Common disk read and write test point:
1. the Read Ramdon = 100% = 100% RW = randread (100% Random Read)
2. the Read Sequence = 100% = 100% RW = Read (100% sequential read)
3. Write = 100% Sequence = 100 % rw = write (100% sequential write)
4. Ramdon the Write = 100% = 100% RW = randwrite (100% random write)
5. The 70% = the Read Sequence = RW = 100% RW, rwmixread = 70, rwmixwrite = 30
(70% sequential read, write order 30%)
6. The Ramdon the read = 70% = 100% RW = randrw, rwmixread = 70, rwmixwrite = 30
(70% of those randomized read, random 30% write)
1) sequential write:
description: / sda partition file size memory block with 2M 1100GB sequential write to the file / dev
fio -output=/tmp/100S100W -name=100S100W -filename=/dev/sda -ioengine=libaio -direct=1 -blocksize=2M -size=1100GB -rw=write -iodepth=8 -numjobs=1
2) Random Write:
Description: to / dev / 2M block partition file size stored random write 1100GB file sda
fio -output=/tmp/100R100W -name=100R100W -filename=/dev/sdb:/dev/sdc:/dev/sdd -ioengine=libaio -direct=1 -blocksize=2M -size=3356GB -rw=randwrite -iodepth=8 -numjobs=1
3) sequential read:
fio -output=/tmp/100S100W -name=100S100W -filename=/dev/sda -ioengine=libaio -direct=1 -blocksize=2M –runtime=1800 -rw=read -iodepth=8 -numjobs=1
4) Random Read:
fio -output=/tmp/100S100Wsdbsdcsdd -name=100S100W -write_bw_log=bw_log -write_lat_log=lat_log -filename=/dev/sdb:/dev/sdc:/dev/sdd -ioengine=libaio -direct=1 -blocksize=2M -runtime=1800 -rw=randread -iodepth=32 -numjobs=1
5) mixing Random Access:
Description: 70% of the random read, random write 30%, with 2M block size to the file / dev / sdb: / dev / sdc: / dev / sdd three partitions the random access time memory 300s
fio -output=/tmp/100S100W -name=100S100W -filename=/dev/sdb:/dev/sdc:/dev/sdd -ioengine=libaio -direct=1 -blocksize=2M -runtime=300 -rw=randrw -rwmixread=70 -rwmixwrite=30 -iodepth=32 -numjobs=1
View the results report:
[root@rac01-node02]# fio -filename=/dev/sdc4 -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_local
randrw_70read_4k_local: (g = 0): rw = randrw, bs = 4K-4K / 4K-4K / 4K-4K, ioengine = psync, iodepth = 1
...
fio-2.1.10
Starting 50 threads
Jobs: 21 (f=21): [____m____m_m___m____mmm__mmm__mm_m_mmm_m__m__m_m_m] [3.4% done] [7004KB/2768KB/0KB /s] [1751/692/0 iops] [eta 01h:27m:00s]
randrw_70read_4k_local: (groupid=0, jobs=50): err= 0: pid=13710: Wed May 31 10:23:31 2017
read : io=1394.2MB, bw=7926.4KB/s, iops=1981, runt=180113msec
clat (usec): min=39, max=567873, avg=24323.79, stdev=25645.98
years (usec): = min 39, max = 567,874, avg = 24324.23, stdev = 25645.98
clat percentiles (msec):
| 1.00th=[ 3], 5.00th=[ 5], 10.00th=[ 6], 20.00th=[ 7],
| 30.00th=[ 9], 40.00th=[ 12], 50.00th=[ 16], 60.00th=[ 21],
| 70.00th=[ 27], 80.00th=[ 38], 90.00th=[ 56], 95.00th=[ 75],
| 99.00th=[ 124], 99.50th=[ 147], 99.90th=[ 208], 99.95th=[ 235],
| 99.99th = [314]
bw (KB /s): min= 15, max= 537, per=2.00%, avg=158.68, stdev=38.08
write: io=615280KB, bw=3416.8KB/s, iops=854, runt=180113msec
clat (usec): min=167, max=162537, avg=2054.79, stdev=7665.24
years (usec): min = 167, max = 162,537, avg = 2055.38, stdev = 7665.23
clat percentiles (usec):
| 1.00th=[ 201], 5.00th=[ 227], 10.00th=[ 249], 20.00th=[ 378],
| 30.00th=[ 548], 40.00th=[ 692], 50.00th=[ 844], 60.00th=[ 996],
| 70.00th=[ 1160], 80.00th=[ 1304], 90.00th=[ 1720], 95.00th=[ 3856],
| 99.00th=[40192], 99.50th=[58624], 99.90th=[98816], 99.95th=[123392],
| 99.99th = [148480]
bw (KB /s): min= 6, max= 251, per=2.00%, avg=68.16, stdev=29.18
years (usec): 50 = 0.01% = 0.03 100% 3.15 = 250% 5.00 = 500% 5.09 = 750%
years (usec): 1000 = 4.87%
years (msec) 2 = 9.64% 4.06% 4 = 10 = 21.42%, 18.08% 20 = 50 = 19.91%
years (msec): 7.24 = 100% 1.47 = 250% 0.03 = 500% 0.01 = 750%
cpu : usr=0.07%, sys=0.21%, ctx=522490, majf=0, minf=7
IO depths : 1=100.0%, 2=0.0%, 4=0.0%, 8=0.0%, 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=100.0%, 8=0.0%, 16=0.0%, 32=0.0%, 64=0.0%, >=64=0.0%
issued : total=r=356911/w=153820/d=0, short=r=0/w=0/d=0
latency : target=0, window=0, percentile=100.00%, depth=1
Run status group 0 (all jobs):
READ: io=1394.2MB, aggrb=7926KB/s, minb=7926KB/s, maxb=7926KB/s, mint=180113msec, maxt=180113msec
WRITE: io=615280KB, aggrb=3416KB/s, minb=3416KB/s, maxb=3416KB/s, mint=180113msec, maxt=180113msec
Disk stats (read/write):
sdc: ios=356874/153927, merge=0/10, ticks=8668598/310288, in_queue=8978582, util=99.99%
io = IO implementation of the number of M
The average IO bandwidth bw =
IOPS = IOPS
of runt threads run time =
slat = submitted delay
clat = complete delay
lat = response time
bw = bandwidth of
cpu = utilization
IO depths = io queue
IO submit = submit individual IO IO number to submit
IO Complete the above Submit Like Number =, But Completions for INSTEAD.
the IO of the Issued = Number of Read / Write Requests Issued, and were Them How MANY of Short.
the IO latencies from the delayed distribution of the IO =
io = total number of executed IO size of
aggrb = group total bandwidth
minb = minimum average of bandwidth.
maxB = maximum average bandwidth.
Mint = minimum run time in the thread group.
MaxT = maximum uptime in the thread group.
ios = group total number of all IO performed.
Merge = total combined number of IO occur.
ticks of ticks WE = Number The Disk Kept The BUSY.
io_queue = total spent on the queue time.
util = disk utilization
4, the IO expansion queue depth
At some point, there are N inflight IO requests, including an IO request in the queue, the disk IO request being processed. N is the queue depth.
Increase the hard disk queue depth is to make the hard disk constantly working hard to reduce idle time.
Increasing queue depth -> increase utilization -> obtained peak IOPS and MBPS -> Note that the response time is within an acceptable range,
increasing queue depth there are many approaches, using asynchronous IO, while initiating a plurality of IO requests, corresponding to queue there are multiple IO requests, initiate synchronous multi-threaded IO requests, equivalent to queue multiple IO requests.
Increasing the size of the application IO, after reaching the bottom, will become more IO requests, a queue corresponding to a plurality of IO requests queue depth increases.
Queue depth increases, IO wait time in the queue will increase, leading to larger IO response time, which requires trade-offs.
Why on disk I / O parallel processing it? The main purpose is to enhance application performance. This is more than physical disks to a virtual disk (or LUN) is very important.
If a commit I / O, while a shorter response time, but the throughput of the system is very small.
In comparison, a submit multiple I / O which shortens the movement distance of the head (by lift algorithm), but also to enhance IOPS.
If a lift can only take one person, but then everyone a ride on the elevator, you can quickly reach the destination (response time), but it takes a long time to wait (queue length).
Thus submission to the plurality of disk system I / O throughput and to balance the overall response time.
Linux system view the default queue depth:
Monitor disk IO command: iostat -mx 1 (iostat installation method: yum install sysstat)
[root@localhost tmp]# iostat -mx 1 Linux 2.6.32-220.el6.x86_64 (localhost.localdomain) XXXX XX, XX years _x86_64_ (32 CPU) avg-cpu: %user %nice %system %iowait %steal %idle 12.74 0.00 8.95 0.04 0.00 78.27 Device: rrqm/s wrqm/s r/s w/s rMB/s wMB/s avgrq-sz avgqu-sz await svctm %util sda 0.18 10.05 0.31 7.67 0.01 0.07 18.77 0.00 0.28 0.14 0.11 sdb 0.69 0.10 15.74 11.21 0.17 2.45 190.77 0.34 12.10 0.23 0.63
rrqms: the device associated with the read requests per second is the number of the Merge (when the system call requires the read data, VFS requests sent to each FS, FS if found different read requests to read is the same as the Block data, FS will request the merge combined) wrqm / s: the device associated with the write requests per second is the number of the Merge. rsec/s：The number of sectors read from the device per second. wsec/s：The number of sectors written to the device per second. rKB/s：The number of kilobytes read from the device per second. wKB/s：The number of kilobytes written to the device per second. avgrq-sz: average request sector size, The average size (in sectors) of the requests that were issued to the device. avgqu-sz: it is the average length of the request queue. There is no doubt queue length as short as possible, The average queue length of the requests that were issued to the device. await: the average processing time for each IO request (in milliseconds, microseconds). Here it will be appreciated that the response time of IO, IO response time of the system in general should be less than 5ms, 10ms is greater than if relatively large.
This time includes the time and queue service time, that is to say, in general, larger than the await the svctm, the smaller the difference between them, then the queue shorter time, whereas the greater the difference, the longer the time the queue, the system described the problem. svctm: represents the average duration of the service device I / O operations (in milliseconds). If svctm value and await very close, represents almost no I / O wait, very good disk performance.
If the value is much higher than the value await svctm of said I / O queue waiting too long, the application running on the system will be slower. % util: in all IO processing time within the time, divided by the total time statistics. For example, if the statistical interval of 1 second, the device has 0.8 seconds processing the IO, the 0.2 seconds of idle, then% util the device = 0.8 / 1 = 80%,
so the parameter implies busy apparatus, generally, if this parameter is 100% indicates that the disk device has been close to running at full capacity (of course, if multiple disks, even if% util is 100% because concurrency disk, so disk usage not necessarily to the bottleneck)