View the performance of I/O disks under Linux disks

Iostat View Linux HDD io performance

rrqm/s:The number of read operations per second for the merge. Delta (rmerge)/s
wrqm/s:The number of write operations per second for the merge. Delta (wmerge)/s
r/s:Number of read I/O devices completed per second. Delta (RIO)/s
w/s:Number of write I/O devices completed per second. Delta (WIO)/s
rsec/s:Number of Read sectors per second. Delta (rsect)/s
wsec/s:Number of write sectors per second. Delta (wsect)/s
rkb/s:The number of K bytes read per second. is half the rsect/s because the size of each sector is 512 bytes. (Calculation required)
wkb/s:Writes the number of K bytes per second. is half the wsect/s. (Calculation required)
Avgrq-sz:The average data size (sector) for each device I/O operation. Delta (rsect+wsect)/delta (Rio+wio)
Avgqu-sz:Average I/O queue length. That is Delta (AVEQ)/s/1000 (because the Aveq is in milliseconds).
await:The average wait time (in milliseconds) for each device I/O operation. Delta (ruse+wuse)/delta (Rio+wio)
SVCTM:The average service time (in milliseconds) per device I/O operation. Delta (use)/delta (RIO+WIO)
%util:How much time in a second is spent on I/O operations, or how many times in a second I/O queues are non-empty. That is, the delta (use)/s/1000 (because the unit of use is milliseconds)

If%util is close to 100%, it indicates that there are too many I/O requests and that the I/O system is fully loaded, the disk
There may be bottlenecks.
Idle less than 70%io pressure is larger, the general reading speed has more wait.
You can also view the B parameter () and WA parameters () in conjunction with Vmstat

In addition, you can also refer
SVCTM generally less than await (because the waiting time for waiting requests is repeatedly computed), the size of SVCTM is generally related to disk performance, cpu/memory load will have an impact on it, too many requests will indirectly lead to increased SVCTM. The size of an await typically depends on the service time (SVCTM) and the length of the I/O queue and the emit mode of the I/O request. If the SVCTM is closer to await, stating that I/O has almost no waiting time, if the await is much larger than SVCTM, the I/O queue is too long, the response time of the application gets slower, and if the response time exceeds what the user can tolerate, you can consider replacing the faster disk. Tune the kernel elevator algorithm, optimize the application, or upgrade the CPU.
The queue Length (AVGQU-SZ) can also be used as an indicator for measuring the system I/O load, but because Avgqu-sz is averaged over a unit time, it does not reflect instantaneous I/O flooding.

Someone else is a good example. (I/O system vs. supermarket queuing)

For example, when we queue up in the supermarket, how do we decide which checkout to go to? The first is to see the number of rows, 5 people than 20 people faster? Besides counting heads, we also often look at the number of things that people buy in front of us, and if there is an aunt who buys food for a week, Then consider changing to a different queue. There is the speed of the cashier, if the money is not clear to the novice, then there are waiting. In addition, the timing is also very important, perhaps 5 minutes before the overcrowded cash table, now is empty, this time the payment is very cool Ah, of course, the premise is that the past 5 minutes to do things than queued to make sense (but I have not found anything more boring than queuing).

I/O systems also have many similarities with supermarket queues:

r/s+w/s similar to the total number of people who have been
Average Queue Length (AVGQU-SZ) is similar to the number of average queueing people in a unit time
Average service time (SVCTM) is similar to the cashier's payment speed
Average wait time (await) is similar to the average wait time per person
Average I/O data (AVGRQ-SZ) is similar to the average number of things each person buys
The I/O operation rate (%util) is similar to the time scale at which a person is queued at the cashier.

We can analyze the mode of I/O requests based on these data, and the speed and response time of I/O.

The following is the analysis of the output of this parameter written by others

#iostat-x1
avg-cpu:%user%nice%sys%idle
device:rrqm/swrqm/sr/sw/srsec/swsec/srkb/swkb/ SAVGRQ-SZAVGQU-SZAWAITSVCTM%UTIL
/dev/cciss/c0d0
0.0044.901.0227.558.16579.594.08289.8020.5722.3578.215.0014.29
/DEV/CCISS/C0D0P1
/dev/cciss/ C0D0P2
0.000.000.000.000.000.000.000.000.000.000.000.000.00

The Iostat output above indicates that there are 28.57 device I/O operations per second: Total io (IO)/s=r/s (read) +w/s (write) =1.02+27.55=28.57 (Times/sec) where the write operation takes up the body (w:r=27:1).

The average Per Device I/O operation takes only 5ms to complete, but each I/O request needs to wait for 78ms, why? Because there are too many I/O requests (about 29 per second), assuming that these requests are issued at the same time, the average wait time can be computed like this:

Average wait time = single I/O service time * (total number of 1+2+...+ requests-1)/Total requests

Apply to the above example: Average wait time =5ms* (1+2+...+28)/29=70ms, and Iostat gives the average latency of 78ms is very close. This in turn indicates that I/O is initiated concurrently.

The number of I/O requests per second (about 29), the average queue is not long (only 2 or so), indicating that the arrival of these 29 requests is uneven, most of the time I/O is idle.

14.29% of the time in a second I/O queue is requested, that is, 85.71% of the time I/O system has nothing to do, all 29 I/O requests are processed within 142 milliseconds.

Delta (ruse+wuse)/delta (IO) =await=78.21=>delta (ruse+wuse)/s=78.21*delta (IO)/s=78.21*28.57=2232.8, indicating i/per second o The request will need to wait for a total of 2232.8ms. So the average queue length should be 2232.8ms/1000ms=2.23, while the average queue Length (Avgqu-sz) given by Iostat is 22.35, why?! Because the Bug,avgqu-sz value in Iostat should be 2.23, not 22.35.

This article from "Flat Light is true" blog, please be sure to keep this source http://ucode.blog.51cto.com/10837891/1902931

View the performance of I/O disks under Linux disks