Re: AW: Re: SOMAXCONN (was Re: Solaris source code)

From: mlw <markw(at)mohawksoft(dot)com>
To: Zeugswetter Andreas SB <ZeugswetterA(at)wien(dot)spardat(dot)at>
Cc: "'ncm(at)zembu(dot)com'" <ncm(at)zembu(dot)com>, "'pgsql-hackers(at)postgresql(dot)org'" <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: AW: Re: SOMAXCONN (was Re: Solaris source code)
Date: 2001-07-13 11:53:02
Message-ID: 3B4EE11E.739374AE@mohawksoft.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

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 ?
>
> > 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.
>
> I liked the idea of min(MaxBackends, PG_SOMAXCONN), since there is no use in
> accepting more than your total allowed connections concurrently.
>
> Andreas

I have been following this thread and I am confused why the queue argument to
listen() has anything to do with Max backends. All the parameter to listen does
is specify how long a list of sockets open and waiting for connection can be.
It has nothing to do with the number of back end sockets which are open.

If you have a limit of 128 back end connections, and you have 127 of them open.
A listen with queue size of 128 will still allow 128 sockets to wait for
connection before turning others away.

It should be a parameter based on the time out of a socket connection vs the
ability to answer connection requests within that period of time.

There are two was to think about this. Either you make this parameter tunable
to give a proper estimate of the usability of the system, i.e. tailor the
listen queue parameter to reject sockets when some number of sockets are
waiting, or you say no one should ever be denied, accept everyone and let them
time out if we are not fast enough.

This debate could go on, why not make it a parameter in the config file that
defaults to some system variable, i.e. SOMAXCONN.

BTW: on linux, the backlog queue parameter is silently truncated to 128 anyway.

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Doug McNaught 2001-07-13 13:16:35 Re: select count...
Previous Message Zeugswetter Andreas SB 2001-07-13 08:36:13 AW: Re: SOMAXCONN (was Re: Solaris source code)