[moving to -hackers]
Peter Eisentraut wrote:
>Am Samstag, 24. Dezember 2005 00:20 schrieb Andrew Dunstan:
>
>
>>The rationale is one connection per apache thread (which on Windows
>>defaults to 400). If people think this is too many I could live with
>>winding it back a bit - the defaults number of apache workers on Unix is
>>250, IIRC.
>>
>>
>
>It's 150. I don't mind increasing the current 100 to 150, although I find
>tying this to apache pretty bogus.
>
>
According to
http://httpd.apache.org/docs/2.0/mod/mpm_common.html#maxclients the
default for the prefork MPM, which is the default on Unix, is 256. 400
appears to be what is used for hybrid MPMs like worker, which is not the
default for any platform. The default Windows MPM (mpm_winnt) is
apparently governed by the ThreadsPerChild setting, which defaults to
64, not 400 as I previously stated.
>I really don't like the prospect of making the defaults platform specific,
>especially if the only rationale for that would be "apache does it". Why
>does apache allocate more connections on Windows anyway?
>
>
>
It uses a *very* different engine.
Maybe referring to apache is not ideal, although playing nicely with a
very common client doesn't strike me as totally bogus either.
But what is the rationale for the current settings, or for anything else
that might be proposed? I have yet to hear any. Is there anyone who
thinks that 1000/20000 for shared_buffers/max_fsm_pages is a good set of
defaults?
Maybe we need to split this into two pieces, given Tom's legitimate
concern about semaphore use. How about we increase the allowed range for
shared_buffers and max_fsm_pages, as proposed in my patch, and leave the
max_connections issue on the table? I also wondered if instead of first
setting max_connections and then shared_buffers/max_fsm_pages, we should
try to scale them in synch somehow.
cheers
andrew