Some I/O statistical tools in Linux (1) (1)

As a Linux system administrator, it is essential to count various types of IO. Iostat is obviously the most important statistical tool. However, iostat is not the focus of this article, because there are already a lot of tutorials on the network for your reference. Here, I want to introduce some other statistical tools to meet different requirements.

Iostat

Iostat is exceptionally powerful and has many output items, as shown in the following example:

 
 

  
  
Device: rrqm/s  wrqm/s  r/s     w/s    rkB/s    wkB/s    avgrq-sz avgqu-sz   await r_await w_await  svctm  %util  
  
  
 
  
  
sda     0.00     0.50  173.50   73.50  3076.00   604.00    29.80   149.93    676.58   74.36 2098.15  4.05 100.00 
 
 

Their meanings are as follows:

• Rrqm/s: the number of merge read operations per second. That is, delta (rmerge)/s.
• Wrqm/s: Number of write operations performed on merge per second. That is, delta (wmerge)/s
• R/s: The number of read I/O devices completed per second. That is, delta (rio)/s.
• W/s: the number of write I/O devices completed per second. That is, delta (wio)/s
• Rsec/s: Number of read sectors per second. That is, delta (rsect)/s
• Wsec/s: Number of write sectors per second. That is, delta (wsect)/s
• RkB/s: the number of K Bytes read per second. It is half of rsect/s, because the size of each sector is 512 bytes. (calculated)
• WkB/s: the number of K bytes written per second. Half of wsect/s (to be calculated)
• Avgrq-sz: average data size (slice) of 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 aveq is measured in milliseconds ).
• Await: average wait time for each device I/O operation (MS). That is, delta (ruse + wuse)/delta (rio + wio)
• Svctm: Average service time for each device I/O operation (MS). That is, delta (use)/delta (rio + wio)
• % Util: the percentage of time in one second for I/O operations, or the number of I/O queues in one second is not empty. that is, delta (use)/s/1000 (because the Unit of use is milliseconds)

If % util is close to 100%, it indicates that too many I/O requests are generated and the I/O system is fully loaded. This disk may have a bottleneck.

When the idle is less than 70% I/O, the load is high. Generally, the read speed is wait.

You can also view the parameters B (number of processes waiting for resources) and wa in combination with vmstat (percentage of CPU time occupied by I/O wait, higher than 30% when I/O pressure is high)

In addition, await parameters must be referenced by svctm. IO problems may occur if the difference is too high.

Avgqu-sz is also a place to note when performing IO optimization. This is the data size of each operation. If the number of times is large but the data size is small, in fact, IO will be very small. if the data is big, the IO data will be high. you can also use avgqu-sz × (r/s or w/s) = rsec/s or wsec/s. that is to say, the speed of reading is determined by this.

Generally, svctm is smaller than await (because the wait time for simultaneously waiting requests is calculated repeatedly). The size of svctm is generally related to disk performance, and the CPU/memory load will also affect it, too many requests may indirectly increase the svctm. the size of await generally depends on the service time (svctm), the length of the I/O queue, and the mode in which I/O requests are sent. if svctm is close to await, it means that I/O has almost no waiting time. If await is much larger than svctm, it means that the I/O queue is too long and the response time of the application is slow, if the response time exceeds the allowable range, you can consider replacing a faster disk, adjusting the kernel elevator algorithm, optimizing the application, or upgrading the CPU.

The queue length (avgqu-sz) can also be used as an indicator to measure the system I/O load. However, because avgqu-sz is based on the average per unit time, therefore, it cannot reflect the instantaneous I/O flood.

If you have time, I will write several separate posts to talk about iostat.