Sar -d

[gigiz]

Hi ,
i have a question.
I have a system Model: 9000/800/SD32A
Main Memory: 53165 MB
Processors: 24
OS mode: 64 bit
The system work fine but i have looked with sar -d a strange value for access to my vg00 disk, exactly on /opt .
This is the output of my sar -d 6 6 but this values are always high.
12:00:14 c2t0d0 94.36 36.50 12 52 0.00 0.32
12:00:21 c2t0d0 99.17 36.50 7 68 0.00 0.41
12:00:27 c2t0d0 100.00 36.50 12 95 0.01 0.75
12:00:33 c2t0d0 93.50 36.50 7 58 0.00 0.84
12:00:39 c2t0d0 95.01 37.08 8 64 0.19 1.03
12:00:45 c2t0d0 100.00 36.50 6 58 0.00 0.79
Average c2t0d0 100.58 36.59 9 66 0.03 0.66

My vg00 disk is on the XP storage, i want know if the value report is normal, ad if anyone can explaine me this value in perfomance term.
If i can use a monitoring tool etc!!
Many point at any response.

[Redhat]

you can use vmstat -d 5 12

and monitor the value for one min and check whether the average load (avload) value is more than the wait value (avwait).

If average wait is more in perticular disk all the time means that some issue with disk or I/O

check the po (page out ) value in vmstat 5 5 so that you can know whether any paging is happening or not. Normally it should be 0(zero)

[gigiz]

But where is a avload and avwait value ...

procs memory page faults cpu
r b w avm free re at pi po fr de sr in sy cs us sy id
23 0 0 4054240 1822317 68 16 0 0 0 0 0 29556 267730 23212 59 10 31

Disk Transfers
device xfer/sec
c2t0d0 6

[Redhat]

Sorry you will find avserv and avwait in sar -d output .

avserv > avwait

[gigiz]

Yes but the output of my sar -d is :
13:25:05 c2t0d0 100.00 36.52 43 244 0.03 0.37
13:25:11 c2t0d0 100.00 36.62 13 80 0.02 0.45
13:25:17 c2t0d0 99.17 36.50 5 35 0.00 0.41
13:25:23 c2t0d0 100.00 36.50 7 40 0.00 0.61
13:25:29 c2t0d0 93.33 36.50 13 89 0.00 0.49
13:25:35 c2t0d0 100.00 36.81 9 84 0.06 0.75
Average c2t0d0 103.16 36.56 15 96 0.02 0.45

It's normal or no .What is the analisis, there is a degrade or no ?

[Redhat]

It is very difficult to say that the performance issue ,though is shows that c2t0d0 is being used very high at the point of time .You have to analyse it for long as it may be due to certain application specific where the disk uses become very high.

see in the same time whether there is a pageing issue or no.

[gigiz]

No there aren't paging in - out. No Swap activity .....
Help me

[Redhat]

find out the major activity happening in system though top command.

you can reach to the root process by following the pid with ps-eaf |grep

..
Pls tell me what performance problem you r faceing due to this high i/o usage for c2t0d0.

[Duncan Edmonstone]

Well the only thing that looks a little odd is the high avque, which seems to indicate an average of 36 IO requests outstanding at each sample point. Thats looks maybe a littel high for a system disk which essentially shouldn't be doinf anything during normal operation except the odd page in for an executable or shared library or the odd write to a system logfile.

Of course if your users aren't reporting any performance issues I wouldn't be too concerned about it, but if you *really* want to investigate further you could:

a) look at what filesystems you have in vg00 (bdf | grep vg00) - anything in there that shouldn't be (like an application filesystem?)
b) Check you didn't have a backup of the OS running when you collected the stats?
c) Do you have glance? You can look at IO by filesystem using 'glance -i' that might tell you where all this IO is happening

HTH

Duncan

[Dennis Handly]

>Manojit: you can reach to the root process by following the pid with ps -eaf |grep

You can get a hierarchical process tree listing by using: UNIX95= ps -Hef

[kenj_2 · Accepted solution]

I agree with you that the numbers don't "add up".

From the average totals for c2t0d0.

%busy 103.16 (?)
avque 36.56 (?)
r+w/s 15
blks/s 96
avwait 0.02
avserv 0.45


The device is not particularly busy averaging 15 IOs/sec. The response time is good with an average service time of less than .5ms and average host queue wait time of only .02ms. Given that, it doesn't really make sense to have such a *consistent* host queue of 36.

In addition to the suggestions for tracking down the source of the IO demand, it could be a reporting problem with sar and/or pstat(). Is Glance reporting the same queues ?

Your initial post didn't say which OS version you are on, but each OS version has patches for sar which fix various reporting errors. I would check for those patches.

[gigiz]

ok