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

Re: 8 way Intel Xeon system

From: "Shridhar Daithankar" <shridhar_daithankar(at)persistent(dot)co(dot)in>
To: pgsql-performance(at)postgresql(dot)org
Subject: Re: 8 way Intel Xeon system
Date: 2003-08-27 07:00:33
Message-ID: 3F4CA469.27749.32D48FD@localhost (view raw, whole thread or download thread mbox)
Lists: pgsql-performance
On 27 Aug 2003 at 14:07, Castle, Lindsay wrote:
> I'm mainly interested in what I should concentrate on from a
> Linux/PostgreSQL config point of view to see if we can take advantage of the
> extra CPUs. - Yes it's overkill but this is a piece of surplus hardware we
> don't have to buy.

First of all whatever you do, add multiple connections using a middle layer. 
That will keep your CPU busy. 

Of course there are few things need to be done over single connection but this 
should help at least in some scenarios.
> Perhaps some may say Linux isn't the best option for an 8 CPU server but
> this is what I have to work with for reasons we won't get into :-)

I think if you can afford a performance benchmark trial, give 2.6.0-testx a 
try. They should be much better than 2.4.x.
> The current usage is along the lines of a few thousands updates spread over
> the space of a few hours in the morning then followed by a thousand select
> queries to do some reporting.

In case of such IO intensive and update/delete heavy load, might be a good idea 
to move WAL to a separate SCSI channel. I believe merely moving it to another 
drive would not yield as much boost.

> Currently RedHat 9 with PostgreSQL 7.3.2 installed.

Get 7.4CVS head. and don't forget to use a autovacuum daemon. It's in contrib 



Ogden's Law:	The sooner you fall behind, the more time you have to catch up.

In response to

pgsql-performance by date

Next:From: Ron JohnsonDate: 2003-08-27 08:12:31
Subject: Re: Replication Ideas
Previous:From: Shridhar DaithankarDate: 2003-08-27 06:54:40
Subject: Re: Sun vs a P2. Interesting results.

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