65k的TIME_WAIT连接出现networking错误

上周我们的一台映像服务器遇到了一些麻烦，需要一些帮助。查看我们的munin监测图：

在这里输入图像说明

我们正在运行debian squeeze，我们有很多的要求，因为这是我们的图像服务器之一。我们不使用保持活力（也许我们应该，但这是另一个话题）

这些数字是我们的日志文件每分钟的请求数量：

17:19：66516
17:20：64627
17:21：123365
17:22：111207
17:23：58257
17:24：17710
… 等等

所以你看，我们有很多请求每分钟，但由于大多数请求在0-1ms服务，一切运行良好。

现在，如你所看到的，在我们的图片中，munin没有设法连接到这个在munin端口上的服务器，并询问相关的数字。连接只是失败。由于服务器没有任何手段（CPU，内存，networking）过载。它必须与我们的防火墙/ tcp堆栈有关。当时这个munin插件没有连接，我们在100MBit的连接上只有17MB的input和输出stream量。

你经常在这里有65k的tcp连接的限制，但这通常是误导的，因为它指的是16位的tcp头，并且属于每个ip /端口组合的65k。

我们的time_wait超时设置为

net.ipv4.tcp_fin_timeout = 60

我们可以降低这个以降低更多的TIME_WAIT连接，但是首先我想知道什么限制了networking的可达性。

我们使用iptables和状态模块。但是我们已经提出了max_conntrack参数。

  net.ipv4.netfilter.ip_conntrack_max = 524288

有没有人知道下一周要看什么内核参数或如何诊断这个问题呢？

FIN_WAIT（FIN请求确认超时）与TIME_WAIT（确保套接字实际上不再使用的时间）不同。是的，在65万个端口处于TIME_WAIT状态的情况下，如果您使用单个请求者IP，则只会用尽TCP端口 – 如果您的所有客户端位于NAT设备后面，情况可能如此。由于传输控制块表过多，你也可能会运行资源 – 即使有些过时的文件可能会影响性能，也可以看到这一点。

如果你真的担心你的套接字处于TIME_WAIT状态，并且在你的客户端和你的服务器之间没有状态防火墙，你可以考虑设置/ proc / sys / net / ipv4 / tcp_tw_recycle，但是你会牺牲RFC合规性， – 由于这个问题将来的影响。

好吧，我已经find了我自己的答案。 munin插件运行速度非常慢，正在达到自己的超时值。如果conntrack表已满，则从/ proc / net / ip_conntrack读取得非常慢。服务器似乎是敏感的，而munin插件不是。