From: | Ivan Voras <ivoras(at)freebsd(dot)org> |
---|---|
To: | pgsql-performance(at)postgresql(dot)org |
Subject: | Re: CPUs for new databases |
Date: | 2010-10-27 00:18:43 |
Message-ID: | ia7r55$5ih$1@dough.gmane.org |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-performance |
On 10/27/10 01:45, James Cloos wrote:
>>>>>> "JB" == Josh Berkus<josh(at)agliodbs(dot)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.)
From | Date | Subject | |
---|---|---|---|
Next Message | Scott Marlowe | 2010-10-27 01:14:26 | Re: CPUs for new databases |
Previous Message | James Cloos | 2010-10-26 23:45:12 | Re: CPUs for new databases |