我陷入了有关 net.core.somaxconn 参数的争论：有人告诉我，如果我们更改默认值 128，不会有任何区别。
我相信这可能足以证明：
“如果 backlog 参数大于 /proc/sys/net/core/somaxconn 中的值，则会被默默截断为该值”http://linux.die.net/man/2/listen
但事实并非如此。
有谁知道用两台机器在 Gbit 网络上验证这一点的方法吗？最好的方法是针对 MySQL、LVS、apache2 ( 2.2 )、memcached。
答案1
仅在高负载服务器上才需要设置net.core.somaxconn更高的值，此时新连接速率非常高/突发，以至于有 128 个（在 BSD 中多 50%：128 backlog+ 64 half-open）尚未接受的连接被视为正常。或者当您需要将“正常”的定义委托给应用程序本身时。
一些管理员使用高net.core.somaxconn来隐藏其服务的问题，因此从用户的角度来看，它看起来像是延迟峰值，而不是连接中断/超时（由net.ipv4.tcp_abort_on_overflowLinux 控制）。
listen(2)手册上说 -net.core.somaxconn仅充当应用程序的上限，应用程序可以自由选择较小的值（通常在应用程序的配置中设置）。虽然有些应用程序只是使用，listen(fd, -1)这意味着将积压设置为系统允许的最大值。
真正的原因是处理速度低（例如单线程阻塞服务器）或工作线程/进程数量不足（例如多进程/线程阻塞软件，如apache/ tomcat）
PS. 有时，快速失败并让负载均衡器完成其工作（重试）比让用户等待更好 - 为此，我们设置net.core.somaxconn任意值，并将应用程序积压限制为例如10并设置net.ipv4.tcp_abort_on_overflow为 1。
附言：旧版本的 Linux 内核存在将somaxcon值截断为其 16 个低位（即将值转换为uint16_t）的严重错误，因此将该值提高到甚至超过65535可能会很危险。有关更多信息，请参阅：http://patchwork.ozlabs.org/patch/255460/
如果您想了解有关 Linux 中所有 backlog 内部机制的更多详细信息，请随意阅读： TCP 积压在 Linux 中的工作原理。