Re: RAID 5 performance

Paul Baumgartel <paulb_at_pcnet.com> wrote:

>I've just done a direct comparison of RAID 5 and non-RAID disk configurations.
 

>All disks are mounted on the same CPU, a Digital Alpha running OpenVMS 6.1. The
>non-RAID configuration contains a database spread across 4 2-GB SCSI disks. The
>RAID 5 configuration consists of 4 data disks and 1 parity disk as a single logical
>volume, with all database files on that volume. In both cases, the online redo logs
>were on a separate disk from all of the other database files. I created identical
>databases on each of the two configurations, with two Oracle instances to access
>them.
 

>The application that I tested was a bulk data load. Part 1 of the load uses
>SQL*Loader to load data from a set of ASCII files into staging tables. Part 2 of
>the load executes a number of packaged procedures to find inconsistent data, compute
>various values, generate primary keys, and create new versions of updated data; it
>then loads the results into the actual application tables. This part of the load
>does a significant amount of reading from the database as well as writing.
 

>I tested the load on each database, with only the database instance under test
>running. On the non-RAID array, the entire process, for one set of files, took an
>average of 12 minutes. On the RAID 5 array, the average time was 32 minutes.
 

>The write performance seemed particularly bad, as evidenced by write response times
>observed in the SQL*DBA file I/O monitor. Response times ranged up to 150 ms on the
>RAID, where typical values on the non-RAID disks were in the single digits.
 

>YMMV, but this makes it pretty clear to me that, for this application at least, RAID
>5 is not the way to go. Next I'm going to test RAID 0+1 (striped and mirrored), and
>I'll post the results.

I am not surprised at the results you have achieved, the problem appears to be one of the fact that you appear to have configured RAID in software, by that I mean that VMS is doing all the work of cutting down your data-block into 4 pieces (one for each disk) and building the checksums etc. for placing on the parity disk (This is in fact, as pointed out already, RAID 3). RAID five is even worse due to the fact that data & Checksums can be placed randomly, ie there is NO parity disk, data & checksums end up on the same disks, although obviously not from the same written block. (Is that clear??) Anyway, S/W based RAID 5 murders any machine. The way to go is to use an external RAID array, when I worked for a large UK corporate we used RAID arrays from a company called Baydel, in fact we were the world's first purchasers of these devices. They are RAID 3 but cached (Read and Write if required) and go like mad. We were achieving a sustained rate of 700 I/O's per second using totally random seeks (thereby removing as much chance as possible that the data we wanted was in the cache) off a 10Gb drive. This was with Oracle databases. Although RAID 0+1 is a nice option, you are still relying on VMS and the good old CPU to do all the data placement, the CPU should actually be doing useful work for the users. If you require RAID's performance (forget availability) then an external array is the best way to go as these remove all the processing overhead from the Host. I have proved that on a busy system with lots of disk activity that up to 50% of the CPU can be used to handle disk I/O, and this would account for your extended run times.

THIS IS NOT A PLUG FOR BUSINESS
I'm new here, but I'm one of the UK's top performance consultants having set up my own consultancy company since leaving large UK corporate's, where I ran various large IT departments. The sharing of information seems pretty good. If anyone has any performance related questions (VMS, UNIX, Novell, IBM, ICL) and you don't require an urgent response (this is free and I have to earn real cash eat sometime) then drop me a line and I'll do my best to drop you some hints. Please don't bomb me with mail asking where your response is as I may not always get round to everything.

Ashley
100440.1227_at_compuserve.com Received on Thu Oct 19 1995 - 00:00:00 CET