Re: PowerEdge 2950 questions - Mailing list pgsql-performance

On 8/24/06, Jeff Davis <pgsql@j-davis.com> wrote:
> 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:
> > 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.

it's worse than that.  if you need to read something that is not in
the o/s cache, all the disks except for one need to be sent to a
physical location in order to get the data.  Thats the basic rule with
striping: it optimizes for sequential i/o in expense of random i/o.
There are some optimizations that can help, but not much.  caching by
the controller can increase performance on writes because it can
optimize the movement across the disks by instituting a delay between
the write request and the actual write.

raid 1 (or 1+x) is the opposite.  It allows the drive heads to move
independantly on reads when combined with some smart algorithms.
writes however must involve all the disk heads however.  Many
controllers do not to seem to optimze raid 1 properly although linux
software raid seems to.

A 4 disk raid 1, for example, could deliver four times the seek
performance which would make it feel much faster than a 4 disk raid 0
under certain conditions.

> > 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?

yeah, if the cache was big enough to cover the volume.  the wal is
also fairly sequenctial i/o though so I'm not sure this would help all
that much after thinking about it.  would be an interesting test
though.

merlin