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

Question

netstat 显示有 153 个连接处于 CLOSE_WAIT 状态。连接永远不会关闭。因此，超时服务器充满了这些连接，这些连接填满了 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）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 状态的连接数不断增加，则很可能表明应用程序存在问题。这是资源泄漏错误的一个特例：应用程序泄漏打开的套接字而不是及时关闭它们。这会消耗内核内存，一旦达到打开文件描述符的最大数量，最终将使应用程序失败。

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

临时解决方案

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

永久解决方案

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