Re: Re: SOMAXCONN
От | ncm@zembu.com (Nathan Myers) |
---|---|
Тема | Re: Re: SOMAXCONN |
Дата | |
Msg-id | 20010713074013.B32438@store.zembu.com обсуждение исходный текст |
Ответ на | AW: Re: SOMAXCONN (was Re: Solaris source code) (Zeugswetter Andreas SB <ZeugswetterA@wien.spardat.at>) |
Список | pgsql-hackers |
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@zembu.com
В списке pgsql-hackers по дате отправления: