Haproxy中出现大量的TIME_WAIT状态

Question

Haproxy中出现大量的TIME_WAIT状态

5

我们有一个 haproxy 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_WAIT是否可接受？如果是，那么我们应该在哪个数字之后开始担心呢？从服务器端许多TIME_WAIT的代价和设置TIME_WAIT TCP来看，似乎不应该有任何问题。
如何减少这些TIME_WAITs
是否有任何替代netstat和lsof的方法，即使有很多的TIME_WAITs也能够正常运行？

- pseudonym

如果你在 netstat 和 lsof 中提供了 -n，它们会立即响应吗？ - David Schwartz

没有netstat -n的帮助，事实上我一直使用带有-n选项。 - pseudonym

1个回答

网页内容由stack overflow 提供, 点击上面的

可以查看英文原文，
原文链接

- Holger Just · Accepted Answer

注意：本答案中引用的所有内容都来自HAProxy的主要作者Willy Tarreau发送的一封邮件，发给了HAProxy邮件列表。

TIME_WAIT状态下的连接是无害的，不会再消耗任何资源。它们被内核在服务器上保留一段时间，以防止在连接关闭后仍然接收到数据包的情况。默认情况下，一个关闭的连接在该状态下保持的时间通常为120秒（或2倍的最大段寿命）。

服务器端的TIME_WAIT状态是无害的。您可以轻松地达到数百万个连接而没有任何问题。

如果您仍然想减少这个数字以更早地释放连接，您可以指示内核这样做。例如，将其设置为30秒，请执行以下操作：

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

如果您有许多连接（无论是在TIME_WAIT状态还是不是），netstat、lsof和ipcs的表现非常糟糕，实际上会减缓整个系统的速度。引用Willy的话：

有两个命令在监控系统中绝对不能使用： - netstat -a - ipcs -a

当出现问题时，它们都会使系统饱和并显著减慢系统速度。对于套接字，您应该使用/proc/net/sockstat中的内容。您拥有所有所需的数字。如果需要更多详细信息，请使用ss -a而不是netstat -a，它使用netlink接口，速度快了几个数量级。

在Debian和Ubuntu系统中，ss可在iproute或iproute2软件包中获得（取决于您的发行版版本）。