Re: RAID Configuration Sugestion - Mailing list pgsql-performance

From Ron
Subject Re: RAID Configuration Sugestion
Date
Msg-id 6.2.3.4.0.20050830154823.05ac9308@pop.earthlink.net
Whole thread Raw
In response to Re: RAID Configuration Sugestion  ("Joshua D. Drake" <jd@commandprompt.com>)
Responses Re: RAID Configuration Sugestion
List pgsql-performance
At 03:27 PM 8/30/2005, Joshua D. Drake wrote:


>>>If you still have the budget, I would suggest considering either
>>>what Ron suggested or possibly using a 4 drive RAID 10 instead.
>>
>>
>>IME, with only 4 HDs, it's usually better to split them them into
>>two RAID 1's (one for the db, one for everything else including the
>>logs) than it is to put everything on one RAID 10.  YMMV.
>
>Really? That's interesting.  My experience is different, I assume
>SCSI? Software/Hardware Raid?

The issue exists regardless of technologies used, although the
technology used does affect when things become an irritation or
serious problem.

The issue with "everything on the same HD set" seems to be that under
light loads anything works reasonably well, but as load increases
contention between DB table access, OS access, and xlog writes can
cause performance problems.

In particular, _everything_ else hangs while logs are being written
with "everything on the same HD set".  Thus leaving you with the
nasty choices of small log writes that cause more seeking behavior,
and the resultant poor overall HD IO performance, or large log writes
that basically freeze the server until they are done.

Having the logs on a different HD, and if possible different IO bus,
reduces this effect to a minimum and seems to be a better choice than
the "shared everything" approach.

Although this effect seems largest when there are fewest HDs, the
general pattern  is that one should use as many spindles as one can
make use of and that they should be as dedicated as possible in their
purpose(s).  That's why the TPC bench marked systems tend to have
literally 100's of HD's and they tend to be split into very focused purposes.

Ron Peacetree



pgsql-performance by date:

Previous
From: Josh Berkus
Date:
Subject: Re: 'Real' auto vacuum?
Next
From: Chris Browne
Date:
Subject: Re: When to do a vacuum for highly active table