From: Hagen Paul Pfeifer <hagen@jauu.net>
To: David Miller <davem@davemloft.net>
Cc: netdev@vger.kernel.org, eric.dumazet@gmail.com
Subject: Re: [PATCH 1/2] socket: increase default maximum listen queue length
Date: Mon, 21 Mar 2011 00:52:53 +0100 [thread overview]
Message-ID: <20110320235253.GD3038@nuttenaction> (raw)
In-Reply-To: <20110320.160906.112595807.davem@davemloft.net>
* David Miller | 2011-03-20 16:09:06 [-0700]:
>Absolutely no context is provided for this number.
>
>What's the RTT? How fast are the cpus? etc.
>
>You must tell the whole story in order to justify these changes
>properly.
(you can skip the first paragraphs and read the last one ;)
The number is somewhat magically - like many other values. I greped
tglx/history.git but the comment (at that time tcp_ipv4.c) seems pre 2002 era.
Providing context is a little bit artificial: I can construct an scenario with
a RTT of 200ms and 1000 connection request per second and the table will
overflow. This can happen, sure. On the other hand there are scenarios with a
RTT of 20ms and 10 connection requests per second - no problem there.
Increasing the number _has_ one essential advantage: it is aligned on
sysctl_max_syn_backlog which in turn is determined by memory characteristics.
Without patch (sysctl not modified, BUT sysctl_max_syn_backlog depending on memory characteristic):
listen-queue-length = max(8, min(userspace_backlog, min(128, sysctl_max_syn_backlog))
Wit patch (sysctl not modified, BUT sysctl_max_syn_backlog depending on memory characteristic):
listen-queue-length = max(8, min(userspace_backlog, min(256, sysctl_max_syn_backlog))
The point is now: sysctl_max_syn_backlog is per default 256, 128 for small
systems and up to 1024 for larger systems. But sysctl_somaxconn (128) will
_always_ restrict the queue length to 128 and make therefore
sysctl_max_syn_backlog defacto unfeasible - it will always restrict the value
to 128. IMHO sysctl_somaxconn should be removed, the overhead of the
listen-queue size per listening socket is insignificant. Especially because
sysctl_max_syn_backlog already consider the memory characteristic. There are a
bunch more connected sockets as these <10 listening sockets, but performance
lack because of will always be noticeable:
netstat -s | grep overflowed
2621 times the listen queue of a socket overflowed
Hagen
next prev parent reply other threads:[~2011-03-20 23:52 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-03-20 1:50 [PATCH] socket: increase default maximum listen queue length Hagen Paul Pfeifer
2011-03-20 4:41 ` David Miller
2011-03-20 11:59 ` Hagen Paul Pfeifer
2011-03-20 8:30 ` Eric Dumazet
2011-03-20 9:04 ` Rémi Denis-Courmont
2011-03-20 9:36 ` Eric Dumazet
2011-03-20 11:39 ` Hagen Paul Pfeifer
2011-03-20 11:55 ` Eric Dumazet
2011-03-20 12:14 ` Hagen Paul Pfeifer
2011-03-20 23:04 ` [PATCH 1/2] " Hagen Paul Pfeifer
2011-03-20 23:04 ` [PATCH 2/2] socket: add minimum listen queue length sysctl Hagen Paul Pfeifer
2011-03-21 7:36 ` Eric Dumazet
2011-03-20 23:09 ` [PATCH 1/2] socket: increase default maximum listen queue length David Miller
2011-03-20 23:52 ` Hagen Paul Pfeifer [this message]
2011-03-21 0:18 ` David Miller
2011-03-20 23:57 ` Hagen Paul Pfeifer
-- strict thread matches above, loose matches on Subject: below --
2011-03-25 18:31 Hagen Paul Pfeifer
2011-03-31 5:52 ` David Miller
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20110320235253.GD3038@nuttenaction \
--to=hagen@jauu.net \
--cc=davem@davemloft.net \
--cc=eric.dumazet@gmail.com \
--cc=netdev@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.