Hardware RAID 5 Performance Configurations?

gandy909 asks: "I am facing the need to replace a major server in the next few months due to both EOL status and disk I/O bottleneck issues with the array containing the data. The server is configured with a 2 channel array controller. It is a RAID 5 array and has 4 drives, 2 per channel (2 data, 1 parity, and 1 hot spare). Obvious performance benefits in replacing the server are quadrupling CPU speed and doubling the memory. Other side benefits I will gain with the new drives, that I think should help my performance, are moving from u160 to u320, and going from 7200 RPM to either 10k or 15k RPM." How would you configure a larger array to best increase its performance? "Having googled around, the consensus is that increasing the number of drives is the preferred way to attack the I/O bottleneck. What I don't find much help on is determining the configuration of the larger array. Assuming I am going to be using a 12 drive array I have come up with the following possible configurations:

1 2 channel controller, 6 drives per channel
1 4 channel controller, 3 drives per channel
2 2 channel controllers, 3 drives per channel
3 2 channel controllers, 2 drives per channel

Would any one of those configurations provide better performance than the others, or would they all even out considering other factors?"

Comments

Depends on usage patterns

[cookd]

First, 3 drives in RAID-5 is not very useful. You get a lot of the disadvantages with few of the benefits. Having more drives really helps throughput. So go for more smaller drives over fewer faster drives for RAID-5.

Second, RAID-5 is great for read speeds, but less great for write speeds. A good caching controller will help hide this, but a small write operation requires a read from each disk in the set before the write can be completed (in order to recompute parity for the stripe). If this is mostly reading, or if most writes are large (not small and random), RAID-5 will work fine (data storage, data mining, etc). If writes are frequent (transactions), RAID-5 is painful. RAID-10 might be better.

Why not forego raid5?

[millisa]

If this is an EOL system and its using U160 drives . .chance are those drives are 36 gig or less . .I'd even bet they might be 18's . . . But lets say they are 36's . . four of them in a raid 5 is giving you ~120GB? Why not just get a pair of 147GB drives and run in a raid1? I mean, like others have said, without knowing what you are doing with it, it is hard to say where you are going to get the most benefit, but a lot of times, Raid5 is chosen just due to the increase in space you can get. . . There are more complex options out there that can get you better performance than raid5 (ie, raid 1+0 raid 5+0 and similar) if your controller and wallet support it . . .

Why RAID5?

[TheLink]

What are you using it for? RAID5 is slow for writes. Plus AFAIK rebuilding a RAID5 is a LOT slower and hurts performance more than rebuilding stripes of mirrored drives.

What are the applications? Would you be needing more drive space or adding drives in the near future?

If it's a single application and you know you are not going to need to expand soon or add/change apps - drives are BIG compared to what app needs AND performance is _THE_ issue. Then I'd suggest optimizing around the application.

For example if you have an OLTP postgresql database app, you should put the transaction logs on a separate array optimized for writing speed, then put the tables, indexes on another array, and maybe the temporary sort directories on yet another array.

Even though striping etc helps, if you understand how the application works, it'll often perform better with each type of access on separate arrays. Of course if the next version of the application changes the way it does thing drastically then all bets are off.

You should probably put the O/S stuff on a mirror/array by itself, so the O/S can go do whatever it wants and mostly not affect your main application throughput.

Typically there are diminishing returns as you optimize more exactly to what the application needs, and you usually lose flexibility the more you tailor the configuration to a specific scenario.

So go for big wins. Forget about the last 5-10% performance gains if you are going to lose flexibility or add significant administration cost (complexity).