On 08/05/2011 09:58 AM, Kevin Grittner wrote:
What I'm saying is that if processes are blocked waiting for disk they are not going to be using CPU, and there is room for that many additional processes to be useful, as the CPUs and other drives would otherwise be sitting idle.
Haha. The way you say that made me think back on the scenario with 4 cpus and 1 disk. Naturally that kind of system is IO starved, and will probably sit at IO-wait at 10% or more on any kind of notable activity level. I was like... "Well, so long as everything is waiting anyway, why not just increase it to 100?"
Now, typically you want to avoid context switching. Certain caveats need to be made for anything with less than two, or even four cpus because of various system and Postgres monitoring/maintenance threads. My own benchmarks illustrate (to me, anyway) that generally, performance peaks when PG threads equal CPU threads *however they're supplied*.
Never minding fudge factor for idling connections waiting on IO, which you said yourself can be problematic the more of them there are. :)
I'd say just put it at 2x, maybe 3x, and call it good. Realistically you won't really notice further tweaking, and a really active system would converge to cpu count through a pooler and be cached to the gills anyway.
-- Shaun Thomas OptionsHouse | 141 W. Jackson Blvd. | Suite 800 | Chicago IL, 60604 312-676-8870 sthomas@xxxxxxxxx ______________________________________________ See http://www.peak6.com/email_disclaimer.php for terms and conditions related to this email -- Sent via pgsql-performance mailing list (pgsql-performance@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-performance
