Re: Re: SOMAXCONN

On Fri, Jul 13, 2001 at 10:36:13AM +0200, Zeugswetter Andreas SB wrote:
>
> > When the system is too heavily loaded (however measured), any further
> > login attempts will fail. What I suggested is, instead of the
> > postmaster accept()ing the connection, why not leave the connection
> > attempt in the queue until we can afford a back end to handle it?
>
> Because the clients would time out ?

It takes a long time for half-open connections to time out, by default.
Probably most clients would time out, themselves, first, if PG took too
long to get to them. That would be a Good Thing.

Once the SOMAXCONN threshold is reached (which would only happen when
the system is very heavily loaded, because when it's not then nothing
stays in the queue for long), new connection attempts would fail
immediately, another Good Thing. When the system is very heavily
loaded, we don't want to spare attention for clients we can't serve.

> > Then, the argument to listen() will determine how many attempts can
> > be in the queue before the network stack itself rejects them without
> > the postmaster involved.
>
> You cannot change the argument to listen() at runtime, or are you suggesting
> to close and reopen the socket when maxbackends is reached ? I think
> that would be nonsense.

Of course that would not work, and indeed nobody suggested it.

If postmaster behaved a little differently, not accept()ing when
the system is too heavily loaded, then it would be reasonable to
call listen() (once!) with PG_SOMAXCONN set to (e.g.) N=20.

Where the system is not too heavily-loaded, the postmaster accept()s
the connection attempts from the queue very quickly, and the number
of half-open connections never builds up to N. (This is how PG has
been running already, under light load -- except that on Solaris with
Unix sockets N has been too small.)

When the system *is* heavily loaded, the first N attempts would be
queued, and then the OS would automatically reject the rest. This
is better than accept()ing any number of attempts and then refusing
to authenticate. The N half-open connections in the queue would be
picked up by postmaster as existing back ends drop off, or time out
and give up if that happens too slowly.

> I liked the idea of min(MaxBackends, PG_SOMAXCONN), since there is no
> use in accepting more than your total allowed connections concurrently.

That might not have the effect you imagine, where many short-lived
connections are being made. In some cases it would mean that clients
are rejected that could have been served after a very short delay.

Nathan Myers
ncm(at)zembu(dot)com