Re: Performance Question: RAID or Individual drives ?

Steve Phelan wrote:

> Dominic Baines wrote:
>
> > Thanks MotoX:
> >
> > Following you're advise I tried this on a separate server with an almost
> > identical datbase (export of original and imported onto the other) but this time
> > used the 15 drive model for the database (DBA handbook rough example followed)
> > but with the drive non-RAID'd and the performance was just so much better than
> > the RAID5 version for both READ's (about 85% slower) and WRITE's (more than 55%
> > slower). OK so that doesn't tell me much more that I expected really but is
> > there a way to improve the RAID performance ?
> >
>
> Wow, that's quite a come-down on the reads - not what I'd expect. Maybe try a
> different adapter? Check the specs on any 'tweaking' options it might have for
> performance tuning.

The adapter is the only one/type that is accepted. It's a large site and they only use specific types of NT kit for servers no alternative choice I'm afraid :-(

OK perhaps didn't tell you the whole picture. I didn't think it was worth trying this without some 'realistic' data so I used a number of department workstations to simulate multi logging and kicked off a number of common type queries and updates that go on all the time in background whilst I did my testing just to see what the difference was between RAID and non-RAID.

Inaddition database I/O usage on a hour by hour basis during the day I know because of the user profile so correcting for one type of use may impact on another. The database is mostly written to between 8am and 4pm, after 4pm is mostly reads producing reports until about 11pm when is goes into backup mode, export and hot, at 4am it's 50/50 reads and writes while it synchronises with local databases, 5am to 6am is almost dead quiet and at 8am it's mostly writes again. The company that uses it (I'm a contractor) are spread worldwide and it's in a production/research department and the other user groups (Oracle servers) are in Japan and USA hence the times.

> > I believe the RAID set is one where every drive is striped across every disk and
> > there is a parity member and there is a standby disk. RAID 5 ?
>
> RAID5 strips the parity across all the disks, yes - rather than having a separate
> parity disk. The standby is your hot-spare, which you can configure to auto-rebuild
> when a disk fails.

This sounds spot on.

> > How would I capture the time taken for each process
> > realistically ? I tried this as a rough stopwatch exercise from a sql*plus
> > connection at both the server and at a client workstation.
>
> Hey, nothing wrong with the old stopwatch! :-) Saves my life all the time.

Yes but it would be great if I could schedule scripts on a 24 basis completely unattended just to see wouldn't it ?

> You could try using - on UNIX - a shell script to log the output from iostat,
> vmstat, sar, etc.

Yes, but it NT :-( (unfortunately)

> Or (and on NT) buy some additional software - although I've found
> this can be pretty expensive.

Thought some interrogation of sysdate both before and after and calculating the difference may be acceptable but then that wouldn't give me a real picture of how long the process took or would it ?

> > At the end of the day I suppose it is the client and SLA's that will win on a
> > recovery arguament rather than performance and as we both answer to the same
> > person they will have to make a choice. The database is approximately 50/50
> > read/write and it is growing at the rate almost across every tablepsace of some
> > 15% per year in size.
>
> Yep, many of my clients will happily accept the performance hit of RAID5 for the
> better fault-tolerance and lower cost, over, say, RAID0+1.

RAID is great for normal filesystems and it sure helps for disater recovery but it isn't exactly kind on performance is it now ?And, there is always one who will say that "....when's the last time we had to recover from drive failure? Isn't that what the backup's are for ? ....such and such takes too long... what are you going to do to make it faster ...." killing RAID and implimenting decent back-ups and DR would work......... or would it ?

Dominic

> Regards,
>
> Steve Phelan (MotoX).
>
> > Regards,
> >
> > Dominic
> >
> > MotoX wrote:
> >
> > > That was well timed - I'm just in the middle of benchtesting strip v
> > > non-strip v single disk v RAID5 for a client. It's a UNIX box, but the
> > > outcome *should* be similar on NT. However, *test* you own kit with a mix of
> > > the types of transactions *you* are going to perform. Anyway, here goes
> > > (35,000,000 row test table):
> > >
> > > READING:
> > >
> > > One disk, best read rate 10MB/s per disk (one of).
> > >
> > > 3 striped disks, 3.4 MB/s per disk. If parallel query used (degree of 2 or
> > > 4), rate goes to 5.7 MB/s per disk. In other words, if you stripe (64k),
> > > it's also best to use parallel query when you can, because if you don't you
> > > won't max out the I/O bandwidth you've created.
> > >
> > > On 6 striped disks, 1.95 MB/s per disk. With degree of 2 or 4, 4.4 MB/s per
> > > disk. In other words, still use parallel, and although you continue to get a
> > > boost, it's reducing.
> > >
> > > RAID5 - 1 processor, 8.3 MB/s per RAID set. Parallel with degree of 2 or 4,
> > > 16.9 MB/s per RAID set. In other words, for reading, RAID5 is just as quick
> > > as striped disks, but you still need to go parallel to max out the I/O. And,
> > > of course, RAID5 (like striping) is much faster than non-RAID single disks,
> > > as long as you can provide the CPU to drive it.
> > >
> > > WRITING (in summary as I haven't finished yet):
> > >
> > > 3 striped drives are about twice as fast as a single disk (not three times
> > > faster).
> > > 6 striped drives are about 4.5 times faster than a single disk.
> > > NB. Like reading, the overhead of sync'ing the drives, memory bandwidth,
> > > etc., affects how much real improvement you get - it won't be linear as you
> > > add more drives.
> > >
> > > RAID5 - on my limited testing so far, writing (creating a 4 Gig tablespace)
> > > has dropped from 3 x 6.8 MB/s per disk to 7.5 MB/s per RAID set. In other
> > > words, RAID5 array is over twice as slow on heavy writing as the same disks
> > > striped (non RAID5).
> > >
> > > In summary, look at striped disks (RAID0 or RAID0+1 or through an LVM) for
> > > write intensive parts of your db. Look at RAID5 for read intensive sections,
> > > and learn to live with the write penalty where you can.
> > >
> > > MotoX.
> > >
> > > Dominic Baines wrote in message <35AA0A1F.41151B15_at_hermes.cam.ac.uk>...
> > > >I've an NT admin who RAID's everything on every NT box he touches. This
> > > >is OK for redundancy if the system dies but I'm not sure this is the
> > > >best option for an Oracle database performance reasons mainly. Are there
> > > >any tuning guru's out there who could shine a like on the appropriate
> > > >arguament to use IF it would be better to use individual drives rather
> > > >than to rely on the RAID set ?
> > > >
> > > >What am I talking about ?:
> > > >
> > > >Standard set-up would be an Oracle server on NT 4 SP3 with system disk
> > > >a mirrored pair and second 'drive' being a raid set over say 7 to 15
> > > >disks. So ORANT is on D:, as is everything else. OK there are different
> > > >drives and spindles but every read or write to anywhere on the RAID set
> > > >would use every drive, wouldn't it ? These are 4GB Seagate SCSI drives.
> > > >The controller is a proper RAID controller, whatever that may be. It's
> > > >all on Compaq kit.
> > > >
> > > >Thanks,
> > > >
> > > >Dominic Baines
> > > >
Received on Wed Jul 15 1998 - 04:57:54 CDT