Home > PostgreSQL > Understanding ‘iostat’ output for database I/O loads

Understanding ‘iostat’ output for database I/O loads

From the Linux man page:

“The iostat command is used for monitoring system input/output device loading by observing the time the devices are active in relation to their average transfer rates. The iostat command generates reports that can be used to change system configuration to better balance the input/output load between physical disks.”

Reports that we get from ‘iostat’ are really useful but I myself had a little bit of trouble when trying to interpret the results while using the the first time, but since then its my preferred go-to tool when trying to debug disk overloads.

I usually use the iostat command with the following switches:

iostat –d –x <interval>

Where…

-d = gets rid of the CPU stats so that we can easily concentrate on the I/O only

-x = some additional info like ‘await’ and ‘svctm’ (will discuss them later)

<interval> = this is time in seconds, so every number of <interval> seconds you will get a new ‘iostat’ report

Let’s now see a sample output of ‘iostat’:

If we look at stats above usually we would look at %util and if we see close to 100% it can identify the problem for a single disk setup, but not in a usual multi-disks scenario.

Columns that we look at it in order to identify the problem will be:

syvctm: The average service time (in milliseconds) for I/O requests that were issued to the device

await: The average time (in milliseconds) for I/O requests issued to the device to be served. This includes the time spent by the requests in queue and the time spent servicing them.

This basically means:

 await = syvctm + wait time in queue

Now using the above we can have a basic rule to identify an overloaded setup:

…if you can see a lot of difference in values for ‘syvctm’ and ‘await’ every now and then, that can tell you about I/O requests being going into long waits and this should help you identify the problem.


Shoaib Mir
shoaibmir[a]gmail.com

About these ads
Categories: PostgreSQL Tags: , ,
  1. Misha
    June 9, 2010 at 10:46 pm

    Thanx,

    but can you tell something about method (yours methods for-example) of analyzing this value (await – syvctm)? What does it mean “a lot of difference in values for ‘syvctm’ and ‘await’”? What level of “difference” can wee check as critical?

    • June 10, 2010 at 12:31 am

      ‘await’ and ‘syvctm’ values should be as close as possible, if the await time starts going higher then syvctm you should really watch it out, but again this is very basic monitoring and just the first step. Some thing next to check in that case will be your IOP values (r/s and w/s) and debug in detail to see if the disk is doing what it is supposed to.

  1. No trackbacks yet.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

Follow

Get every new post delivered to your Inbox.

%d bloggers like this: