Re: choosing RAID level for xlogs

Theoretically RAID 5 can perform better than RAID 10 over the same
number of drives (more members form the stripe in RAID 5 than in RAID
10).  All you have to do is calculate parity faster than the drives
can write.  Doesn't seem like a hard task really, although most RAID
controllers seem incapable of doing so, it is possible that Clariion
might be able to acheive it.  The other factor is that for partial
block writes, the array has to first read the original block in order
to recalculate the parity, so small random writes are very slow.  If
you are writing chunks that are larger than your stripe size*(n-1),
then in theory the controller doesn't have to re-read a block, and can
just overwrite the parity with the new info.

Consider just four drives.  in RAID 10, it is a stripe of two mirrors,
forming two independant units to write to.  in RAID 5, it is a 3 drive
stripe with parity giving three independant units to write to.
Theoretically the RAID 5 should be faster, but I've yet to benchmark a
controler where this holds to be true.

Of course if you ever do have a drive failure, your array grinds to a
halt because rebuilding a raid 5 requires reading (n-1) blocks to
rebuild just one block where n is the number of drives in the array,
whereas a mirror only required to read from a single spindle of the
RAID.

I would suggest running some benchmarks at RAID 5 and RAID 10 to see
what the _real_ performance actualy is, thats the only way to really
tell.

Alex Turner
NetEconomist

On 8/16/05, Anjan Dave <adave@vantage.com> wrote:
> Yes, that's true, though, I am a bit confused because the Clariion array
> document I am reading talks about how the write cache can eliminate the
> RAID5 Write Penalty for sequential and large IOs...resulting in better
> sequential write performance than RAID10.
>
> anjan
>
>
> -----Original Message-----
> From: mudfoot@rawbw.com [mailto:mudfoot@rawbw.com]
> Sent: Tuesday, August 16, 2005 2:00 PM
> To: pgsql-performance@postgresql.org
> Subject: Re: [PERFORM] choosing RAID level for xlogs
>
> Quoting Anjan Dave <adave@vantage.com>:
>
> > Hi,
> >
> >
> >
> > One simple question. For 125 or more checkpoint segments
> > (checkpoint_timeout is 600 seconds, shared_buffers are at 21760 or
> > 170MB) on a very busy database, what is more suitable, a separate 6
> disk
> > RAID5 volume, or a RAID10 volume? Databases will be on separate
> > spindles. Disks are 36GB 15KRPM, 2Gb Fiber Channel. Performance is
> > paramount, but I don't want to use RAID0.
> >
>
> RAID10 -- no question.  xlog activity is overwhelmingly sequential 8KB
> writes.
> In order for RAID5 to perform a write, the host (or controller) needs to
> perform
> extra calculations for parity.  This turns into latency.  RAID10 does
> not
> perform those extra calculations.
>
> >
> >
> > PG7.4.7 on RHAS 4.0
> >
> >
> >
> > I can provide more info if needed.
> >
> >
> >
> > Appreciate some recommendations!
> >
> >
> >
> > Thanks,
> >
> > Anjan
> >
> >
> >
> >
> > ---
> > This email message and any included attachments constitute
> confidential
> > and privileged information intended exclusively for the listed
> > addressee(s). If you are not the intended recipient, please notify
> > Vantage by immediately telephoning 215-579-8390, extension 1158. In
> > addition, please reply to this message confirming your receipt of the
> > same in error. A copy of your email reply can also be sent to
> > support@vantage.com. Please do not disclose, copy, distribute or take
> > any action in reliance on the contents of this information. Kindly
> > destroy all copies of this message and any attachments. Any other use
> of
> > this email is prohibited. Thank you for your cooperation. For more
> > information about Vantage, please visit our website at
> > http://www.vantage.com <http://www.vantage.com/> .
> > ---
> >
> >
> >
> >
>
>
>
> ---------------------------(end of broadcast)---------------------------
> TIP 1: if posting/reading through Usenet, please send an appropriate
>        subscribe-nomail command to majordomo@postgresql.org so that your
>        message can get through to the mailing list cleanly
>
>
> ---------------------------(end of broadcast)---------------------------
> TIP 4: Have you searched our list archives?
>
>                http://archives.postgresql.org
>