On 10/27/10 01:45, James Cloos wrote:
"JB" == Josh Berkus<josh@xxxxxxxxxxxx> 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.)
--
Sent via pgsql-performance mailing list (pgsql-performance@xxxxxxxxxxxxxx)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-performance
