From: Christian Elmerot <ce@one.com>
To: Kevin Grittner <Kevin.Grittner@wicourts.gov>
Cc: pgsql-performance@postgresql.org
Subject: Re: CPUs for new databases
Date: Tue, 26 Oct 2010 17:23:34 +0200
Message-ID: <4CC6F276.30603@one.com> (raw)
In-Reply-To: <4CC69F150200002500036E10@gw.wicourts.gov>
References: <4CC6CFAA.10107@one.com>
<4CC69F150200002500036E10@gw.wicourts.gov>
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
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-performance@postgresql.org
Cc: ce@one.com, Kevin.Grittner@wicourts.gov
Subject: Re: CPUs for new databases
In-Reply-To: <4CC6F276.30603@one.com>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox