sar -d question

[Scott_14]

Well, since I can always relay on the HP people out here and sar -s pretty typical amoung unix system, I have a question here...

here is a snip from an aix sar -d, and I am trying to understand the vaule of
the r+w/s
If you notice the 2 disk show 99 they are mirrored however I dont see a problem with the disk wait and serv.

I am being told to move them to hardware mirror for better performance, but I would like to understand this first.
thanks


00:00:00 device %busy avque r+w/s Kbs/s avwait avserv
Average hdisk0 4 0.2 15 91 14.6 4.7
hdisk3 38 0.0 99 806 0.8 4.1
hdisk4 38 0.0 98 697 0.8 4.1
hdisk5 1 0.2 6 54 28.9 6.6
hdisk1 13 0.0 110 826 0.0 1.6
cd0 0 0.0 0 0 0.0 0.0

[Tim Nelson]

Not sure what the question is ?

99 io/s with a service time of 4.1 msec.. Looks great. ( although this is only a small sample with no trends)

(not sure what you think good service time is, 4ms is cool to me )


Low io/s will typically have a higher service time for many reasons , because the disk has to go look for data after being idle, they may be random in nature, they may just be unluckly not to have the heads sitting on top of that block, probably not in read-ahead....etc.etc..

Low io like this won't get much help from moving it around on standard disk ( but then I do not know what kind of disk this is, maybe is is some old 2400rpm 2gb SE drives ).

If somebody wants something faster I hear the price of solid state disk is down from a couple 100thou to a few 100thou ;)

Post some more info or thoughts.

[Scott_14]

Thank you..

I guess what I was wanting was someone to tell me that 99 I/O and as you mentioned the low service time is good.

I have a vendor telling me the disk are being so hammered they need to be moved to be mirroed on the raid card, and not os mirrored.

thanks, I was second guessing seeing I/O at 99
trying to understand where they were comming from.

[Emil Velez]

if you are doing file system I/O to a disk alot depends on your sizing of buffer cache and your read and write hit rate of buffer cache. Everntually if you modify a block it has to be written back to the disk when buffer cache is fuller and the block in memory is needed. if a block is in a logical volume that is mirrored and you do a read it will read the block from the device (copy) that has the lowest queue so it will do load balancing at the LVM/VXVM level.

If you have a LUN that has multiple paths to it and you have the HPUX autopath software it will do load balancing at the driver level since the OS will only see a single device file for multiple physical paths. WIth 11.31 there is no need since this functionlaity is built into the OS.

So bottom line.

1. mirror for fault tolerance against a disk failure.
2. let the OS or volume manager do load balancing across multiple paths if you have a lun in a disk array and multiple FC cards.
3. Let buffer cache minimize the amount of physical writes if you have lots of memory and do not have memory pressure.