Re: Postgres 8.4 memory related parameters

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(at)peak6(dot)com

______________________________________________

See http://www.peak6.com/email_disclaimer.php
for terms and conditions related to this email