Re: hardware for a server - Mailing list pgsql-general

From Greg Smith
Subject Re: hardware for a server
Date
Msg-id 4B9E2E3F.3040900@2ndquadrant.com
Whole thread Raw
In response to hardware for a server  (A B <gentosaker@gmail.com>)
Responses Re: hardware for a server  (A B <gentosaker@gmail.com>)
Re: hardware for a server  (Bruce Momjian <bruce@momjian.us>)
Re: hardware for a server  (Vick Khera <vivek@khera.org>)
List pgsql-general
A B wrote:
> 3Ware SAS 9690SA-8i 512 MB BBU
> Adaptec SAS Raid 5805  256 MB BBU
> LSI MegaRaid SAS 8708 128 MB BBU
>
> When it comes to choosing the acctual discs I guess this would be
> appropriate to use:
> "other data":  Barracda ES.2 1000 GB (SATA)  to get a a good GB/$ ratio.
> OS/xlog : Barracuda ES.2 500 GB (SAS)
> DB: Cheeta 15K.6  146 GB (SAS) (The 300 GB would be better if I can
> find some more money)
>

Here's some things not to do to help narrow this down.

Don't mix SAS and SATA; vendors will tell you it works, but it's
extremely painful when it doesn't, and that happens sometimes.

Don't put SAS drives on a 3ware controller.  They say that works now,
but they haven't really gotten it right yet--their controllers are still
only good with SATA drives.

Don't put an Adaptec card into a Linux system.  They don't take that OS
nearly as seriously as your other choices here.

Don't mix drive capacities unless absolutely necessary for budget
reasons, because you'll hate life the minute you're trying to recover
from your first disaster and have minimal flexibility for rebuilding any
arrays because of that choice.  This is also a secondary reason not to
mix SAS and SATA.

Do not mix the xlog and OS disks onto the same drive.  That defeats the
purpose of having a separate xlog disk on the first place, particularly
because on a Linux system every xlog write is going to require flushing
every OS write in the pipeline to commit.  Ditto for mixing the xlog and
all this image/avatar stuff, if those are producing large writes too.
You'll be better off mixing the xlog with the database disks--at least
then you'll be clogging the RAID card's write cache with mostly database
writes when things get congested, rather than having either sitting
blocked behind OS or "other data" writes that must get flushed first.

Given what you've said about your budget here, I suspect that you're
heading toward either 3ware or LSI and all SATA drives.  I wouldn't
expect that big of a performance difference between the two with only 8
drives on there.  If you had 24, the 3ware controller would likely turn
into the bottleneck, and if this was an all SAS system the LSI one would
also be the only sensible choice.  (Make sure you get the right battery
included with whatever controller you pick)

In your situation, I'd probably get a pair of TB drives for the OS and
"other data", just to get them all out of the way on one place to fight
with each other, then use whatever budget is leftover to get the best
performing drives you can to create a 6-disk RAID10 for the database +
xlog.  If all six of those can only be a smaller drive instead after
that, that's not such a bad combination--you can always grab a larger
capacity drive as your spare and then put it anywhere in the array in an
emergency.

Mind you, that's said from the perspective of a database person.  If
your image data has to be high performance, too, maybe an even 4/4 split
between OS+data and DB+xlog would make more sense for your app.

--
Greg Smith  2ndQuadrant US  Baltimore, MD
PostgreSQL Training, Services and Support
greg@2ndQuadrant.com   www.2ndQuadrant.us


pgsql-general by date:

Previous
From: "A. Kretschmer"
Date:
Subject: Re: Unable to connect to Postgres database from email marketing software on the same host
Next
From: Major Services
Date:
Subject: Re: Unable to connect to Postgres database from email marketing software on the same host