如何不获得如此多的apache CLOSE_WAIT连接？

Question

netstat显示，在状态CLOSE_WAIT上有153个连接。连接永远不会关闭。因此，超时，服务器充满了这些连接，这填补了RAM，现在网站没有加载。

netstat显示了许多类似的内容：

tcp      160      0 my_server_name:http         my_server_name:51584        CLOSE_WAIT
tcp      160      0 my_server_name:http         my_server_name:51586        CLOSE_WAIT
tcp        0      0 my_server_name:http         my_server_name:50827        CLOSE_WAIT
tcp        0      0 my_server_name:http         my_server_name:50830        CLOSE_WAIT
tcp      312      0 my_server_ip.static.:http rate-limited-proxy-72:61249 CLOSE_WAIT
tcp      382      0 my_server_ip.static.:http b3090792.crawl.yahoo.:58663 CLOSE_WAIT
tcp      382      0 my_server_ip.static.:http b3090792.crawl.yahoo.:34655 CLOSE_WAIT
tcp      382      0 my_server_ip.static.:http b3090792.crawl.yahoo.:56681 CLOSE_WAIT
tcp      382      0 my_server_ip.static.:http b3090792.crawl.yahoo.:40829 CLOSE_WAIT
tcp      576      0 my_server_ip.static.:http b3090792.crawl.yahoo.:38278 CLOSE_WAIT
tcp       47      0 my_server_ip.static.:http 203.200.5.143.ill-bgl:49379 CLOSE_WAIT

如果我查看appache error_log，在CLOSE_WAIT情况出现之前，有如下所示的行

[warn] child process 15670 still did not exit, sending a SIGTERM
[error] child process 15670 still did not exit, sending a SIGKILL
[notice] child pid 3511 exit signal Segmentation fault (11)

我的安装程序Apache2.2.3RAM 1024 MB (突发2048 MB) CentOS版本5.3 (最终)，运行2个WPMU 2.9.2安装

Answer 1

背景

当远程终端终止发送带有FIN标志的数据包的连接时，套接字进入CLOSE_WAIT状态。然后在此状态下等待本地应用程序到close()套接字，然后向客户端发送自己的FIN，并将套接字转换为LAST_ACK状态。另见TCP状态转换图和RFC 793。

还请注意，CLOSE_WAIT与臭名昭著的TIME_WAIT无关，因为前者发生在被动关闭分支(远程结束首先关闭)，而后者发生在主动关闭分支上(本地结束先关闭)。

问题描述

正常情况下，连接从CLOSE_WAIT过渡到LAST_ASK相当快。如果远程地址和端口不断快速变化，那么处于CLOSE_WAIT状态的相当数量的连接可能仅仅是大量连接打开、使用和关闭的结果。应该检查系统性能，但这本身并不构成问题。

如果远程地址和端口变化缓慢，则表示应用程序进程需要等待CPU，在这种情况下，高负载平均值将证实这一点。

另一方面，如果远程地址和端口保持不变，并且CLOSE_WAIT状态中的连接数量不断增加，则很可能表明应用程序存在问题。这是资源泄漏错误的特例:应用程序泄漏的是打开的套接字，而不是及时关闭它们。这将消耗内核内存，并最终使应用程序在达到打开的文件描述符的最大数量时失败。

但是请注意，泄漏的速度可能是缓慢的。通常情况下，这样的错误是由于在请求中处理异常失败而导致的，中断了工作线程中的执行流，这可能随后会阻止清理(包括套接字关闭)。冒犯的例外情况可能很少发生。

临时解决方案

该问题的临时解决方案是增加对打开的文件描述符的限制，并在问题开始影响性能时(最好在此之前)定期重新启动应用程序。请注意，这可能会无意中影响当前打开的连接。冗余服务器和负载平衡的存在可以帮助用户隐藏问题。

永久溶液

这个问题的永久解决方案是在没有错误的情况下部署应用程序的版本。临时解决方案对用户和业务的损害程度、修补版本的准备程度以及上一个工作版本的状态有助于决定是回滚到应用程序的最后一个工作版本还是等待修复。