Re: Solaris/SOMAXCONN

[Justin Mason <jm...@jmason.org>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1


"Owen McShane" writes:
>Hi,
>
>we are using SA 2.63 on Solaris 7 for sparc, with perl 5.8.0 and exim 4.04 This is with spamc/spamd.
>
>This is for our internal staff mail server, which receives a lot of spam.
>
>So far SA is only scanning mail for a handful of users, but we have found the load placed on the server to be quite high.
>
>We have tried to get around this by using spamd -m 10 to limit the max number of children to 10.
>
>My understanding of this is that once this limit is reached, the remaining mails are queued until a child process is freed up.
>
>The number of queued mails depends on the (OS specific) value of SOMAXCONN
>
>On Solaris, this value appears to be '5'(?!), as defined in /usr/include/sys/socket.h
>
># perl -MSocket -e'print SOMAXCONN'
>5# 
>
>Whereas on Redhat Linux 9, it is 128:
>
>[owen@bass owen]$ perl -MSocket -e'print SOMAXCONN'
>128
>
>Obviously Solaris is quite capable of handling more open sockets than 5, so my question is does spamd actually use the value returned by perl? Should it not use some other variable?

Hi Owen --

I'm pretty sure it's easy enough to increase this value, using
either ulimit or a kernel parameter.  can't remember how, though ;)

- --j.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)
Comment: Exmh CVS

iD8DBQFAO5ZiQTcbUG5Y7woRAjFhAJ0SFrPyugRb3OTsyRAsMgKPsMk/vACggc+R
0pncFoydT/VCRQ/I/7A9qCI=
=aRQ/
-----END PGP SIGNATURE-----

Re: Solaris/SOMAXCONN

[Theo Van Dinter <fe...@kluge.net>]

On Wed, Feb 25, 2004 at 11:14:12PM -0500, David Birnbaum wrote:
> There's an excellent document for lots of Solaris-based tuning worth
> reading:
> 
>   http://www.sean.de/Solaris/soltune.htm

404 - Document not found.   :(

Thankfully the fix is simple:

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

-- 
Randomly Generated Tagline:
"The liberty of a democracy is not safe if the people tolerate the
 growth of private power to the point where it becomes stronger than the
 democratic state itself. That in its essence is fascism Ñ ownership of
 government by an individual, by a group or any controlling private power."
                                 - President Franklin D. Roosevelt 

Re: Solaris/SOMAXCONN

[David Birnbaum <da...@pins.net>]

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
>
>
>
>
>

Re: Solaris/SOMAXCONN

[Sidney Markowitz <si...@sidney.com>]

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

Re: Solaris/SOMAXCONN

[Duncan Findlay <du...@debian.org>]

On Wed, Feb 25, 2004 at 01:10:23PM +0000, Owen McShane wrote:
> I've been looking into this for a while now, and it would seem that it is not that tunable.
> 
> Can any SA developers tell me if spamd will actually start freaking out after it's queued 5 connections over the max-children limit?
> 
> If it does, would replacing all references to SOMAXCONN in spamd with a pre-defined variable (1024 say) be adhered to?

I think it's an OS specific thing -- Solaris will not queue more
connections than SOMAXCONN. You can try it, I just don't know if it
will work.

-- 
Duncan Findlay