Re: With 4 disks should I go for RAID 5 or RAID 10 - Mailing list pgsql-performance

In response to "Fernando Hevia" <fhevia@ip-tel.com.ar>:
>
> > David Lang Wrote:
> >
> > with only four drives the space difference between raid 1+0 and raid 5
> > isn't that much, but when you do a write you must write to two drives (the
> > drive holding the data you are changing, and the drive that holds the
> > parity data for that stripe, possibly needing to read the old parity data
> > first, resulting in stalling for seek/read/calculate/seek/write since
> > the drive moves on after the read), when you read you must read _all_
> > drives in the set to check the data integrity.
>
> Thanks for the explanation David. It's good to know not only what but also
> why. Still I wonder why reads do hit all drives. Shouldn't only 2 disks be
> read: the one with the data and the parity disk?

In order to recalculate the parity, it has to have data from all disks. Thus,
if you have 4 disks, it has to read 2 (the unknown data blocks included in
the parity calculation) then write 2 (the new data block and the new
parity data)  Caching can help some, but if your data ends up being any
size at all, the cache misses become more frequent than the hits.  Even
when caching helps, you max speed is still only the speed of a single
disk.

> > for seek heavy workloads (which almost every database application is) the
> > extra seeks involved can be murder on your performance. if your workload
> > is large sequential reads/writes, and you can let the OS buffer things for
> > you, the performance of raid 5 is much better.
>
> Well, actually most of my application involves large sequential
> reads/writes.

Will it?  Will you be deleting or updating data?  If so, you'll generate
dead tuples, which vacuum will have to clean up, which means seeks, and
means you new data isn't liable to be sequentially written.

The chance that you actually have a workload that will result in
consistently sequential writes at the disk level is very slim, in my
experience.  When vacuum is taking hours and hours, you'll understand
the pain.

> The memory available for buffering (4GB) isn't bad either, at
> least for my scenario. On the other hand I have got such strong posts
> against RAID 5 that I doubt to even consider it.

If 4G is enough to buffer all your data, then why do you need the extra
space of RAID 5?  If you need the extra space of the RAID 5, then 4G
isn't enough to buffer all your data, and that buffer will be of limited
usefulness.

In any event, even if you've got 300G of RAM to buffer data in, sooner or
later you've got to write it to disk, and no matter how much RAM you have,
your write speed will be limited by how fast your disks can commit.

If you had a database multiple petabytes in size, you could worry about
needing the extra space that RAID 5 gives you, but then you'd realize
that the speed problems associated with RAID 5 will make a petabyte sized
database completely unmanageable.

There's just no scenario where RAID 5 is a win for database work.  Period.
Rationalize all you want.  For those trying to defend RAID 5, I invite you
to try it.  When you're on the verge of suicide because you can't get
any work done, don't say I didn't say so.

> Well, here rises another doubt. Should I go for a single RAID 1+0 storing OS
> + Data + WAL files or will I be better off with two RAID 1 separating data
> from OS + Wal files?

Generally speaking, if you want the absolute best performance, it's
generally recommended to keep the WAL logs on one partition/controller
and the remaining database files on a second one.  However, with only
4 disks, you might get just as much out of a RAID 1+0.

> > now, if you can afford solid-state drives which don't have noticable seek
> > times, things are completely different ;-)
>
> Ha, sadly budget is very tight. :)

Budget is always tight.  That's why you don't want a RAID 5.  Do a RAID 5
now thinking you'll save a few bucks, and you'll be spending twice that
much later trying to fix your mistake.  It's called tripping over a dime
to pick up a nickel.

--
Bill Moran
Collaborative Fusion Inc.
http://people.collaborativefusion.com/~wmoran/

wmoran@collaborativefusion.com
Phone: 412-422-3463x4023