Skip site navigation (1) Skip section navigation (2)

Re: Master/Slave, DB separation or just spend $$$?

From: David Rees <drees76(at)gmail(dot)com>
To: Kelvin Quee <kelvinq(at)gmail(dot)com>
Cc: Scott Marlowe <scott(dot)marlowe(at)gmail(dot)com>, pgsql-performance(at)postgresql(dot)org, JiaYi Lee <leejiayi(at)gmail(dot)com>, lim(dot)ck(dot)michael(at)gmail(dot)com, elias(dot)soong(at)gmail(dot)com
Subject: Re: Master/Slave, DB separation or just spend $$$?
Date: 2009-07-22 19:29:25
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-performance
On Wed, Jul 22, 2009 at 12:52 AM, Kelvin Quee<kelvinq(at)gmail(dot)com> wrote:
> I have been staring at *top* for a while and it's mostly been 40% in
> userspace and 30% in system. Wait is rather low and never ventures
> beyond 1%.

Certainly seems like you are CPU bound.

> My hardware is a duo core AMD Athlon64 X2 5000+, 1GB RAM and a single
> 160 GB SATA II hard disk drive.

Looks like you are on a budget as Scott also suggested - I would also
mirror his recommendation to upgrade to a quad core processor and more
memory.  Hopefully your motherboard supports quad-cores so you don't
have to replace that bit, and you should be able to get at least 4GB
of RAM in there.

If IO load becomes an issue, Velociraptors are fast and don't cost too
much.  Getting a basic RAID1 will help prevent data-loss due to disk
failure - make sure you are making offline backups as well!

> I will go look at Slony now.
> Scott, one question though - If my master is constantly changing,
> wouldn't the updates from the master to the slave also slow down the
> slave?

Yes - Slony will increase the load on your source node as it does take
work to do the replication, so unless you are able to offload your CPU
heavy read only queries to the slave machine, it will only bog down
the source node more.


In response to

pgsql-performance by date

Next:From: Lauris UlmanisDate: 2009-07-23 10:47:47
Subject: Postgres user authentification or LDAP authentification
Previous:From: Victor de BuenDate: 2009-07-22 18:28:23
Subject: Re: Atomic access to large arrays

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group