On Thu, 2006-08-24 at 09:21 -0400, Merlin Moncure wrote:
> On 8/22/06, Jeff Davis <pgsql@j-davis.com> wrote:
> > On Tue, 2006-08-22 at 17:56 -0400, Bucky Jordan wrote:
> > Very interesting. I always hear that people avoid RAID 5 on database
> > servers, but I suppose it always depends. Is the parity calculation
> > something that may increase commit latency vs. a RAID 10? That's
> > normally the explanation that I get.
>
> it's not the parity, it's the seeking. Raid 5 gives you great
> sequential i/o but random is often not much better than a single
> drive. Actually it's the '1' in raid 10 that plays the biggest role
> in optimizing seeks on an ideal raid controller. Calculating parity
> was boring 20 years ago as it inolves one of the fastest operations in
> computing, namely xor. :)
>
Here's the explanation I got: If you do a write on RAID 5 to something
that is not in the RAID controllers cache, it needs to do a read first
in order to properly recalculate the parity for the write.
However, I'm sure they try to avoid this by leaving the write in the
battery-backed cache until it's more convenient to do the read, or maybe
until the rest of the stripe is written in which case it doesn't need to
do the read. I am not sure the actual end effect.
> > > Lastly, re your question on putting the WAL on the RAID10- I currently
> > > have the box setup as RAID5x6 with the WAL and PGDATA all on the same
> > > raidset. I haven't had the chance to do extensive tests, but from
> > > previous readings, I gather that if you have write-back enabled on the
> > > RAID, it should be ok (which it is in my case).
>
> with 6 relatively small disks I think single raid 10 volume is the
> best bet. however above 6 dedicated wal is usually worth considering.
> since wal storage requirements are so small, it's becoming affordable
> to look at solid state for the wal.
>
I've often wondered about that. To a certain degree, that's the same
effect as just having a bigger battery-backed cache, right?
Regards,
Jeff Davis
