) Use the "iostat-DX 1" command to monitor Io Performance

Http://huoding.com/2011/07/13/91

Many of the website's performance problems will eventually come down to I/O, so it is necessary to understand the iostat command.

TIPS: Do you know where iostat gets io-related information? Use the strace command to track the answer:

Shell> strace-eopen iostat

Open ("/proc/diskstats", o_rdonly) Note: strace Tutorial: 5 simple ways to troubleshoot using strace

Note: For more information about diskstats, see the official documentation (mainly field1 ~ Field11 ).

If you do not have the iostat command in your operating system, you can install it from the source code by using the following methods:

Centos/Fedora Installation Method: Yum install sysstat

Debian/Ubuntu Installation Method: aptitude install sysstat

The most commonly used iostat command format is "iostat-DX 1", which means that I/O Extension information is displayed every second.

Shell> iostat-DX 1

Device: rrqm/s wrqm/s r/s w/s rsec/s wsec/s

SDA 0.18 37.71 0.65 2.63 50.18

Avgrq-SZ avgqu-SZ await svctm % util

113.46 0.35 107.49 1.67 0.55

Device: rrqm/s wrqm/s r/s w/s rsec/s wsec/s

SDA 0.00 4208.00 0.00 165.00 0.00

Avgrq-SZ avgqu-SZ await svctm % util

993.16 119.54 1144.36 6.07 note: the average value starting from system startup is displayed at the beginning, followed by the average value in each interval.

This section describes the meanings of related parameters:

Rrqm/S: Number of read requests merged per second in the queue

Wrqm/S: Number of write requests merged per second in the queue

R/S: Number of read requests completed per second

W/S: Number of write requests completed per second

Rsec/S: number of sectors read per second

Wsec/S: number of sectors written per second

Avgrq-SZ: average request sector size

Avgqu-SZ: average length of the Request queue

Await: average waiting time for each request

Svctm: Average service time of each request

Util: Device Utilization

Note: We recommend that you compare the source code to remember how these parameters are calculated.

The following parameters are more important: util, svctm, await, avgqu-SZ:

Util is the utilization rate of the device. If it is close to 100%, it usually indicates that the device capability tends to be saturated (not absolute ). Sometimes there may be more than 100%, because the data is read by a non-atomic operation.

Svctm is the average service time of each request. From the source code, we can see that (R/S + w/s) * (svctm/1000) = util. For example, if util reaches 100%, then svctm = 1000/(R/S + w/s). Suppose iops is 1000, then svctm is about 1 ms, if the value is greater than this value for a long time, the system is faulty.

Await is the average wait time for each request. This time includes the queue time and service time. That is to say, in general, await is larger than svctm, and the smaller the difference, the shorter the queue time, and the larger the difference, the longer the queue time, it indicates a problem with the system.

Avgqu-SZ is the length of the average request queue. Undoubtedly, the shorter the queue length, the better.

Note: The svctm parameter will be deleted in a future version of iostat. This is the reason described in the official documentation:

The average service time (svctm field) value is meaningless, as I/O statistics are calculated at block level, and we don't know when the disk driver starts to process a request. for this reason, this field will be removed in a future sysstat version.

In addition, sometimes iostat will display some very outrageous results. The official FAQ provides the following explanation:

Because of a Linux kernel bug, iostat-X may display huge I/O response times (svctm) and a bandwidth utilization (% util) of 100% for some devices. indeed these devices have a value for the field #9 (beginning after the device name) in/proc/{partitions, diskstats} which is always different from 0, and even negative sometimes. yet this field shocould go to zero, since it gives the number of I/OS currently in progress (it is incremented as requests are submitted, and decremented as they finish ). to (temporarily) solve the problem, you shoshould reboot your system to reset the counters in/proc/{partitions, diskstats }.

If you want to learn more about Io, refer to the following materials:

Getting the hang of iops

Basic I/O monitoring on Linux