AutoRaid 12H Glance Reports High I/O

[BEN WRIGHT]

Hello there
I promise to score points for great answer!
Right then here is my configuration:
1 x 12 H AutoRaid containing 7 x 18GB Disks with two controllers
7 Disks -> 4 LUNs of 20GB
4 LUNs -> 1 Volume Group totalling 80GB going to both controllers (alternate path)
1 Volume Group -> 1 Logical File System
Mounted for Oracle Database Tables

I set the AutoRaid up this way because I was told it was better for Redundancy and could improve performance?

In Glance Plus (the performance tool we use) we note that there is a very high level of I/O ranging from 80 - 100% on ONE of the disks. This is causing great concern amongst the IT Staff here but as I have no actual report of performance problems passay I am wondering what to do.

The first thing is that the with 96MB of Cache on the controllers I think the I/O is an indication of the controller absorbing the data before writing it?

The only other things I can thing of doing to improve the situation is:
1) Remove all the LUNs and create 1 LUN etc
2) Stripe the file system (is this possible as I thought the AutoRaid striped by default anyway).

More information as it comes in:
sar -d reports that this disk can be up to 60% busy but it has a very low avque size (compared to the other disks), occasionally the avwait is greater than the avserv, but this happens on all the disks not just those in the AutoRaid.

If you require any more info to help me decide what to do about high Disk I/O I would happily provide.

Best regards

Ben

[Bill McNAMARA_1]

glance is saying in fact the lun is experiencing high throughput. It has no way to determine disk usage in the 12H.
The best way to do this is via /opt/array/bin/logprint . The logprint results can be analysed by hp to verify disk array sanity.

I won't worry too much about it from an admin point of view.. keep an eye on it though.

Later,
Bill

[BEN WRIGHT]

Thanks Bill
Bill and Ben the flower pot men, how un-canny is that, I expect you are from the States so won't understand this reference from one of the oldest childrens programs on TV?

Anyway, I am also convinced that it is not to much of a problem but need ways to prove it (non-technical people interfering). Unfortunately the log file have not been created, when I run the command it say:
There are no Log Files.
I cannot find a command to switch the log on?
Any idea's
Best regards
Ben

[Bill McNAMARA_1 · Accepted solution]

Hi Ben, yea, I know Bill & Ben but never watched them, they were b&w right!! I'm in France at the moment, but from Dublin.

the logs if I remeber correctly are normally started with arraylog ( in /opt/hparray/bin), but in any case don't activate them unless you are desperate, I don't think you have a problem.

You could run a diagnostics from xstm (or mstm) select the 12H and run tools - info - run

Striping will make little or no difference even if you see it noted here in the forums.

What will make a difference is making sure that that your autoraid is not 100% full, and stores mainly in Raid1/0, turning on active hot spare should be sufficient if it's not already on.

Glance is reporting the 12H as a single disk device file, but this single disk device file corresponds to a Lun. the luns on the autoraid are spread across every single disk in the array.. to prove it, create a small lun and

dd if=/dev/dsk/cXtYdLUN2 of=/dev/null bs=4096k

all disk leds blink. (this is effectively a read)

you can if from a disk and op to the LUN to benchmark writes..

Later,
Bill

[BEN WRIGHT]

Thanks Bill

That is what I am trying to explain to the powers that be, but you can only get so technical and I have no proof, they have a nice graph maxing out at 100% every once in a while!!!

I may well start up the logs for a day, just to show them some information, although I hope the sar statistics will be sufficient. Personally having seen the data from sar they may actually have problems with the other disks not the AutoRaid, but there you go.

Best regards

Ben