Haproxy中的TIME_WAIT数量很多

pse*_*nym 4 linux tcp http haproxy

我们在CentOS 5.9机器上托管了haproxy 1.3.26,它具有2.13 GHz Intel Xeon处理器,作为许多服务的http和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 servertimeout client300s我们改变30s,但没有太大用处.

现在的疑虑是: -

Hol*_*ust 8

注意:本答复中的引用全部来自Willy Tarreau(HAProxy的主要作者)发送给HAProxy邮件列表的邮件.

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

TIME_WAIT在服务器端是无害的.您可以毫无问题地轻松达到数百万.

如果您仍希望减少该数字以便更早地释放连接,则可以指示内核执行此操作.要将其设置为30秒,请执行以下操作:

echo 30 > /proc/sys/net/ipv4/tcp_fin_timeout
Run Code Online (Sandbox Code Playgroud)

如果你有很多连接(无论是否在TIME_WAIT中)netstat,那么lsof,ipcs执行效果非常差,实际上会降低整个系统的速度.再次引用威利:

在监视系统中绝对不能使用两个命令:

  • netstat -a
  • ipcs -a

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

在Debian和Ubuntu系统,ss是在现有的iprouteiproute2包(取决于你的发行版的版本).