Iostat to understand the Linux hard disk IO performance __linux

Http://www.php-oa.com/2009/02/03/iostat.html

I've never used this parameter before. Now seriously study the Iostat, because there is just one important server pressure high, so put it up to analyze. The next one is IO, a server with too much pressure.

1 2 3 4 5 6 7 8

$iostat-X 1 Linux 2.6.33-fukai (fukai-laptop)           _i686_     (2 CPU) avg-cpu: %user  % nice%system%iowait %steal  %idle nbsp;         5.47    0.50    8.96    48.26    0.00   36.82   device:          rrqm/s   wrqm/s     r/s     w/s   rsec/s & nbsp wsec/s avgrq-sz avgqu-sz   await  svctm %util         6.00   273.00   99.00    7.00  2240.00  2240.00    42.26     1.12   10.57   7.96  84.40 SDB           &Nbsp;   0.00     4.00    0.00  350.00     0.00   2068.00     5.91     0.55    1.58   0.54   18.80

rrqm/s: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 sectors read 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 each sector size is 512 bytes. (Need to calculate)
wkb/s:Write K bytes per second. It's half the wsect/s. (Need to calculate)
Avgrq-sz:The average data size (sector) per 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 unit is in milliseconds).
await:Average wait time (in milliseconds) for each device I/O operation. Delta (Ruse+wuse)/delta (Rio+wio)
SVCTM:Average service time (in milliseconds) per device I/O operation. Delta (use)/delta (RIO+WIO)
%util:How much of the time is spent on I/O operations in a second, or how many times in a second I/O queues are non-null. That is, Delta (use)/s/1000 (because the unit of use is in milliseconds)

If the%util is close to 100%, which indicates that there are too many I/O requests, the I/O system is full load, the disk
There may be a bottleneck.
Idle less than 70% io pressure is larger, the general reading speed has more wait.
You can also combine vmstat to view the B parameter (the number of processes waiting for the resource) and the WA parameter (percentage of CPU time spent on Io wait, high io pressure above 30%)
In addition, the parameters of await and SVCTM to refer to. The problem of IO is certain to be too bad.
Avgqu-sz is also a place to be aware of when doing IO tuning, this is the direct operation of the data size, if the number of times, but the data are small, in fact, IO will also be very small. If the data is large, the IO data will be high. You can also pass AVGQU-SZX (r/s or w/s) = RSEC/S or wsec/s. That is to say, the speed of reading is determined by this.

In addition, you can also refer to
SVCTM is generally less than await (because the waiting time of the waiting request is calculated repeatedly), the size of the 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 the await depends generally on the service time ( SVCTM) as well as the length of the I/O queue and the emit mode of I/O requests. If the SVCTM is closer to await, there is almost no wait time for the I/O, if await is much larger than SVCTM, the I/O queue is too long and the response time is slow, if the response time User can allow the range, at this time can consider replacing faster disk, adjust the kernel elevator algorithm, optimize the application, or upgrade the CPU.
Queue Length (AVGQU-SZ) can also be used as an indicator of system I/O load, but since Avgqu-sz is average per unit time, it does not reflect instantaneous I/O floods.

A good example of others. (I/O system vs. supermarket queues)

For example, when we queue checkout in a supermarket, how do we decide which payment table to go to? The first line is the number of teams, 5 people are always faster than 20 people? In addition to counting heads, we often look at what people buy in front of us, if there is an old lady who buys food for a week, then you can consider a different line. There is the speed of the cashier, if met even the money is not clear to the novice, there are waiting. In addition, timing is also important, perhaps 5 Minutes before the overcrowding of the cashier, now is empty, this time the payment is very good ah, of course, the premise is that the past 5 minutes to do things than the line to make sense (but I have not found anything than the queue is boring).

The I/O system also has many similarities with the supermarket queues:

r/s+w/s similar to the total number of people who paid
Average Queue Length (AVGQU-SZ) similar to the number of people queuing in a unit of time
Average service time (SVCTM) similar to Cashier's collection speed
Average wait time (await) is similar to the average waiting time per person
Average I/O data (AVGRQ-SZ) is similar to the average number of things each person buys
The I/O operating rate (%util) is similar to the percentage of time someone queues up at the cashier.

Based on this data, we can analyze the pattern of I/O requests, as well as the speed and response time of I/O.

The following is written by someone else. Analysis of the output of this parameter

1 2 3 4 5 6

# iostat-x 1 avg-cpu:%user% nice%sys%idle 16.24 0.00 4.31 79.44