☰

FreeBSD 已建立连接数上限为 300

tag-icon • tag-icon freebsd tcp kernel connections
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 个连接。这意味着它不会在该特定端口上接受更多连接。

答案1

看起来这实际上是一个应用程序限制。监听 2069 套接字的进程的最大监听连接数为 192。

我假设许多应用程序都是在这些限制的情况下构建的，并且 somaxconn 很可能只会增加允许的总监听套接字数量，而不是应用程序实际构建的数量。

答案2

我想到的是文件句柄。首先使用ulimit -n(或，取决于 shell，limit -n) 检查它是否返回。如果返回，则使用或1024增加文件句柄限制。看看这是否有帮助。ulimit -n 16384limit -n 16384

相关内容