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?



---------------------------(end of broadcast)---------------------------
TIP 6: explain analyze is your friend

Reply via email to