From: | Andrew Dunstan <andrew(at)dunslane(dot)net> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
Cc: | daveg <daveg(at)sonic(dot)net> |
Subject: | Re: [PATCHES] default resource limits |
Date: | 2005-12-23 23:58:22 |
Message-ID: | 43AC8F1E.9020209@dunslane.net |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers pgsql-patches |
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
From | Date | Subject | |
---|---|---|---|
Next Message | Qingqing Zhou | 2005-12-24 02:37:42 | Re: [Bizgres-general] WAL bypass for INSERT, UPDATE and |
Previous Message | Tom Lane | 2005-12-23 23:38:39 | Re: PLs and domain constraints |
From | Date | Subject | |
---|---|---|---|
Next Message | Tatsuo Ishii | 2005-12-24 00:27:23 | Re: [BUGS] BUG #2120: Crash when doing UTF8<->ISO_8859_8 |
Previous Message | Tom Lane | 2005-12-23 23:22:36 | Re: default resource limits |