From: | "scott(dot)marlowe" <scott(dot)marlowe(at)ihs(dot)com> |
---|---|
To: | Hilary Forbes <hforbes(at)dmr(dot)co(dot)uk> |
Cc: | <pgsql-performance(at)postgresql(dot)org> |
Subject: | Re: Processors vs Memory |
Date: | 2003-10-22 16:36:10 |
Message-ID: | Pine.LNX.4.33.0310221031481.12830-100000@css120.ihs.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-performance |
On Wed, 22 Oct 2003, Hilary Forbes wrote:
> If I have a fixed amount of money to spend as a general rule is it
> better to buy one processor and lots of memory or two processors and
> less memory for a system which is transactional based (in this case
> it's handling reservations). I realise the answer will be a generalised
> one but all the performance bits I've read seem to talk about adjusting
> memory allocation. The client has received the general advice from
> their hardware supplier that 2 Xeon processors and less memory is better
> but for postgresql I'm thinking they might be better off with a single
> processor and loads of memory. The OS is Red Hat Linux.
My opinion is that two CPUs is optimal because it allows the OS to operate
in parallel to the database. After the second CPU, the only advantage is
if you are doing a lot of parallel access.
Go for fast I/O first, a RAID1+0 setup is optimal for smaller numbers of
drives (works on 4 or 6 drives nicely) and RAID5 is optimal for a larger
number of drives (works well on 10 or more drives). Always use hardware
RAID with battery backed cache for a heavily updated database. For a
reports database software RAID is quite acceptable.
There's a limit to how much memory you can throw at the problem if you're
on 32 bit hardware, and that limit is about 2 to 4 gig. While you can
install more, it usually makes little or no difference.
Lastly, don't forget to tune your database and server once you have it up
and running:
http://www.varlena.com/varlena/GeneralBits/Tidbits/perf.html
From | Date | Subject | |
---|---|---|---|
Next Message | Josh Berkus | 2003-10-22 16:58:28 | Re: Low Insert/Update Performance |
Previous Message | Josh Berkus | 2003-10-22 16:27:49 | Re: Low Insert/Update Performance |