On Sat, Jun 16, 2001 at 01:02:15PM -0400, Tom Lane wrote:
> ncm@zembu.com (Nathan Myers) writes:
> > On Thu, Jun 14, 2001 at 01:42:26PM -0400, Tom Lane wrote:
> > This last could also be addressed (along with Solaris's Unix Sockets
> > problem!) by changing the second argument to listen(2) from the current
> > SOMAXCONN -- which is 5 in Solaris 2.7 -- to 127. See the six-page
> > discussion in Stevens UNPv1 beginning at page 93.
>
> Unfortunately I only have Stevens' first edition, and it doesn't seem
> to have any such advice in it. Why is it a good idea to ignore the
> platform's specification of SOMAXCONN? Seems like on non-broken
> platforms, that would do more harm than good.
The second edition is easily worth the price, for any number of reasons.
Do you want me to type in all six pages? (I'll fax you a copy if you
ask.) He includes graphs of sample daemon transaction rates for
different settings of that argument, from SOMAXCONN on up, as well
as analyses of what is going on, including diagrams.
The short description is that half-completed connections occupy
a sort of foyer or vestibule (my terms). The second argument to
listen(2), usually called "backlog", is defined vaguely in Posix
and therefore has various meanings on different systems, but is
supposed to limit how many half-open connections are allowed to
wait there.
I don't have the book at home, but IIRC, Solarix's interpretation
is unusually strict, which causes it to reject connections much
more aggressively for a given value. Independently of that, the
low value that was originally suggested just turned out to be a
bad guess. The mistake got worse as longer, fatter pipes got
deployed and protocols that did more opens got popular.
Posix says that a backlog value more than the platform's maximum
gets folded, so there is no danger in exceeding it. On Solaris 2.7,
SOMAXCONN is still 5 in the headers, but larger values are both legal
and effective. A parameter might reasonably be added to the config
file to crank the backlog value down on installations where kernel
memory is scarce and other daemons must compete with PG for connection
resources.
I have seen reports that it is this strict interpretation, and the
too-low backlog passed to listen(2), that accounts for reports of
Unix sockets working poorly on Solaris. (Certainly it is hard to
believe that Sun could not make their Unix sockets work right!)
Nathan Myers
ncm@zembu.com
