如何不获得这么多的Apache CLOSE_WAIT连接？

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)

我的设置Apache 2.2.3 RAM 1024 MB（突发2048 MB）运行2个WPMU 2.9.2安装的CentOS版本5.3（最终版）

背景

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

还要注意，CLOSE_WAIT与臭名昭著的TIME_WAIT无关，因为前者发生在被动关闭分支上（远端先关闭），而后者发生在主动关闭分支上（本地端先关闭）。

问题描述

通常，连接会很快从CLOSE_WAIT转换为LAST_ASK。如果远程地址和端口保持快速变化，则处于CLOSE_WAIT状态的大量连接可能仅仅是由于大量打开，使用和关闭连接的结果。应该检查系统性能，但这本身并不构成问题。

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

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

但是请注意，泄漏的速度可能很慢。通常这样的错误是由于未能在请求中间处理异常而导致的，从而中断了工作线程中的执行流，这可能随后阻止清除（包括套接字关闭）。令人反感的异常可能很少发生。

临时解决方案

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

永久解决方案

永久解决此问题的方法是部署没有错误的应用程序版本。临时解决方案对用户和业务的损害程度，已修补发行版的就绪状态以及最新工作发行版的状态有助于决定是回滚到应用程序的最新工作版本还是等待修复。