为什么我不能超过32k或65k的时间等待连接？

Question

我一直试图调整我们的Ubuntu14.04LTS web服务器实例，托管web应用程序和反向代理nginx，以便使用给定的硬件处理尽可能多的req/s。它是一个带有8x EC2的c4.2xl vCPU实例。

我在我的办公室机器上运行以下两个基准测试工具(不是同时运行这两个工具)：

wrk -c1000 -d2m -t8 --timeout 90 --latency http://api.mysite.com/2/ping
# or
ab -k -n 100000 -c 1000 http://api.mysite.com/2/ping

我看到的是，通过运行ss -tan | wc -l，我总是在TIME-WAIT中最大限度地达到65.5k连接

我的操作系统设置是：

• net.ipv4.ip_local_port_range value="15000 65000"
• /etc/security/limits.conf中有‘`www data硬nofile 100000’
• 更新/etc/pam.d/common-session*以读取上述内容

nginx的设置是：

• worker_processes auto; # will result in 8 on this machine

events { worker_connections 8192; multi_accept on; use epoll; }

将api代理到nginx的上游如下所示，用于获得非常高的不同TCP四胞胎的最大值，这意味着我在nginx ->应用程序中几乎从未耗尽过短暂的端口：

upstream my_api { server 127.0.0.1:3004; server 127.0.0.2:3004; server 127.0.0.3:3004; [...] }

我遇到了类似的问题，我的m3大型实例，而不是65k，我的最大值在32k。两个实例的区别在于前者有2vCPU，后者有8个，前者有7.5GB内存，后者有15GB。

在这篇文章(超过65k打开的文件(TCP连接))中也描述过类似的问题，但它似乎不适用于我的情况，因为在我较小的例子中，vm.max_map_count是65530，但在TIME-WAIT中却从未超过32k连接。

我以为最初的限制只是# process *# workers，但在较小的情况下，即使我将每个进程的工人#提高到25k，我仍然被限制在32k，所以不是这样的。

我不知道在这一点上要调整什么旋钮，我不知道这些硬约束是从哪里来的。在这里可能需要帮助。

有趣的是，当等待时间达到这个“极限”时，我不认为连接最终会被这些机器中的任何一个拒绝。可能是套接字队列在幕后填满了，而客户机只是重新尝试稍后再建立一个连接，这就是为什么我没有看到任何永久性的失败。

更新：

在c4.8xlarge实例中，我可以及时获得262 k连接--等待具有相同的精确部署配置。即使限制nginx工作人员的#仅为1，也不会改变它。仍然不确定这里会有什么区别。

更新2:

我强烈怀疑这与不同的实例有关，所有这些实例都有不同的net.ipv4.tcp_max_tw_buckets值，从我所能看出的情况来看，这些值与我所看到的模式完全匹配。

Answer 1

看看net.ipv4.netfilter.ip_conntrack_max可调性。有关更多信息，您可以阅读这个服务器故障帖子

Answer 2

源计算机上的源端口正在耗尽。

为了标识您需要的连接:源IP、源端口、目标IP和目标端口。由于源IP、目标IP和目标端口在测试中总是相同的，所以只有一个变量:源端口。您的TCP/IP堆栈不能处理超过64k的不同源端口(实际上要少一点)。

从单点进行压力测试从来不是一个好主意，但是您可以通过启用net.ipv4.tcp_tw_recycle在TIME_WAIT状态下重用端口来将其压缩得更多，但它可能会因为端口重用而给您带来麻烦。