我在net.core.somaxconn参数中引入了一个参数：我被告知，如果我们改变默认值128，它不会有什么区别。
我相信这可能是足够的证据：
“如果backlog参数大于/ proc / sys / net / core / somaxconn中的值，则会自动将其截断为该值” http://linux.die.net/man/2/listen
但事实并非如此。
有没有人知道一个方法来certificate这两台机器，坐在一个Gbitnetworking？ 最好的办法是反对MySQL，LVS，apache2（2.2），memcached。
将net.core.somaxconn设置为更高的值仅在高负载的服务器上需要，在该服务器中，新的连接速率如此高/突发，以至于具有128个（在BSD中：多于50个的backlog + 64个half-open ）未被接受的连接正常。 或者当您需要将“正常”的定义委派给应用程序本身时。
有些pipe理员使用高net.core.somaxconn来隐藏他们的服务的问题，所以从用户的angular度来看，它看起来像一个延迟尖峰，而不是连接中断/超时（由Linux中的net.ipv4.tcp_abort_on_overflow控制）。
listen(2)手册说 – net.core.somaxconn行为只能自由select较小的应用程序（通常设置在应用程序的configuration）的应用程序的上限。 虽然有些应用程序只是使用listen(fd, -1) ，这意味着将backlog设置为系统允许的最大值。
真正的原因是处理速度慢（例如单线程阻塞服务器）或工作线程/进程数量不足（例如多进程/线程阻塞软件，如apache / tomcat ）
PS。 有时候最好是快速失败，让负载平衡器做它的工作（重试），而不是让用户等待 – 为此目的，我们设置net.core.somaxconn任何值，并限制应用程序backlog例如10并设置net.ipv4.tcp_abort_on_overflow为1。
PPS。 老版本的Linux内核有一个令人讨厌的错误， somaxcon值截断为16位（ somaxcon值转换为uint16_t ），因此将该值提高到65535甚至可能是危险的。 欲了解更多信息，请参阅： http : //patchwork.ozlabs.org/patch/255460/
如果您想了解Linux中所有积压内部的更多细节，请随时阅读： Linux中的TCP积压工作原理 。