|
Rob, I have always been instructed to keep drives in a RAID set as close to the same size as possible to avoid the types of problem you are encountering. Again, Alexei has stated what I have always understood. The configuration in question will always have a problem, no matter in what type of system it is installed. Many other systems would not even let you create a RAID configuration of this type, as a number of RAID controller cards will require identical size disks to create a RAID 5 set, if they will let you configure mismatched drives, it would only be as a RAID 0 (JBOD) set, which does not have parity protection. Seems to me the only way to improve your situation is to modify you RAID set, either add additional drives to lessen the I/O load, or preferably, replace the odd sized drive with one or more drives to balance the RAID set. Good Luck, Keith Blazek MIS Coordinator Alexei Pytel <pytel@xxxxxxxxxx> wrote on 10/01/2004 06:14:53 PM: > To me it does not look like a RAID problem per se. > 53 4327 70564 74.9 131.3 5.9 47.3 83.9 > 54 4327 35282 74.9 50.7 6.6 13.8 36.8 > 55 4327 35282 74.9 70.0 5.6 22.0 47.9 > > I think, in this configuration the problem is because there is a > significant imbalance in unit size. > Unit 53 is twice the size of other two. Having set aside potential hot > spots, normally I/O load is spread proportionally to amount of data stored > on the drive, which again is roughly proportional to disk size. > As a result, unit 53 has to handle twice the load. If I/O load is light, > this is not an issue, but with heavy load this unit will be simply > overloaded. > RAID configurations are always somewhat unbalanced in size, but usually > not so much (25% on 4-unit set, 12.5% on 8-unit set). > This configuration is simply not for heavy disk workload. > > You will have to frequently rebalance data to keep data allocation > "skewed" to compensate for disk size imbalance. > Adding one drive to the RAID set will make all drives equal in size, which > is very very importnat for disk performance under heavy load. > > Alexei Pytel > always speaking for myself only > > Where is the beginning of the end, which ends the beginning? > > > > rob@xxxxxxxxx > Sent by: midrange-l-bounces+pytel=us.ibm.com@xxxxxxxxxxxx > 10/01/2004 04:10 PM > Please respond to > Midrange Systems Technical Discussion > > > To > midrange-l@xxxxxxxxxxxx > cc > > Subject > Three drive raid set. > > > > > > > Anyone else out there have serious performance issues with a three drive > raid set? We are. And we even ran STRASPBAL. IBM tried iDoctor, etc. > Nothing out of the ordinary. So, their suggestion is a STRASPBAL *ENDALC > and then add them back in with STRASPBAL *CAPACITY. > > Our BP says he knows of another customer that had the same issue but just > ordered another drive and it was solved. Never opened pmr with IBM. > > Trying to find a few "me too's", hopefully with pmr #'s, to encourage IBM > to look harder. > > We will buy more drives. We were hoping to put it off awhile. Boss does > think that getting them in before year end is a good thing though, > budgetwise. > > System ASP . . . . . . . : 3316 G > % system ASP used . . . : 74.9333 > > WRKDSKSTS > Size % I/O Request Read Write > Unit Type (M) Used Rqs Size (K) Rqs Rqs > ... > 50 4327 52923 74.9 15.3 8.6 7.0 8.2 > 51 4327 70564 74.9 25.3 7.9 13.7 11.6 > 52 4327 61744 74.9 29.4 6.4 17.7 11.6 > 53 4327 70564 74.9 131.3 5.9 47.3 83.9 > 54 4327 35282 74.9 50.7 6.6 13.8 36.8 > 55 4327 35282 74.9 70.0 5.6 22.0 47.9 > > The last three are the raid set in question. > > Rob Berendt > -- > Group Dekko Services, LLC > Dept 01.073 > PO Box 2000 > Dock 108 > 6928N 400E > Kendallville, IN 46755 > http://www.dekko.com > > --
As an Amazon Associate we earn from qualifying purchases.
This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].
Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.