Re: sysctl kern.ipc.somaxconn limit 65535 why?

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On 10/03/12 13:47, Garrett Cooper wrote:
> On Wed, Oct 3, 2012 at 1:03 PM, Adrian Chadd <adrian_at_freebsd.org>
> wrote:
>> Hi,
>> 
>> somaxconn is the connection queue depth. If it's sitting at a
>> couple hundred thousand then something else is going crazily
>> wrong.
>> 
>> I understand your frustration, but there's a lot of instances
>> where the application just isn't doing things "right" and the OS
>> tries to hide it as much as psosible. Blowing out somaxconn to
>> chew up a whole lot of resources seems a bit silly. I'd rather
>> investigate why the userland application is not servicing the
>> connect queue often enough.
>> 
>> I've written network services that supported tens of thousands of
>> new TCP connections a second on a LAN and I never once had to
>> bump somaxconn past 32767. I'm not saying that it won't apply to
>> your scenario, I'm just trying to explain that there's likely
>> more going on.
> 
> Or the TTL of TCP connections might be too high for the volume of 
> connections received. Someone else on net_at_ reported that changing
> this value to more aggressively reap sockets improved performance
> greatly (at the cost that more connections potentially needing to
> be reestablished and/or getting dropped on the floor if things go
> too high volume).

That's a different topic I think.  On busy web servers it's fairly
typical to have a lot of TCP sockets staying in TIME_WAIT state for
extended time and the usual tuning would be to set MSL to about 2
seconds at the expense of sacrificing slow clients who can't make
3-way handshake in time (*), etc.  The TTL of IP packet have nothing
to do with this though, and our default (64) is saner than many other
operating systems.

> But yeah... the listen(2) queue might be too high, or the 
> application might be accept(2)'ing too much and thus the queue is 
> backing up too much. I was merely providing the pointer to "why" 
> things are the way they are.

Well, not accept'ing fast enough is a big problem and has to be
solved.  Think about this example: at a shopping center there are a
lot of customers waiting for checkout.  The right solution is not to
draw zigzag lines or to remodel the shopping center's building and
create a large "waiting room" in order to increase the capacity of the
queue, but to increase the number of cashiers or prioritize simple
cases (like, if you have less than 10 items for checkout, go this queue).

(*) which is actually not a bad idea because the usual web visitors
would just walk away in that case and this can also be used as a
leverage for attacks.

Cheers,
- -- 
Xin LI <delphij_at_delphij.net>    https://www.delphij.net/
FreeBSD - The Power to Serve!           Live free or die
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.19 (FreeBSD)

iQEcBAEBCAAGBQJQbKhIAAoJEG80Jeu8UPuzcZMH/1yzMaKmgyJhfHL3P05SDUdZ
nKx4EEg/4KyA7jkodNzbQONr/icem3uUZ/TnwxTkZ7Aq9Ezg8nqF8RXFXPUqE7V2
H3aptIkRqVt/02SRb1Y3Cd7meqt6ikEQcfQZxT9cFDQWc8BXduyh6J0P6pvaiXSS
he8LVeg5SfT1o43lf8q4N6I/mlPmc2EKhzcrxeNwXOL3jqjHJ7NNPjIX8l4cu6a/
g6JvkDwSVyve6L91b7Jrp1y505aYRlAIioIH9CTcYJx/nQMjXFLYEsJA5dley/sw
1c3IilJ8zJFzLzNmjaUF0emY4QcMYX5eA/gododDEXWF+WjZs2Qv+/w1Fu9McKQ=
=dCYl
-----END PGP SIGNATURE-----