1826148 Members
4697 Online
109690 Solutions
New Discussion

Re: sar -d data

 
SOLVED
Go to solution
Dean Irving
Occasional Advisor

sar -d data

Don't understand how the 'avwait' time came be higher than the 'avserv' time? What's the better indicator of 'busy-ness' of a disk? Why?
Just because it works doesn't mean it's right.
4 REPLIES 4
Thierry Poels_1
Honored Contributor

Re: sar -d data

Hi,

avwait
indicates the average time in ms that a disk job waited in queue (before really starting disk I/O) ... as work starts stacking up the avwait increases indicating processes are waiting for work on that drive.

avserv
indicates the average time in ms that a disk job took to complete.... (=effective disk I/O)

regards,
Thierry.
All unix flavours are exactly the same . . . . . . . . . . for end users anyway.
Steven Sim Kok Leong
Honored Contributor

Re: sar -d data

Hi,

If the jobs are processed on average (avserv) very slowly and that a job waits very long for its turn to be served in the queue on average (avwait), it is indicative that the queue of jobs is clearing too slowly, like the queue of people in front of a foodstall - very busy.

Hope this helps. Regards.

Steven Sim Kok Leong
Dean Irving
Occasional Advisor

Re: sar -d data

So, if 'avwait' spikes occassionally to 120-180ms, but 'mean' of the 'avwait' values hoovers around 70-80ms and 'avserv' time is farily constant at 20-30ms, does this indicate a problem? Drives in question are the mirrored vg00 (i.e., the 'root' drives). System is SuperDome running 11.11/64
Just because it works doesn't mean it's right.
Thierry Poels_1
Honored Contributor
Solution

Re: sar -d data

hmmmz,
Superdome, as in recent fast hi-tec hardware?!?! Yep, I would say you have a problem. Your figures are way to high. Try to find the cause of the problem: runaway process, patch required, swapping, .... Use glance to trace the heaviest I/O process. VG00 normally does not contain application data, so shouldn't be overloaded at all.

good luck,
Thierry.
All unix flavours are exactly the same . . . . . . . . . . for end users anyway.