FreeBSD 建立的連接最大為 300

我們以前在我們的環境中遇到過問題，似乎我們達到了 FreeBSD 的最大連接限制。我們採取了http://nginx.org/en/docs/freebsd_tuning.html所展示的行動，並將我們的連接限制提高到 500：kern.ipc.somaxconn: 500

我們仍然遇到問題，我們希望看到從客戶端到此特定伺服器的其他連接，但我們沒有，它們失去了。

我們不知道這是應用程序問題還是網路問題。但我想知道我們現在是否還有其他限制，也許是建立連接的最大數量？

下面是一些圖表，顯示了我們的連接行為，奇怪的是它被限制在 300 個連接：

我們伺服器上失去的命令的大約數量^

編輯：

有關應用程序的其他詳細資訊：該應用程序是一個 tclsh（tcl shell），它使用套接字應用程序在特定的 tcp 埠上偵聽以接收連接。也許這是一些基於 tcl 的限製或套接字應用程序限制？

故障排除詳細資訊：當我執行 nmap 基本上一遍又一遍地“ping”所需的埠時

for i in {1..600}; do nmap -p 2069 serverIP; done

我似乎通過 netstat 得到以下資訊：

netstat -Lan | grep 2069
tcp4  193/0/128      *.2069
tcp4  193/0/128      *.2069
tcp4  193/0/128      *.2069
tcp4  193/0/128      *.2069

這似乎意味著我實際上正在最大化 kern.ipc.somaxconn 預設值。但是我們已經將該值設置為遠高於預設值。

即使我使用以下方法監視已建立的連接：

netstat -an | grep 2069 | wc -l

我在 2069 年總共只獲得了 192 個連接。這意味著它在該特定埠上不接受更多連接。

似乎這實際上是一個應用程序限制。在 2069 套接字上偵聽的程序是使用最大數量的 192 個偵聽連接建構的。

我假設很多應用程序都是在這些限制的情況下建構的，somaxconn 很可能只是增加了總允許的偵聽套接字，而不是應用程序實際建構的用途。

我想到了文件句柄。首先檢查ulimit -n（或，取決於外殼，limit -n）如果它返回1024。ulimit -n 16384如果是這樣，請使用limit -n 16384或 左右來提高文件句柄限制。看看是否有幫助。

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