增加 net.core.somaxconn 會有所不同嗎？

我在 net.core.somaxconn 參數上遇到了一個爭論：有人告訴我，如果我們更改預設值 128，它不會有任何區別。

我相信這可能足以證明：

“如果積壓參數大於 /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）尚未接受的連接被認為是正常的。或者當您需要將“正常”的定義委託給應用程序本身時。

一些管理員使用 highnet.core.somaxconn來隱藏他們的服務問題，所以從使用者的角度來看，它看起來像一個延遲峰值，而不是連接中斷/超時（net.ipv4.tcp_abort_on_overflow在 Linux 中由控制）。

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 backlog 如何在 Linux中工作。

引用自：https://serverfault.com/questions/518862