The soft load shedding idea is great.
Along the lines of "lots of idle connections" is the issue with the simple
number of connections. I suspect in most real world apps you'll have
logic+web serving on a set of frontends talking to a single db backend
(until clustering is really nailed).
The issue we hit is that if we all the frontends have 250 maxclients, the
number on the backend goes way up.
This falls in the connection pooling realm, and could be implemented with
the client lib presenting a server view, so apps would simply treat the
pooler as a local server which would allocate connections as needed from a
pool of persistent connections. This also has a benefit in cases (cgi) where
persistent connections cannot be maintained properly. I suspect we've got a
10% duty cycle on the persistent connections we set up... This problem is
predicated on the idea that holding a connection is not negligible (i.e.,
5,000 connections open is worse than 200) for the same loads. Not sure if
that's the case...
AZ
"Nathan Myers" <[EMAIL PROTECTED]> wrote in message
[EMAIL PROTECTED]">news:[EMAIL PROTECTED]...
> On Mon, Apr 23, 2001 at 03:09:53PM -0300, The Hermit Hacker wrote:
> >
> > Anyone thought of implementing this, similar to how sendmail does it?
If
> > load > n, refuse connections?
> > ...
> > If nobody is working on something like this, does anyone but me feel
that
> > it has merit to make use of? I'll play with it if so ...
>
> I agree that it would be useful. Even more useful would be soft load
> shedding, where once some load average level is exceeded the postmaster
> delays a bit (proportionately) before accepting a connection.
>
> Nathan Myers
> [EMAIL PROTECTED]
>
> ---------------------------(end of broadcast)---------------------------
> TIP 4: Don't 'kill -9' the postmaster
---------------------------(end of broadcast)---------------------------
TIP 6: Have you searched our list archives?
http://www.postgresql.org/search.mpl
