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

Re: CPUs for new databases

From: Christian Elmerot <ce(at)one(dot)com>
To: Kevin Grittner <Kevin(dot)Grittner(at)wicourts(dot)gov>
Cc: pgsql-performance(at)postgresql(dot)org
Subject: Re: CPUs for new databases
Date: 2010-10-26 15:23:34
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-performance
On 2010-10-26 16:27, Kevin Grittner wrote:
> Christian Elmerot<ce(at)one(dot)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:

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.

Christian Elmerot

In response to

pgsql-performance by date

Next:From: Merlin MoncureDate: 2010-10-26 15:41:59
Subject: Re: Postgres insert performance and storage requirement compared to Oracle
Previous:From: Leonardo FrancalanciDate: 2010-10-26 15:08:20
Subject: Re: Postgres insert performance and storage requirement compared to Oracle

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