Date: Tue, 6 May 2008 13:39:27 -0400 (EDT)
From: Greg Smith <gsmith@gregsmith.com>
To: Dennis Muhlestein <djmuhlestein@gmail.com>
cc: pgsql-performance@postgresql.org
Subject: Re: Possible Redundancy/Performance Solution
In-Reply-To: <fvq189$2ej4$1@news.hub.org>
Message-ID: <Pine.GSO.4.64.0805061316340.3589@westnet.com>
References: <fvq189$2ej4$1@news.hub.org>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed

On Tue, 6 May 2008, Dennis Muhlestein wrote:

> First, I'd replace are sata hard drives with a scsi controller and two 
> scsi hard drives that run raid 0 (probably running the OS and logs on 
> the original sata drive).

RAID0 on two disks makes a disk failure that will wipe out the database 
twice as likely.  If you goal is better reliability, you want some sort of 
RAID1, which you can do with two disks.  That should increase read 
throughput a bit (not quite double though) while keeping write throughput 
about the same.

If you added four disks, then you could do a RAID1+0 combination which 
should substantially outperform your existing setup in every respect while 
also being more resiliant to drive failure.

> Our applications are mostly read intensive.  I don't think that having two 
> databases on one machine, where previously we had just one, would add too 
> much of an impact, especially if we use the load balance feature of pgpool as 
> well as the redundancy feature.

A lot depends on how much RAM you've got and whether it's enough to keep 
the cache hit rate fairly high here.  A reasonable thing to consider here 
is doing a round of standard performance tuning on the servers to make 
sure they're operating efficient before increasing their load.

> Can anyone comment on any gotchas or issues we might encounter?

Getting writes to replicate to multiple instances of the database usefully 
is where all the really nasty gotchas are in this area.  Starting with 
that part and working your way back toward the front-end pooling from 
there should crash you into the hard parts early in the process.

--
* Greg Smith gsmith@gregsmith.com http://www.gregsmith.com Baltimore, MD