上周，我们的一个图像服务器出现了一些问题，需要一些帮助。请查看我们的 munin 监控图：
我们正在运行 Debian Squeeze，我们收到很多请求，因为这是我们的一个图像服务器。我们不使用 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
有人知道下周我们下次检查时要查看哪些内核参数或如何诊断这个问题吗？
答案1
FIN_WAIT（FIN 请求确认超时）与 TIME_WAIT（确保套接字不再使用的时间）不同。是的，在 65k 个端口处于 TIME_WAIT 状态的情况下，只有在使用单个请求者 IP 时才会耗尽 TCP 端口 - 如果所有客户端都位于 NAT 设备后面，情况可能就是如此。由于传输控制块表填充过多，您还可能会耗尽资源 - 请参阅这篇论文虽然有些过时，但仍然很优秀以免对性能产生影响。
如果您真的担心您的套接字处于 TIME_WAIT 状态并且您的客户端和服务器之间没有状态防火墙，您可以考虑设置 /proc/sys/net/ipv4/tcp_tw_recycle，但您会牺牲 RFC 合规性并且可能会因此在将来产生有趣的副作用。
答案2
好的，我自己找到了答案。munin 插件运行得相当慢，并且达到了自己的超时值。如果 conntrack 表已满，则从 /proc/net/ip_conntrack 读取会变得非常非常慢。服务器似乎响应迅速，而 munin 插件却没有。