# Two traps in iostat: %util and svctm

DevFeed: [Two traps in iostat: %util and svctm](<https://devfeed.tech/articles/two-traps-in-iostat-util-and-svctm-12459.md>)

Original publisher: [Read original article](<http://brooker.co.za/blog/2014/07/04/iostat-pct.html>)

Author: Marc Brooker

Published: 2014-07-04T00:00:00Z

Content type: article

Language: en

Sources: [Marc Brooker's Blog](<https://devfeed.tech/sources/marc-brooker-s-blog.md>), [Marc Brooker's Blog](<https://devfeed.tech/sources/marc-brooker-s-blog-2.md>)

Topics: [IO](<https://devfeed.tech/topics/io.md>), [Linux](<https://devfeed.tech/topics/linux.md>), [Statistics](<https://devfeed.tech/topics/statistics.md>)

Tags: [devices](<https://devfeed.tech/tags/devices.md>), [io](<https://devfeed.tech/tags/io.md>), [linux](<https://devfeed.tech/tags/linux.md>), [performance](<https://devfeed.tech/tags/performance.md>), [ssd](<https://devfeed.tech/tags/ssd.md>), [utilities](<https://devfeed.tech/tags/utilities.md>)

## AI overview

The article examines two misleading iostat metrics, %util and svctm, with particular attention to solid-state drives and varying I/O parallelism. It explains why svctm lacks a clear meaning and why interpreting these fields as direct measures of device service time or saturation can be misleading.

## Source excerpt

Two traps in iostat: %util and svctm These commonly-used fields in iostat shouldn't be commonly-used. iostat, from the excellent sysstat suite of utilities, is the go-to tool for evaluating IO performance on Linux. It's obvious why that's the case: sysstat is very useful, solid, and widely installed. System administrators can go a lot worse than taking a look at iostat -x. There are some serious caveats lurking in iostat's output, two of which are greatly magnified on newer machines with solid state drives. To explain what's wrong, let me compare two lines of iostat output: Device: rrqm/s wrqm/s r/s w/s rkB/s wkB/s avgrq-sz sdd 0.00 0.00 13823.00 0.00 55292.00 0.00 8.00 avgqu-sz await r_await w_await svctm %util 0.78 0.06 0.06 0.00 0.06 78.40 Device: rrqm/s wrqm/s r/s w/s rkB/s wkB/s avgrq-sz sdd 0.00 0.00 72914.67 0.00 291658.67 0.00 8.00 avgqu-sz await r_await w_await svctm %util 15.27 0.21 0.21 0.00 0.01 100.00 Both of these lines are from the same device (a Samsung 840 EVO SSD), and both are from read-only 4kB random loads. What differs here is the level of parallelism: in the first load the mean queue depth is only 0.78, and in the second it's 15.27. Same pattern, more threads. The first problem we run into with this output is the svctm field, widely taken to be the average amount of time an operation takes. The iostat man page describes it as: The average service time (in milliseconds) for I/O requests that were issued to the device. and goes on to say: The average service time (svctm field) value is meaningless, as I/O statistics are now calculated at block level, and we don't know when the disk driver starts to process a request. The reasons the man page states for this field being meaningless are true, as are the warnings in the sysstat code. The calculation behind svctm is fundamentally broken, and doesn't really have a clear meaning. Inside iostat, svctm in an interval is calculated as time the device was doing some work / number of IOs, that is the amoun