I think there's some confusion on this.

In SunOS 4.X, this is a parameter you have to recompile the kernel for.
If you're running 4.X, that's a real bummer.  There are several good
references on changing this parameter (the one below looks wildly
dangerous, but what the hey; that's what Perl is for), good luck.

In Solaris < 2.5.1 or so, this controlled by the ndd tunable
tcp_conn_req_max.  In > 2.5.1, this was split into tcp_conn_req_max_q and
tcp_conn_req_max_q0 to survive those nasty syn attacks.
tcp_conn_req_max_q is the one you want, which refers to "real" queued
connections.  I think it defaults to 128 or 1024, depending on what 2.X
you are running.  It can be read or retuned realtime as root:

  ndd -get /dev/tcp tcp_conn_req_max_q

and -set to change.

listen() lets one set the actual queue on the particular socket of
interest.  See man -s3socket listen for the gory details.  If one uses the
Perl IO::Socket::INET, the "Listen" parameter allows you to specify the
queue up to the max that the kernel is currently running.  The more
primitive Socket libraries don't seem to be so kind.  I actually don't
know what the default would be in perl in the older libraries.

Of course, this queue is per socket, not per process listening.  So, if 10
forked daemons are listening on a socket for connections, that's not
10*Listen, it's simply Listen for the total number in the queue.

There's an excellent document for lots of Solaris-based tuning worth
reading:

  http://www.sean.de/Solaris/soltune.htm

Cheers,

David.

-----

On Thu, 26 Feb 2004, Sidney Markowitz wrote:

> Justin Mason said:
> > I'm pretty sure (from my days as a solaris sysadmin) that it *is*
> > possible to increase the kernel-level limit.  This would be essential
> > to queue up processes, as we don't accept the conn until there's
> > a free child to process it.
>
> WARNING: The following method I discovered in a Google search is only for
> the strong of stomach or those of sufficiently little technical experience
> that a nauseatingly blecherous hack will just go over their heads:
>
> http://www.islandnet.com/~mark/somaxconn.html
>
> "Increasing SOMAXCONN
> This web page deals with the what, why, and how of altering the SOMAXCONN
> kernel parameter. I don't claim to be an expert on this, so don't freak
> out if I've got some of the theory wrong. All I know is that this worked
> for me. It may or may not work for you."
>
> Go there for details, I don't have the stomach to republish it here :-)
>
>  -- sidney
>
>
>
>
>

Reply via email to