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

Поиск
Список
Период
Сортировка
От mlw
Тема Re: AW: Re: SOMAXCONN (was Re: Solaris source code)
Дата
Msg-id 3B4EE11E.739374AE@mohawksoft.com
обсуждение исходный текст
Ответ на AW: Re: SOMAXCONN (was Re: Solaris source code)  (Zeugswetter Andreas SB <ZeugswetterA@wien.spardat.at>)
Ответы Re: SOMAXCONN (was Re: Solaris source code)  (ncm@zembu.com (Nathan Myers))
Список 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.


В списке pgsql-hackers по дате отправления:

Предыдущее
От: Zeugswetter Andreas SB
Дата:
Сообщение: AW: Re: SOMAXCONN (was Re: Solaris source code)
Следующее
От: Doug McNaught
Дата:
Сообщение: Re: select count...