sar -d

[Scott_20]

what do the columns acutally tell me and at what point is a column at at certain number bad. i'm trying to put the man page into real terms
thanks

[Uday_S_Ankolekar · Accepted solution]

This doc might be a help..
http://www1.itrc.hp.com/service/cki/docDisplay.do?docLocale=en_US&docId=200000063203050

-USA

[Stuart Abramson_2]

1. The sar -d report has the following fields:

time device %busy avque r+w/s blks/s avwait avserv

where:

device Logical name of the device and its
corresponding instance.

%busy Portion of time device was busy
servicing a request;

avque Average number of requests outstanding
for the device;

r+w/s Number of data transfers per second
(read and writes) from and to the
device;

blks/s Number of bytes transferred (in 512-byte
units) from and to the device;

avwait Average time (in milliseconds) that
transfer requests waited idly on queue
for the device;

avserv Average time (in milliseconds) to
service each transfer request (includes
seek, rotational latency, and data
transfer times) for the device.

2. Things to look for are:

a. % busy greater than 50%

b. avque greater than 3

c. avwait greater than avserv.

- This means the i/os are waiting longer than the
the time it takes to process them. Bad...

d. However:

- %busy high and queue length low, is okay, because
it means the disk is working, but is keeping up.

e. avserv < 6 ms is good!

If a disk rotates at 10,000 revolutions per minutes, then
how long does one revolution take:

10,000 revolutions
10,000 RPM = ------------------
60 seconds

60 seconds
1 revolution = --------------
10,000

= .006 seconds

= 6 milliseconds

f. Average seek time would be 1/2 rotation time. Also
called "latency time".

g. Average transfer rate for one block of data on one
cylinder would then be 6 milliseconds.

[Bill Hassell]

However, once you know that a particular disk device has an enormous load, the next steps are fairly complicated. First, if there are no applications running, then there will be no load. Therefore, applications cause disk I/O. And bad applications can saturate disk channels. In a database application, a poorly indexed database or poorly constructed SQL statements can impose severe loads on the disks.

Now many sysadmins are asked to 'fix' the problem when the reality is that the biggest impact may be fixing the application. Certainly if there are competing applications trying to access the same disk in different places, significant improvemts are possible by moving some of the files to another channel. Or by striping the volume across multiple disks. Or in some cases (very heavy read activity), a larger buffer cache in the kernel.

There is nothing wrong with massive disk I/O and high queue lengths--unless it is affecting performance in an unacceptable way. Then the task becomes one of asking: why are there so many disk I/O's required of your application? Can this be changed in some way?