Re: Postgres 8.4 memory related parameters - Mailing list pgsql-performance

From Kevin Grittner
Subject Re: Postgres 8.4 memory related parameters
Date
Msg-id 4E3ACA8C020000250003FB05@gw.wicourts.gov
Whole thread Raw
In response to Re: Postgres 8.4 memory related parameters  (Shaun Thomas <sthomas@peak6.com>)
Responses Re: Postgres 8.4 memory related parameters  (Shaun Thomas <sthomas@peak6.com>)
List pgsql-performance
Shaun Thomas <sthomas@peak6.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

pgsql-performance by date:

Previous
From: Scott Marlowe
Date:
Subject: Re: Suspected Postgres Datacorruption
Next
From: Shaun Thomas
Date:
Subject: Re: Postgres 8.4 memory related parameters