topic Re: sar -d giving inaccurate data in Operating System - Linux

sar -d giving inaccurate data

Tom Wolf_3 — Tue, 07 Jun 2005 11:15:28 GMT

Hello. We're running HP-UX 11i on a rp7410. Whenever I run #sar -d on this box, I notice that %busy on a number of VA disks is always at 90 plus percent. Despite this high %busy rate, the r+w/s is really low, around 20. This high %busy figure is inaccurate. I've verified the %busy using Measureware and it's output doesn't agree with that generated by sar. I see there is a patch that supposedly addresses sar -d issues, PHKL_30515, and we've already applied it but the inaccurate data is still being generated.

Is anyone aware of another patch that resolves sar -d inaccurate data generation?

Any help would be greatly appreciated.

Thank you.
-Tom

Re: sar -d giving inaccurate data

Steven E. Protter — Tue, 07 Jun 2005 11:30:17 GMT

I would search the patch database and get a more comprehensive set of sar.

http://www6.itrc.hp.com/service/patch/mainPage.do

I'm asking them to transfer this case to the HP-UX forum.

SEP

Re: sar -d giving inaccurate data

Stuart Abramson — Tue, 07 Jun 2005 12:49:56 GMT

I have noticed the following in regard to sar -d:

1. You can occasionally get "spikes" of high numbers in %busy or avg_serv. Especially when this is the "1st" read/write you are doing on this disk in a while.

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.

Re: sar -d giving inaccurate data

Steven E. Protter — Tue, 07 Jun 2005 13:02:49 GMT

What would happen if you collected data over a longer time period and did average statistics.

Attaching a script set that does that.

SEP

Re: sar -d giving inaccurate data

Tom Wolf_3 — Tue, 07 Jun 2005 13:59:27 GMT

I've looked at the average %busy figure for the past three weeks using the standard system activity daily data files, #sar -d -f /var/adm/sa/sadd. The same six SAN disks always have a %busy rate of at least 90 percent.

Re: sar -d giving inaccurate data

harry d brown jr — Tue, 07 Jun 2005 15:11:53 GMT

sar is sampled base and glance is trace based:
http://www.hpug.org.uk/PING_may_2004_NL_volume_6_number_2_FINALa.pdf

glance is more accurate!

what about patch PHKL_30510 or even PHKL_32090?

go here: http://www2.itrc.hp.com/service/patch/search.do?BC=patch.breadcrumb.main|&pageContextName=hpux:::

in "step 2" change to (if not already) to "SEARCH BY KEYWORD", then enter the word sar and click on the search button. You should get a list of 17 patches (you probably don't need them all).

live free or die
harry d brown jr