Tom Lane wrote:
>Andrew Dunstan <andrew@dunslane.net> writes:
>
>
>>I accept the "run from init.d" argument. So then, is there a case for
>>increasing the limits that initdb works with, to reflect the steep rise
>>we have seen in typically available memory at the low end?
>>
>>
>
>I can't see any particular harm in having initdb try somewhat-larger
>values ... but how far does that really go towards fixing the issues?
>
>Personally, the default value I currently see as far too tight is
>max_fsm_pages. I'd rather see initdb trying to push that up if it's
>able to establish shared_buffers and max_connections at their current
>maxima.
>
>
>
Ok. how would the logic go? Just have a function that runs max_fsm_pages
checks after we call test_connections() and test_buffers(), or should
there be some interplay between those settings? As I understand it, the
current setting would consume all of 120,000 bytes of shared memory, so
there could well be lots of head room.
>>... it would be nice to try to allow
>>one connection per standard allowed apache client (default is 256
>>non-threaded and 400 threaded, I think).
>>
>>
>
>That's a mostly independent consideration, but it seems fair enough.
>Can we check the exact values rather than relying on "I think"?
>
>
That's my reading of
http://httpd.apache.org/docs/2.0/mod/mpm_common.html#maxclients