65k TIME_WAIT 连接的网络错误

Question

上周我们的一台图像服务器出现了一些问题，需要一些帮助。查看我们的 munin 监控图：

我们正在运行 debian 挤压，我们有很多请求，因为这是我们的图像服务器之一。我们不使用 keep-alive（也许我们应该，但那是另一个话题）

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

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

所以你看，我们每分钟有很多请求，但由于大多数请求在 0-1 毫秒内提供服务，所以通常一切正常。

现在，正如您在我们的 munin 图形中看到的，munin 无法通过 munin 端口连接到此服务器并询问相关号码。连接失败了。由于服务器不会以任何方式（CPU、内存、网络）过载。它一定与我们的防火墙/tcp 堆栈有关。在 munin 插件连接失败时，我们在 100MBit 连接上只有 17MBit 的传入和传出流量。

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

我们的 time_wait 超时设置为

 net.ipv4.tcp_fin_timeout = 60

我们可以降低它以更早地删除更多 TIME_WAIT 连接，但首先我想知道是什么限制了网络的可达性。

我们正在使用带有状态模块的 iptables。但是我们已经提高了 max_conntrack 参数。

 net.ipv4.netfilter.ip_conntrack_max = 524288

有没有人知道下周要查看哪些内核参数或如何诊断这个问题？

Answer 1

好吧，我自己找到了答案。munin 插件运行速度非常慢并且达到了自己的超时值。如果 conntrack 表已满，从 /proc/net/ip_conntrack 读取会变得非常非常慢。服务器似乎有响应，而 munin 插件则没有。