Shaun Thomas <sthomas@xxxxxxxxx> 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 -- Sent via pgsql-performance mailing list (pgsql-performance@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-performance
