RE: Informix "hardware bottlenecks"

And I quote: From: "Art S. Kagel" <kagel@bloomberg.net> > >Reinhard Habichtsberg wrote: > > > > On Mon, 29 Nov 1999 17:18:51 -0500, Barry Lloyd > > <bdl62@42_dirm_po.dmh.state.sc.us> wrote: > > > > >I have seen several recommendations to avoid RAID 5. Can someone tell > > >me exactly what the problems with RAID 5 are? > >Most of those disparaging postings are from me. There are two problems >with RAID5. The first is performance which is the one most people notice >and if you can live with write throughput which is 50% of the equivalent >RAID0 stripe set then that is fine. The performance hit is caused because >RAID5 ONLY reads the one drive containing the requested sector leaving the >other drives free to return other sectors from different stripe blocks. >This is the reason that RAID5 is preferred to RAID3 or RAID4 for >filesystems, this feature improved small random read performance. However, >since the parity and the balance of the stripe block were not read, if you >rewrite the block (which databases do far more frequently than filesytems) >the other drives must all be read and a new parity calculated and then >both the modified block and the parity block must be written back to disk. >This READ-WRITE-READ-WRITE for each modified block is the reason RAID5 is >so poor in terms of write throughput. Large RAID controller caches and >on controller firmware level RAID implementations alleviate the problem >somewhat but not completely and write performance still hovers at around >half what a pure stripe (RADI0) would get. > >The second problem, despite what others have said IS a FUNDAMENTAL problem >with the design of RAID5 which various implementors have tried to correct >with varying levels of success. The problem is that if a drive fails >slowly over time, known as partial media failure, where periodically a >sector or two goes bad, this is NOT detected by RAID5's parity and so >is propagated to the parity when that sector is rewritten which means that >if another drive fails catastrophically its data will be rebuilt utilizing >damaged parity resulting in two sectors with garbage. Now this may not >even be noticed for a long time as modern SCSI drives automatically remap >bad sectors to a set of sectors set asside for the purpose but the >corrected error is NOT reported to the OS or the administrators. Over >time if the drive is going it will run out of remap sectors and will have >to begin returning data reconstructed from the drive's own ECC codes. >Eventually the damage will exceed the ECC's ability to rebuild a single >bit error per byte and will return garbage. > >RAID3 and RAID4 are superior in both areas. In both all drives are read >for any block which improves sequential read performance (Informix Read >Ahead depends on sequential read performance) over RAID5 and parity can >be (and in most implementations IS) checked at read time so that partial >media failure problems can be detected. Write performance is >approximately the same as RAID0 for large writes or smaller stripe block >sizes. One problem with early implementations of RAID3/4 was slow parity >checking since it has to be calculated for every read and every write. >Modern controller based RAID systems use the on-board processor on the >SCSI controller to perform the parity checks without impacting system >performance by tying up the a system CPU to check and produce parity. >These RAID levels require the exact same number of drives as RAID5. > >RAID10 provides the best protection and performance with read performance >exceeding any other RAID level (since both drives of a mirrored pair can >be reading different sectors on parallel) and write performance is closest >to pure striping. Indeed in a hardware/firmware implemented RAID10 array >with on-board cache apparent write throughput can exceed RAID0 for brief >periods due to the two drives of each pair being written to independently >though the gain is not sustainable over time. > >A third problem with ALL RAID3/4/5 from which RAID10 does not suffer is >multiple drive failure. (Ever get a batch or 200 bad drives? We have!) >If one drive in a RAID3/4/5 array fails catastrophically you are at risk >for complete data loss if ANY of the remaining 4 (or more) drives should >fail before the original failed drive can be replaced and rebuilt. With >RAID10, since it is made up as a stripe set of N mirrored pairs, when a >drive fails you are only at risk for complete data loss if that one drives >particular mirror partner should fail. Make each mirrored pair from >drives selected from different manufacturer's lots and the probability of >this happening become vanishingly small. > >Fourth problem. During drive rebuild RAID3/4/5 (and RAID01 mirrored >stripe sets) performance of the array during the rebuild can degrade by >as much as 80%! Some RAID systems let you tune the relative priority of >rebuild versus production to reduce the performance hit to as low as about >40% degradation but this will increase the recovery time increasing the >number of production requests that are degraded and increasing the risk >of the previous problem with a second drive failure. RAID10, since only >one drive is involved in mirror recovery, the array's performance (for a >4 drive array) is degraded only a maximum of 80% for reads and writes >against the failed pair and only slightly (due to controller traffic) for >accesses to the other drives, on average, since the one pair comprises >only 20% of accesses, performance is affected no more than 16% during >recovery and the risk of catastrophic data loss is reduced. > >Well this concludes my quarterly RAID5 rant for anyone who has had trouble >finding my earlier ones. > >Art S. Kagel I've also personally seen a RAID5 box go titsup.com, and it was special. No warning, just a total failure. Niiice... From: Bryce Stenberg <bryce@hrnz.co.nz> > >I joined this list a couple of weeks back and have found it interesting >with >many useful tips. > >NO RAID 5 ??? >Two days ago we just went live with a new NT4 server running IDS7.31. This >server has two RAID5 disk arrays for the database and the logs. What issues >are we going to run into with RAID5 that lead to exclamations of "NO RAID >5" >(Obnoxio)?? So far everything runs fine and very fast. > >Regards, > Bryce Stenberg. > Harness Racing New Zealand computer department, > emailto:bryce@hrnz.co.nz > Phone: +64 3 3385099 > > >-----Original Message----- >From: Andris [mailto:andris.shirons@dati.lv] >Sent: Thursday, 19 October 2000 21:52 >To: Obnoxio The Clown; informix-list@iiug.org >Subject: RE: Informix "hardware bottlenecks" > > >Hi, > >well, I should've expected such reaction...8) > >Any ideas about other cofigurations, RAID 10 for example? > >Thanks for answering! > >Andris > > > -----Original Message----- > > From: Obnoxio The Clown [mailto:obnoxio@hotmail.com] > > Sent: Thursday, October 19, 2000 1:44 PM > > To: andris.shirons@dati.lv; informix-list@iiug.org > > Subject: Re: Informix "hardware bottlenecks" > > > > > > >Recommended RAID level? (RAID 5 or RAID 10 or else)? > >