daveg wrote:
On Fri, Dec 23, 2005 at 03:38:56PM -0500, Andrew Dunstan wrote:
What numbers would you like? If what I suggested seems odd, how about
targets of 400 connections, 4000 shared_buffers and 200,000
max_fsm_pages?
Here's a patch that does what I had in mind. On my modest workstation it
tops out at 400 connections and 2500/125000
shared_buffers/max_fsm_pages. An idle postmaster with these settings
consumed less than 4% of the 380Mb of memory, according to top, making
it still dwarfed by X, mozilla, apache and amavisd among other memory hogs.
I don't understand the motivation for so many connections by default, it
seems wasteful in most cases.
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.
Here's why iot matters: during Hurricane Katrina, one web site that was
collecting details on people missing etc. found its application failing
because apache/php wanted more connections (out of the box) than the out
of the box postgres default. Luckily we were able to advise the operator
on how to fix it very quickly, but having these in some sort of sync
seems reasonable.
Of course, if you use connection pooling you can probably wind the
number back quite a lot.
There's no magic right answer - but on even entry level retail desktop
machines the extra used from this is now quite a small drop in the
memory bucket - the very lowest come with 256Mb of memory, and all but
the very lowest come with 512Mb or 1Gb. So why should we argue over a
handful of megabytes in raising limits last set 3 or 4 years ago?
cheers
andrew
---------------------------(end of broadcast)---------------------------
TIP 6: explain analyze is your friend
