上周我们的一台图像服务器遇到了一些问题,需要一些帮助.请参阅我们的munin监控图：
我们正在进行debian挤压,我们有很多请求,因为这是我们的图像服务器之一.我们不使用keep-alive(也许我们应该,但这是另一个话题)
这些数字是我们日志文件中每分钟的请求数：
> 17：19：66516
> 17：20：64627
> 17：21：123365
> 17：22：111207
> 17：23：58257
> 17：24：17710
> ……等等
所以你看,我们每分钟有很多请求但是由于大多数请求都是在0-1ms内提供的,所以一切都运行正常.
现在你在我们的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
当我们下一次偷看时,有谁知道下周要查看的内核参数或如何诊断这个问题？
解决方法
FIN_WAIT(FIN请求确认的超时)与TIME_WAIT(确保不再使用套接字的时间)不同.是的,对于处于TIME_WAIT状态的65k端口,如果您使用单个请求者IP,则只会耗尽TCP端口 – 如果所有客户端都在NAT设备后面,则可能就是这种情况.由于过度填充的传输控制块表,您也可能正在运行资源 – 请参阅
this excellent even if somewhat dated paper以了解可能的性能影响.
如果你真的担心你的套接字处于TIME_WAIT状态并且你的客户端和你的服务器之间没有状态防火墙,你可以考虑设置/ proc / sys / net / ipv4 / tcp_tw_recycle,但你会牺牲RFC合规性并且可能有一些有趣的方面 – 由此引起的未来影响.
