Writes on an 8-disk RAID5 group are slower than on a 4-disk RAID5 group on a HP Rack Storage/12 FC

[Oskar_6]

Hi,

Writes on an 8-disk RAID5 group are 2 times slower (according to SQLIO test) than on a 4-disk RAID5 group on a HP Rack Storage/12 FC. Why is it so? Here's the configuration (the 4-disk RAID5 group was placed on disks, from which the 4-disk RAID01 group is aggregated in this configuration):

Auto Rebuild Management : Enabled
Storage Works Fault Management : Disabled
Rebuild/Add Capacity Rate : 50
Stripe Size : 64K
Cache Segment Size : 64K

SCSI Transfer Parameters
------------------------

Data Transfer Rate for channel 0: async
Data Bus Width for channel 0 : 16 Bit
Command Tags for channel 0 : Disabled

Data Transfer Rate for channel 1: async
Data Bus Width for channel 1 : 16 Bit
Command Tags for channel 1 : Enabled

Data Transfer Rate for channel 2: async
Data Bus Width for channel 2 : 16 Bit
Command Tags for channel 2 : Enabled

Data Transfer Rate for channel 3: async
Data Bus Width for channel 3 : 16 Bit
Command Tags for channel 3 : Enabled

Startup Parameters
------------------
Spin Up Option : Automatic
Number of devices per spin up : 3
Length of delay : 6 seconds
Sequence delay : 6 seconds
_________________________________________________________________________________


Logical Drives:

Device Raid Logical Size Physical Size Write Back State
------ ---- ------------ ------------- ---------- -----
0 5 121562 138928 Enabled On Line
1 0+1 34732 69464 Enabled On Line

_________________________________________________________________________________


Arrays:

Array ID Devices
-------- -------
A0 0-0; 0-1; 0-2; 0-3; 0-8; 0-9; 1-10; 1-11;

A1 1-12; 1-13; 1-14; 1-15;


_________________________________________________________________________________

Devices:

Chan-Targ Type Vendor Model Version Size State
--------- ---- ------ ----- ------- ---- -----
0-0 Disk HP 18.2GB C 80-8C44 8C44 17366 On Line
0-1 Disk HP 18.2G ST318453LC HPC4 17366 On Line
0-2 Disk HP 18.2G ST318453LC HPC4 17366 On Line
0-3 Disk HP 18.2G MAS3184NC HPC3 17366 On Line
0-8 Disk HP 18.2G MAS3184NC HPC3 17366 On Line
0-9 Disk SEAGATE ST318451LC HP03 17366 On Line
1-10 Disk HP 18.2GB C 80-8C42 17366 On Line
1-11 Disk HP 18.2GB C 80-8C42 17366 On Line
1-12 Disk HP 18.2GB C 80-8C42 17366 On Line
1-13 Disk HP 18.2GB C 80-8C42 17366 On Line
1-14 Disk HP 18.2GB C 80-8C42 17366 On Line
1-15 Disk HP 18.2GB C 80-8C44 8C44 17366 On Line

_________________________________________________________________________________


LUN Mapping:
# c0p0 c0p1 c1p0 c1p1
= ======== ======== ======== ========
0 ........ ........ ........ 0.......
1 ........ ........ ........ .1......
2 ........ ........ ........ ........
3 ........ ........ ........ ........
4 ........ ........ ........ ........
5 ........ ........ ........ ........
6 ........ ........ ........ ........
7 ........ ........ ........ ........

--
Many thanks,
Oskar

[Mahesh Kumar Malik]

Hi Oscar

Do you have same application accessing both groups?

RAID 5 is seen by many as the ideal combination of good performance, good fault tolerance and high capacity and storage efficiency. It is best suited for transaction processing and is often used for "general purpose" service, as well as for relational database applications, enterprise resource planning and other business systems. For write-intensive applications, RAID 1 or RAID 1+0 are probably better choices (albeit higher in terms of hardware cost), as the performance of RAID 5 will begin to substantially decrease in a write-heavy environment.

Regards
Mahesh

[Marek Smejkal]

Oskar,

more parity overhead for 8 disk groups, but I would not expect 2x slower.

Marek

[Oskar_6]

Hi Marek,
Well, 1.6 - 1.9 times slower, and on random writes. Sequential writes are more comparable (13 - 20% less throughput). Random reads are better on the 8-disk RAID5 group, but sequential reads are slightly worse (no more than 6% though).

--
Many thanks,
Oskar

[Oskar_6]

Hi Mahesh,
Yes I've used the SQLIO test for testing both groups. According to Microsoft:

<>

My application, specifically Microsoft SQL Server, won't place too much writes on that disk, but, still, I was expecting the performance of writes to increase along with the number of physical drives, but not to be a ridiculous 1.63 MBps for random writes.

Maybe I'm not getting something here?

--
Many thanks,
Oskar

[Leif Halvarsson_2]

Hi

Sorry if I can't be of any direct help as I have no experience with your RAID controller but, of course you are right. A 8 disk RAID group should perform better the a 4 disk. The physical disks is the bottleneck (if not a very large number of disks). Each disk can handle a limited number of IOPS, the performance of the disk group should increase linear (at least to a certain level) regardless of the RAID level. In your case, something must be wrong. The most simple reason, has a disk in the 8-group failed ?

Is there any tool for monitoring your controller, it may be of some help.

We have a similar problem with a EVA 3000 array. A 8 disk array performs better then a 56-disk. Dhe documentation for the EVA is clear at that point, the performance should increase linear up to the max number of disks. I have an ongoing supportcall to HP for this problem but, to this date, not get any useful feedback.

[Oskar_6]

Thanks for your reply Leif.
No, the RAID5 group hasn't failed. This condition is pretty easy to spot and I would not have missed it. Yes, I have a tool for my RAID controller called "FC Array Assistant" at hand. I can measure the current throughput in IOps and MBps and the figures are pretty much the same as from the SQLIO test. Maybe I will have to look for some diagnostic tools if such exist as you suggested.
I agree with you that there must something terribly wrong with the array configuration (firmware, settings, cabling, incompatibility etc.), or it might be as well functioning improperly in a way that's not obvious, or it might be some kind of a design fault. Who knows?

--
Many thanks,
Oskar