Skip site navigation (1) Skip section navigation (2)

Re: refusing connections based on load ...

From: "August Zajonc" <augustz(at)bigfoot(dot)com>
To: pgsql-hackers(at)postgresql(dot)org
Subject: Re: refusing connections based on load ...
Date: 2001-04-23 20:45:25
Message-ID: 9c2496$1eg2$ (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers
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...


"Nathan Myers" <ncm(at)zembu(dot)com> wrote in message
> 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?
> > load > n, refuse connections?
> > ...
> > If nobody is working on something like this, does anyone but me feel
> > 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
> ncm(at)zembu(dot)com
> ---------------------------(end of broadcast)---------------------------
> TIP 4: Don't 'kill -9' the postmaster

In response to

pgsql-hackers by date

Next:From: Peter EisentrautDate: 2001-04-23 21:20:23
Subject: Re: SET SESSION AUTHORIZATION (was Re: Real/effective user)
Previous:From: Jan WieckDate: 2001-04-23 20:00:19
Subject: Re: refusing connections based on load ...

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group