To: pgsql-performance@postgresql.org
From: Ivan Voras <ivoras@freebsd.org>
Subject: Re: CPUs for new databases
Date: Wed, 27 Oct 2010 02:18:43 +0200
Lines: 27
Message-ID: <ia7r55$5ih$1@dough.gmane.org>
References: <4CC6CFAA.10107@one.com>
	<AANLkTi=ScGQiHB2ch+C_+K14TgjaO_3+x0+28QOFYeUU@mail.gmail.com>
	<4CC73FEF.9020805@agliodbs.com>
	<m3ocagplgf.fsf@jhcloos.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US;
	rv:1.9.2.9) Gecko/20101008 Thunderbird/3.1.4
In-Reply-To: <m3ocagplgf.fsf@jhcloos.com>

On 10/27/10 01:45, James Cloos wrote:
>>>>>> "JB" == Josh Berkus<josh@agliodbs.com>  writes:
>
> JB>  In a general workload, fewer faster cores are better.  We do not scale
> JB>  perfectly across cores.  The only case where that's not true is
> JB>  maintaining lots of idle connections, and that's really better dealt
> JB>  with in software.
>
> I've found that ram speed is the most limiting factor I've run into for
> those cases where the db fits in RAM.  The less efficient lookups run
> just as fast when the CPU is in powersving mode as in performance, which
> implies that the cores are mostly waiting on RAM (cache or main).
>
> I suspect cache size and ram speed will be the most important factors
> until the point where disk i/o speed and capacity take over.

FWIW, yes - once the IO is fast enough or not necessary (e.g. the 
read-mostly database fits in RAM), RAM bandwidth *is* the next 
bottleneck and it really, really can be observed in actual loads. Buying 
a QPI-based CPU instead of the cheaper DMI-based ones (if talking about 
Intel chips), and faster memory modules (DDR3-1333+) really makes a 
difference in this case.

(QPI and DMI are basically the evolution the front side bus; AMD had HT 
- HyperTransport for years now. Wikipedia of course has more information 
for the interested.)