Message-ID: <4CC6F276.30603@one.com>
Date: Tue, 26 Oct 2010 17:23:34 +0200
From: Christian Elmerot <ce@one.com>
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US;
	rv:1.9.2.11) Gecko/20101006 Thunderbird/3.1.5
MIME-Version: 1.0
To: Kevin Grittner <Kevin.Grittner@wicourts.gov>
CC: pgsql-performance@postgresql.org
Subject: Re: CPUs for new databases
References: <4CC6CFAA.10107@one.com>
 <4CC69F150200002500036E10@gw.wicourts.gov>
In-Reply-To: <4CC69F150200002500036E10@gw.wicourts.gov>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

On 2010-10-26 16:27, Kevin Grittner wrote:
> Christian Elmerot<ce@one.com>  wrote:
>
>> What is the general view of performance CPU's nowadays when it
>> comes to PostgreSQL performance? Which CPU is the better choice,
>> in regards to RAM access-times, stream speed, cache
>> synchronization etc. Which is the better CPU given the limitation
>> of using AMD64 (x86-64)?
>
> You might want to review recent posts by Greg Smith on this.  One
> such thread starts here:
>
> http://archives.postgresql.org/pgsql-performance/2010-09/msg00120.php

I've read those posts before and they are interresting but only part of 
the puzzle.


>   
>> We're getting ready to replace our (now) aging db servers with
>> some brand new with higher core count. The old ones are 4-socket
>> dual-core Opteron 8218's with 48GB RAM. Right now the disk-subsystem
>> is not the limiting factor so we're aiming for higher core-count
>> and as well as faster and more RAM. We're also moving into the
>> territory of version 9.0 with streaming replication to be able to
>> offload at least a part of the read-only queries to the slave
>> database. The connection count on the database usually lies in the
>> region of ~2500 connections and the database is small enough that
>> it can be kept entirely in RAM (dump is about 2,5GB).
>
> You really should try connection pooling.  Even though many people
> find it counterintuitive, it is likely to improve both throughput
> and response time significantly.  See any of the many previous
> threads on the topic for reasons.

I believe you are right as this is actually something we're looking into 
as we're making read-only queries pass through a dedicated set of 
lookup-hosts as well as having writes that are not time critical to pass 
through another set of hosts.

Regards,
Christian Elmerot