增加 net.core.somaxconn 会有所不同吗？

Question

我对 net.core.somaxconn 参数产生了争论：有人告诉我，如果我们更改默认值 128，它不会有任何区别。

我相信这可能足以证明：

“如果积压参数大于 /proc/sys/net/core/somaxconn 中的值，则它会被静默截断为该值” http://linux.die.net/man/2/listen

但事实并非如此。

有谁知道一种方法可以用两台机器来证明这一点，坐在 Gbit 网络上？最好的方法是针对 MySQL、LVS、apache2 (2.2)、memcached。

Answer 1

net.core.somaxconn只有在新连接速率如此之高/突发的高负载服务器上才需要设置更高的值，以至于有 128 个（在 BSD 中多 50%： 128 backlog+ 64 half-open）个尚未接受的连接被认为是正常的。或者当您需要将“正常”的定义委托给应用程序本身时。

一些管理员使用 highnet.core.somaxconn来隐藏他们服务的问题，所以从用户的角度来看，它看起来像是一个延迟峰值，而不是连接中断/超时（由net.ipv4.tcp_abort_on_overflowLinux控制）。

listen(2)手册说 -net.core.somaxconn仅作为应用程序的上限，可以自由选择较小的内容（通常在应用程序的配置中设置）。虽然有些应用程序只是使用listen(fd, -1)这意味着将积压设置为系统允许的最大值。

真正的原因是处理率低（例如单线程阻塞服务器）或工作线程/进程数量不足（例如多进程/线程阻塞软件，如apache/ tomcat）

附注。有时最好快速失败并让负载平衡器完成它的工作（重试）而不是让用户等待 - 为此我们设置net.core.somaxconn任何值，并将应用程序积压限制为 eg10并设置net.ipv4.tcp_abort_on_overflow为 1。

聚苯乙烯。旧版本的 Linux 内核具有将somaxcon值截断为低 16 位（uint16_t即将值转换为）的令人讨厌的错误，因此将该值提高到超过65535甚至可能是危险的。有关更多信息，请参阅：http : //patchwork.ozlabs.org/patch/255460/

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