netstat显示在状态CLOSE_WAIT上有153个连接。 连接永远不会closures。 所以超时服务器充满了这些连接，填充内存，现在网站没有加载。
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内存1024 MB（突发2048 MB）CentOS发行5.3（最终）运行2 WPMU 2.9.2安装
当远端终止发送带有FIN标志的数据包的连接时，套接字进入CLOSE_WAIT状态。 然后在这个状态下等待本地应用程序close()套接字，然后将自己的FIN发送给客户端，并将套接字转换为LAST_ACK状态。 另请参阅TCP状态转换图和RFC 793 。
还要注意的是CLOSE_WAIT与臭名昭着的TIME_WAIT无关，因为前者发生在被动closures分支上（远程端先closures），而后者在活动closures分支上（本地端先closures）。
通常连接很快从CLOSE_WAIT过渡到LAST_ASK。 如果远程地址和端口保持快速变化，那么在CLOSE_WAIT状态下的相当数量的连接可能仅仅是大量连接打开，使用和closures的结果。 应该检查系统性能，但是本身并不构成问题。
如果远程地址和端口变化缓慢，则说明应用程序进程需要等待CPU，在这种情况下，高负载平均值将确认这一点。
另一方面，如果远程地址和端口保持不变，并且处于CLOSE_WAIT状态的连接数量不断增加，则很可能表示应用程序出现问题。 这是资源泄漏漏洞的一个特殊情况：应用程序泄露打开的套接字而不是及时closures它们。 这会消耗内核内存，一旦达到打开文件描述符的最大数量，最终会导致应用程序失败。
但请注意，泄漏的速度可能会很慢。 通常情况下，像这样的错误是由于在请求中不处理exception而导致的，中断了工作线程中的执行stream程，这可能随后阻止清除（包括套接字closures）。 违规的例外可能很less发生。
解决此问题的临时解决scheme是增加对打开的文件描述符的限制，并在问题开始影响性能时（最好在此之前）定期重新启动应用程序。 请注意，这可能会无意中影响当前打开的连接。 冗余服务器的存在和负载平衡可以帮助用户隐藏问题。
永久解决问题的方法是部署没有错误的应用程序版本。 临时解决scheme危害用户和业务的程度，修补版本的准备情况以及最后一个工作版本的状态有助于决定是回滚到应用程序的最后一个工作版本还是等待修复。