Re: [PATCHES] default resource limits

Tom Lane wrote:

>daveg <daveg(at)sonic(dot)net> writes:
>
>
>>I don't understand the motivation for so many connections by default, it
>>seems wasteful in most cases.
>>
>>
>
>I think Andrew is thinking about database-backed Apache servers ...
>
>Some quick checks say that CVS tip's demand for shared memory increases
>by about 26kB per max_connection slot. (Almost all of this is lock table
>space; very possibly we could afford to decrease max_locks_per_connection
>when max_connections is large, to buy back some of that.) So boosting
>the default from 100 to 400 would eat an additional 7.8mB of shared
>memory if we don't do anything with max_locks_per_connection. This is
>probably not a lot on modern machines.
>
>A bigger concern is the increase in semaphores or whatever the local
>platform uses instead. I'd be *real* strongly tempted to bound the
>default at 100 on Darwin, for example, because on that platform each
>"semaphore" is an open file that has to be passed down to every backend.
>Uselessly large max_connections therefore slows backend launch and
>risks running the whole machine out of filetable slots. I don't know
>what the story is on Windows but it might have some problems with large
>numbers of semas too --- anyone know?
>
>Also, some more thought needs to be given to the tradeoff between
>shared_buffers and max_connections. Given a constrained SHMMAX value,
>I think the patch as-is will expend too much space on connections and
>not enough on buffers --- the "* 5" in test_connections() probably needs
>a second look.
>
>
>
>

All very good points. I didn't try to change the existing logic much.

I think we need to take this back to -hackers to get discussion on
tuning the way initdb selects the defaults.

Here are some questions:
. Do we want/need to make the behaviour platform specific?
. The patch put max_fsm_pages into the mix, and above it's suggested we
look at max_locks_per_connection. Is there anything else we should add?

My goal here is to pick reasonable defaults, not to tune the
installation highly. I think we tend to err on the side of being too
conservative today, but certainly it's possible to err the other way too.

cheers

andrew