Why iostat’s %util and svctm Mislead on SSDs and How to Read Them Correctly

Through SSD Benchmark, Interpreting util% Differences

Both tests use the same SSD device (sdb1) but with different benchmark commands, producing distinct IOPS results while %util and svctm both report 100%.

First test (A) shows lower IOPS; second test (B) shows much higher IOPS, yet both report 100% %util and svctm, demonstrating that these metrics no longer reflect true device load on SSDs.

iostat Core Item Interpretation

Key fields:

r/s + w/s : current IOPS (reads per second + writes per second).

await : average time a request spends in the queue plus service time (svctm), measured in milliseconds.

svctm : average service time of the device, excluding host‑side queueing; theoretically constant for a given device.

%util : device utilization; values near 100% traditionally indicate the device is fully busy.

For rotating disks, service time consists of head seek (~3 ms), rotational latency (e.g., 7200 rpm → 4.17 ms, 15000 rpm → 2 ms), and data transfer (often negligible).

Core Problem Explanation

Two observations from the benchmarks:

%util reaching 100% does not necessarily mean the device is fully saturated.

svctm, expected to be constant, varies significantly between tests.

In the era of mechanical disks, I/O is essentially serial, so %util accurately reflected load. Modern SSDs and RAID arrays can execute multiple I/O operations in parallel, breaking the original assumptions.

The original calculation assumes:

concurrency = (r/s + w/s) * (svctm / 1000)

%util = concurrency * 100%

Because svctm is itself derived from the same measurements, concurrency tends to be around 1, forcing %util to 100% regardless of actual load.

An analogy compares a single courier (mechanical disk) to a ninja with 15 clones (SSD/RAID). The old formula only counts the original courier, ignoring the clones, thus under‑estimating true utilization.

Correct Interpretation Method

Obtaining real svctm: Run a synthetic benchmark such as fio with synchronous I/O, a single thread, and io_depth=1. The measured service time from this test represents the true physical svctm.

Calculating true parallelism and util%: Use the measured svctm as a constant in the concurrency formula. For the second test (9342 IOPS, measured svctm ≈ 0.61 ms):

concurrency = (9342 + 0) * (0.61 / 1000) = 5.63762

%util = 5.63762 * 100% = 563.762%

This shows the device is handling roughly 5.6 parallel I/O streams, far beyond the single‑stream assumption.

Implement a small utility that reads iostat -x output, replaces the reported svctm with the pre‑measured true svctm, and recomputes %util for a more accurate view.

Using avgqu‑sz: When the average queue size exceeds 1.5 × the measured parallelism, the disk is considered heavily loaded. In the benchmark, avgqu‑sz = 9.21 and parallelism ≈ 5.63, giving a ratio of 1.63, indicating high pressure.

Additionally, a large gap between await and svctm (await ≫ svctm) signals significant host‑side queuing, another indicator of I/O stress.