Once upon a time CPU utilization was quite a useful metric. Following are the output of several tools that provide CPU utilization metrics:

top

top reports a load of 1.66.

Is this correct? No. The correct load number is probably closer to 2.4.

# top -b -n 1| head -20
top - 11:27:45 up 151 days,  1:55,  7 users,  load average: 1.66, 1.84, 1.88
Tasks: 389 total,   3 running, 386 sleeping,   0 stopped,   0 zombie
Cpu(s):  0.7%us, 20.6%sy,  1.2%ni, 77.3%id,  0.1%wa,  0.0%hi,  0.1%si,  0.0%st
Mem:  32639636k total, 32206476k used,   433160k free,   235732k buffers
Swap: 16359420k total, 10285664k used,  6073756k free,  2354840k cached

  PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND
16702 root      20   0 8274m 5.0g 5.0g S 85.1 16.1  59164:55 VirtualBox
 4657 root      20   0  9.8g 5.2g 5.1g S 45.5 16.6  26518:13 VirtualBox
 6239 root      20   0  9.8g 5.1g 5.1g S 39.6 16.5  31200:52 VirtualBox
27070 root …

In this blog post, I will look at disk utilization and saturation.

In my previous blog post, I wrote about CPU utilization and saturation, the practical difference between them and how different CPU utilization and saturation impact response times. Now we will look at another critical component of database performance: the storage subsystem. In this post, I will refer to the storage subsystem as “disk” (as a casual catch-all). 

The most common tool for command line IO performance monitoring is

iostat

, which shows information like this:

root@ts140i:~# iostat -x nvme0n1 5
Linux 4.4.0-89-generic (ts140i)         08/05/2017      _x86_64_        (4 CPU)
avg-cpu:  %user   %nice %system %iowait  %steal   %idle
          0.51    0.00    2.00    9.45    0.00   88.04
Device:         rrqm/s   wrqm/s …