Haproxy中的高TIME_WAITs数

Question

我们有一个代理1.3.26托管在CentOS 5.9机器上，它有2.13 GHz Intel Xeon处理器，它充当许多服务的http & tcp负载均衡器，最高吞吐量为2000请求/秒。两年来一直运行良好，但交通和服务的数量都在逐渐增加。

我们观察到，即使在重新加载旧的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_WAITs是否是可以接受的。如果是的话，我们应该担心的数字是什么。看看WAIT on the server side?和WAIT TCP，似乎不应该有任何问题。
• 如何降低这些TIME_WAITs
• 有什么替代netstat和lsof的方法，即使有很高数量的TIME_WAITs，它们的性能也会很好。

Answer 1

注意:这个答案中的引号都是从http://marc.info/?l=haproxy&m=135659125315859 ( 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包中使用(取决于发行版的版本)。