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
