Re: SOMAXCONN (was Re: Solaris source code) - Mailing list pgsql-hackers
From | mlw |
---|---|
Subject | Re: SOMAXCONN (was Re: Solaris source code) |
Date | |
Msg-id | 3B50318A.75BEA041@mohawksoft.com Whole thread Raw |
In response to | AW: Re: SOMAXCONN (was Re: Solaris source code) (Zeugswetter Andreas SB <ZeugswetterA@wien.spardat.at>) |
Responses |
Re: SOMAXCONN (was Re: Solaris source code)
|
List | pgsql-hackers |
Tom Lane wrote: > > mlw <markw@mohawksoft.com> writes: > > Nathan Myers wrote: > >> But using SOMAXCONN blindly is always wrong; that is often 5, which > >> is demonstrably too small. > > > It is rumored that many BSD version are limited to 5. > > BSD systems tend to claim SOMAXCONN = 5 in the header files, but *not* > to have such a small limit in the kernel. The real step forward that > we have made in this discussion is to realize that we cannot trust > <sys/socket.h> to tell us what the kernel limit actually is. > > > Passing listen(5) would probably be sufficient for Postgres. > > It demonstrably is not sufficient. Set it that way in pqcomm.c > and run the parallel regression tests. Watch them fail. > That's interesting, I would not have guessed that. I have written a number of server applications which can handle, litterally, over a thousand connection/operations a second, which only has a listen(5). (I do have it as a configuration parameter, but have never seen a time when I have had to change it.) I figured the closest one could come to an expert in all things socket related would have to be the Apache web server source. They have a different take on the listen() parameter: >>>>> from httpd.h >>>>>>>>>>> 402 /* The maximum length of the queue of pending connections, as defined 403 * by listen(2). Under some systems, it should be increased if you 404 * are experiencing a heavy TCP SYN flood attack. 405 * 406 * It defaults to 511 instead of 512 because some systems store it 407 * as an 8-bit datatype; 512 truncatedto 8-bits is 0, while 511 is 408 * 255 when truncated. 409 */ 410 411 #ifndef DEFAULT_LISTENBACKLOG 412 #define DEFAULT_LISTENBACKLOG 511 413 #endif <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< I have not found any other location in which DEFAULT_LISTENBACKLOG is defined, but it is a configuration parameter, and here is what the Apache docs claim: >>>>>>>>>>>> http://httpd.apache.org/docs/mod/core.html >>>>>>>>>>>> ListenBacklog directive Syntax: ListenBacklog backlog Default: ListenBacklog 511 Context: server config Status: Core Compatibility: ListenBacklog is only available in Apache versions after 1.2.0. The maximum length of the queue of pending connections. Generally no tuning is needed or desired, however on some systems it is desirable to increase this when under a TCP SYN flood attack. See the backlog parameter to the listen(2) system call. This will often be limited to a smaller number by the operating system. This varies from OS to OS. Also note that many OSes do not use exactly what is specified as the backlog, but use a number based on (but normally larger than) what is set. <<<<<<<<<<<<<<<<<<<<<<< Anyway, why not just do what apache does, set it to some extreme default setting, which even when truncated, is still pretty big, and allow the end user to change this value in postgresql.conf.
pgsql-hackers by date: