それほど多くのApache CLOSE_WAIT接続を取得しないようにするにはどうすればよいですか？

netstatは、153の接続がステータスCLOSE_WAITにあることを示しています。接続は決して閉じられません。そのため、時間の経過とともに、サーバーはこれらの接続でいっぱいになり、RAMがいっぱいになり、Webサイトが読み込まれなくなります。

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状態の接続数が増え続ける場合は、アプリケーションに問題がある可能性があります。これは、リソースリークバグの特別なケースです。アプリケーションは開いているソケットをタイムリーに閉じるのではなくリークします。これはカーネルメモリを消費し、オープンファイル記述子の最大数に達すると、最終的にアプリケーションを失敗させます。

ただし、漏れの速度が遅い場合があることに注意してください。このようなバグは、リクエストの途中で例外を処理できず、ワーカースレッドの実行フローが中断され、その後クリーンアップ（ソケットのクローズを含む）が妨げられることが原因であることがよくあります。問題の例外はまれに発生する可能性があります。

一時的な解決策

問題の一時的な解決策は、開いているファイル記述子の制限を増やし、問題がパフォーマンスに影響し始めたとき（できればその前に）定期的にアプリケーションを再起動することです。これは、現在開かれている接続に誤って影響を与える可能性があることに注意してください。冗長サーバーと負荷分散の存在は、ユーザーから問題を隠すのに役立ちます。

永続的なソリューション

問題の永続的な解決策は、バグのないバージョンのアプリケーションをデプロイすることです。一時的なソリューションがユーザーとビジネスに悪影響を与える度合い、パッチを適用したリリースの準備状況、および最新の作業リリースの状態は、アプリケーションの最新の作業バージョンにロールバックするか、修正を待つかを決定するのに役立ちます。