增加net.core.somaxconn会有所作为吗？

我在net.core.somaxconn参数上遇到了一个参数：有人告诉我，如果更改默认值128，它不会有任何区别。

我相信这可能足以证明：

“如果backlog参数大于/ proc / sys / net / core / somaxconn中的值，那么它将被默默地截断为该值” http://linux.die.net/man/2/listen

但事实并非如此。

有谁知道一种方法来通过两台位于Gbit网络上的机器进行验证？最好是针对MySQL，LVS，apache2（2.2），memcached。

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任何值，并将应用程序积压限制为eg 10并设置net.ipv4.tcp_abort_on_overflow为1。

PPS。旧版本的Linux内核有一个讨厌的错误，somaxcon即会将值截断为它的低16位（即，将值强制转换为uint16_t），因此将该值提高到65535甚至超过危险。有关更多信息，请参见：http : //patchwork.ozlabs.org/patch/255460/

如果您想了解有关Linux中所有积压内部细节的更多信息，请随时阅读： TCP积压如何在Linux中工作。