Re: RAID 5 vs RAID 10 benchmark

"Jan" <janik_at_pobox.sk> wrote in message news:81511301.0411250222.496c1242_at_posting.google.com...
> Several scientific (or logical) conclussions were already made about
> RAID 5
> that this is not the best option for write intensive databases. It
> seems very logical also to me when I read arguments against RAID 5.
>
> But I`m confused by following benchmark showing that it is not
> worthful anymore (at least for a tested storage) to thinks about RAID
> 5 vs RAID 10 from the performance point of view.
>
> http://www-1.ibm.com/servers/storage/disk/ess/pdf/raid5-raid10.pdf

The conclusion that I would draw from that is that the workload that they used to benchmark the system didn't manage to stress the IO capacity that they had set up. The paper states that the disk system that they use had an IO capacity of 200 iops per disk. The RAID5 system was therefore running at approx 80% capacity and the RAID10 system was running at approx 50% capacity. I rather like this paper, because it fits well with my own personal bias, and the reason for example that I haven't signed up at www.baarf.com , it does show the advantage of RAID10 over RAID5 (though it would be nice if the actual workloads used rather than a general description were published), but it also illustrates neatly that if RAID5 has enough capacity for your business needs then it really isn't a crime to buy it. In these days of many disks and large caches that capacity can be really rather high.

The one area where I would be a little interested in some more figures is the redo/archiving subsystem. It looks like RAID5 was largely saved from crippling performance before the overall write request rate got too high because the redo rate was well below the capacity of the raid set that held the redo logs. In many (maybe most) systems (because of poor sql and or app design) the redo generation will become the bottleneck well before the data disks are even working up a sweat. In practice therefore I tend to favour the 'mixed' setup that they describe.

-- 
Niall Litchfield
Oracle DBA
http://www.niall.litchfield.dial.pipex.com