Shaun Thomas <sthomas(at)peak6(dot)com> wrote:
> On 08/04/2011 03:38 PM, Kevin Grittner wrote:
>
>> You're probably going to get better performance by setting that
>> to 2 to 3 times the number of actual cores (don't county
>> hyperthreading for this purpose), and using a connection pooler
>> to funnel the 600 user connections down to a smaller number of
>> database connections.
>
> Your note about Hyperthreading *used* to be true. I'm not sure
> exactly what they did to the Intel nehalem cores, but
> hyperthreading actually seems to be much better now. It's not a
> true multiplier, but our pgbench scores were 40% to 60% higher
> with HT enabled up to at least 5x the number of cores.
Note that I didn't recommend not *using* HT, just not counting it
toward the core count for purposes of calculating how many active
connections to allow. The important question for this purpose isn't
whether you ran faster with HT enabled, but where you hit the knee
in the performance graph.
Did you actually run faster with 5x more active connections than
cores than with 3x more connections than cores? Was the load
hitting disk or running entirely from cache? If the former, what was
your cache hit rate and how many spindles did you have in what
configuration. I oversimplified slightly from the formula I
actually have been using based on benchmarks here, which is ((2 *
core_count) + effective_spindle_count. Mostly I simplified because
it's so hard to explain how to calculate an
"effective_spindle_count". ;-)
Anyway, I'm always willing to take advantage of the benchmarking
work of others, so I'm very curious about where performance topped
out for you with HT enabled, and whether disk waits were part of the
mix.
-Kevin