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

Re: [PERFORM] Quad processor options

From: Bjoern Metzdorf <bm(at)turtle-entertainment(dot)de>
To: "scott(dot)marlowe" <scott(dot)marlowe(at)ihs(dot)com>
Cc: pgsql-performance(at)postgresql(dot)org,"Pgsql-Admin (E-mail)" <pgsql-admin(at)postgresql(dot)org>
Subject: Re: [PERFORM] Quad processor options
Date: 2004-05-11 20:41:28
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-adminpgsql-performance
scott.marlowe wrote:

> Well, from what I've read elsewhere on the internet, it would seem the 
> Opterons scale better to 4 CPUs than the basic Xeons do.  Of course, the 
> exception to this is SGI's altix, which uses their own chipset and runs 
> the itanium with very good memory bandwidth.

This is basically what I read too. But I cannot spent money on a quad 
opteron just for testing purposes :)

> But, do you really need more CPU horsepower?
> Are you I/O or CPU or memory or memory bandwidth bound?  If you're sitting 
> at 99% idle, and iostat says your drives are only running at some small 
> percentage of what you know they could, you might be memory or memory 
> bandwidth limited.  Adding two more CPUs will not help with that 
> situation.

Right now we have a dual xeon 2.4, 3 GB Ram, Mylex extremeraid 
controller, running 2 Compaq BD018122C0, 1 Seagate ST318203LC and 1 
Quantum ATLAS_V_18_SCA.

iostat show between 20 and 60 % user avg-cpu. And this is not even peak 

I attached a "vmstat 10 120" output for perhaps 60-70% peak load.

> If your I/O is saturated, then the answer may well be a better RAID 
> array, with many more drives plugged into it.  Do you have any spare 
> drives you can toss on the machine to see if that helps?  Sometimes going 
> from 4 drives in a RAID 1+0 to 6 or 8 or more can give a big boost in 
> performance.

Next drives I'll buy will certainly be 15k scsi drives.

> In short, don't expect 4 CPUs to solve the problem if the problem isn't 
> really the CPUs being maxed out.
> Also, what type of load are you running?  Mostly read, mostly written, few 
> connections handling lots of data, lots of connections each handling a 
> little data, lots of transactions, etc...

In peak times we can get up to 700-800 connections at the same time. 
There are quite some updates involved, without having exact numbers I'll 
think that we have about 70% selects and 30% updates/inserts.

> If you are doing lots of writing, make SURE you have a controller that 
> supports battery backed cache and is configured to write-back, not 
> write-through.

Could you recommend a certain controller type? The only battery backed 
one that I found on the net is the newest model from


Attachment: vmstat.txt
Description: text/plain (1.3 KB)

In response to


pgsql-performance by date

Next:From: Bjoern MetzdorfDate: 2004-05-11 20:45:13
Subject: Re: [PERFORM] Quad processor options
Previous:From: Anjan DaveDate: 2004-05-11 20:38:28
Subject: Re: [PERFORM] Quad processor options

pgsql-admin by date

Next:From: Bjoern MetzdorfDate: 2004-05-11 20:45:13
Subject: Re: [PERFORM] Quad processor options
Previous:From: Tom LaneDate: 2004-05-11 20:39:19
Subject: Re: download problems

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