Haproxy中的TIME_WAIT数量很多

Question

我们在拥有2.13 GHz英特尔至强处理器的CentOS 5.9机器上安装了haproxy 1.3.26，该处理器充当http＆amp;用于众多服务的tcp负载均衡器，提供~2000个请求/秒的峰值吞吐量。它已经运行了2年，但逐渐增加了流量和服务数量。

我们观察到即使在重新加载旧的haproxy过程后仍然存在。在进一步调查中，我们发现旧进程在TIME_WAIT状态下有许多连接。我们还发现netstat和lsof花费了很长时间。在提到http://agiletesting.blogspot.in/2013/07/the-mystery-of-stale-haproxy-processes.html时，我们介绍了option forceclose，但它正在弄乱各种监控服务，因此将其还原。在进一步挖掘时，我们意识到在/proc/net/sockstat接近200K套接字处于tw（TIME_WAIT）状态，这是令人惊讶的，因为/etc/haproxy/haproxy.cfg maxconn被指定为31000和ulimit-n为64000.我们将timeout server和timeout client作为300s，我们将其更改为30s但使用不多。

现在怀疑是： -

• 是否可以接受如此多的TIME_WAIT。如果是，那么我们应该担心的是一个数字。看What is the cost of many TIME_WAIT on the server side?和Setting TIME_WAIT TCP似乎不应该有任何问题。
• 如何减少这些TIME_WAIT
• 除非有非常多的TIME_WAIT，否则netstat和lsof是否有其他替代品可以正常运行

Answer 1

注意：此答案中的引号全部来自a mail by Willy Tarreau（HAProxy的主要作者）到HAProxy邮件列表。

TIME_WAIT状态下的连接是无害的，并且不再消耗任何资源。它们由服务器上的内核保留一段时间，用于在连接关闭后它仍然收到包的罕见事件。在该状态下保持关闭连接的默认时间通常为120秒（或最大段寿命的2倍）

  

TIME_WAIT在服务器端是无害的。您可以轻松达到数百万   没有任何问题。

如果您仍希望减少该数字以便更早地释放连接，则可以指示内核执行此操作。例如，设置为30秒执行：

echo 30 > /proc/sys/net/ipv4/tcp_fin_timeout

如果您有许多连接（无论是否在TIME_WAIT中），netstat，lsof，ipcs执行效果非常差，实际上会降低整个系统的速度。再次引用威利：

  

在监控中绝对不能使用两个命令   系统：

     

  
• netstat -a
  
• ipcs -a
  

     

它们都会使系统饱和，并且会大大减慢它的速度   事情开始出错了。对于插座，你应该使用的是什么   /proc/net/sockstat。你有你想要的所有数字。如果你需要更多   详细信息，使用ss -a而不是netstat -a，它使用netlink接口   并且快几个数量级。

在Debian和Ubuntu系统上，ss或iproute包中提供了iproute2（具体取决于您的发布版本）。