Windows 2008のTIME_WAIT状態の大量のTCP接続-Amazon AWSで実行

OS：Windows Server 2008、SP2（EC2 Amazonで実行）。

Apache httpdおよびtomcatサーバー6.02とWebサーバーを使用してWebアプリを実行すると、キープアライブ設定があります。

TIME_WAIT状態（netstatとtcpviewを使用）で約69,250（httpポート80）+ 15000（ポート80以外）TCP接続があります。これらの接続は、Webサーバーを停止した後でも閉じられないようです（24時間待機）

パフォーマンスモニターカウンター：

• TCPv4アクティブ接続：145K
• TCPv4パッシブ接続：475K
• TCPv4エラー接続：16K
• TCPv4接続のリセット：23K

HKEY_LOCAL_MACHINE\System \CurrentControlSet\Services\Tcpip\Parameters TcpTimedWaitDelayキーがないため、値はデフォルト（2 * MSL、4分）でなければなりません

数千の接続要求が同時に来ている場合でも、Windows OSが最終的にそれらを削除できないのはなぜですか？
この状況の背後にある理由は何でしょうか？
Windows OSを再起動せずにこれらすべてのTIME_WAIT接続を強制的に閉じる方法はありますか？

数日後、アプリは新しい接続の取得を停止します。

私たちもこの問題に取り組んできました。Amazonが根本原因を見つけて修正したようです。ここに彼らがくれた情報があります。

こんにちは、この問題の原因についての説明を以下に貼り付けています。幸いなことに、これはエンジニアリングチームによって最近修正されました。修正するには、この問題が発生しているWindows Server 2008インスタンスを停止/開始するだけです。繰り返しますが、私は異なるREBOOTについて話していません。STOP / STARTにより、インスタンスは別の（正常な）ホストに移動します。これらのインスタンスが再び起動すると、修正が適用されているホストで実行されるため、再びこの問題が発生することはありません。以下は、この問題の技術的な説明です。詳細な調査の結果、ほとんどの利用可能なインスタンスタイプでWindows 2008 x64を実行すると、veは、TCP接続が非常に長い時間TIME_WAIT / CLOSE_WAITのままになる可能性がある問題を特定しました（場合によっては、この状態が無期限に残る）。これらの状態では、特定のソケットペアは使用できず、十分に蓄積すると、問題のポートのポートが枯渇します。この特定の状況が発生した場合、問題のソケットペアをクリアする唯一の解決策は、問題のインスタンスを再起動することです。原因は、Windows 2008カーネルAPIのタイマー関数によって生成された値であると判断しました。これは、64ビットプラットフォームの多くで、非常に将来の値を取得する場合があります。これは、TCPソケットペアのタイムスタンプが将来的に大幅にスタンプされることにより、TCPスタックに影響します。Microsoftによると、このAPI呼び出しによって生成された値が累積値よりも大きい場合を除き、更新されない累積カウンターが保存されています。最終的な結果は、この時点以降に作成されたソケットは、その将来の時刻に到達するまで、すべて非常に遠くにスタンプされます。場合によっては、この値が数百日先の未来を見たことがあるため、ソケットペアは永久にスタックしているように見えます。

Ryanの答えは、RaviがEC2で経験している条件には適用されないことを除いて、良い一般的なアドバイスです。私たちもこの問題を見てきましたが、何らかの理由でWindowsがTcpTimedWaitDelayを完全に無視し、TIMED_WAIT状態からソケットを解放することはありません。

待機しても解決しない...アプリを再起動しても解決しない...見つかった唯一の解決策は、OSを再起動することです。本当にい。

別の問題をデバッグしようとしているときに、このスレッドを完全にランダムに見つけましたが、これは少し改良されたものですが、EC2上のWindowsでよく知られている問題です。我々は、プレミアムサポートを持っていた、そのチャネルを介した非公共の場でそれらでこれを議論したが、これは我々がいることに関連する問題であるなかった公開フォーラムで議論します。

他の人が述べたように、すぐにWindows Serverを調整する必要があります。ただし、上記のスレッドでStopWatchが機能しないのと同じように、TCP / IPスタックはQueryPerformanceCounter呼び出しを使用して、TCP_TIME_WAIT期間がいつ続くかを正確に判断します。問題は、EC2で、彼らが問題に遭遇し、それについて知っていることでありQueryPerformanceCounter、遠い将来、遠い未来に時間を返す可能性があるということです。TIME_WAIT状態が無視されているわけではなく、TIME_WAITの有効期限が潜在的に何年も先であるということです。httpd設定で実行している場合、状態が発生すると、これらのゾンビソケットをすばやく蓄積する方法を確認できます（一般的に、ゾンビをゆっくりと蓄積するのではなく、個別のイベントであることがわかります）。

TIME_WAIT状態のソケットの数を照会するサービスをバックグラウンドで実行し、これが特定のしきい値を超えたら、アクションを実行します（サーバーを再起動します）。どういうわけか、過去45秒以内に、サーバーを停止/起動して問題を解決できると誰かが指摘しました。これら2つのアプローチを組み合わせることをお勧めします。

WindowsのTCPスタックのデフォルト設定は、控えめに言っても、HTTPサーバーをホストするシステムには最適ではありません。

HTTPサーバーとして使用するときにWindowsマシンを最大限に活用するには、MaxUserPort TcpTimedWaitDelay、TcpAckFrequency、EnableDynamicBacklog、KeepAliveIntervalなどのように通常調整するパラメーターがいくつかあります。

最初にいくつかのクイックデフォルトが必要になった場合のために、数年前にこれに関するメモを書きました。パラメータを自由に理解してから調整してください。

AWSとは無関係に、この問題に遭遇しました。このKB記事の結果のようです。

http://support.microsoft.com/kb/2553549/en-us

基本的に、システムが497日以上稼働していて、修正プログラムが適用されていない場合に起動します。もちろん、再起動により解決されました。修正プログラムが機能するかどうかは今後16か月間はわからないかもしれませんが、長時間稼働しているサーバーを持っている人には役立つかもしれません。

Windows Server 2008 R2 x64 SP1の多くのボックスで、ほとんどがCLOSE_WAIT（TIME_WAITとは多少異なります）でほとんど同じことを経験していました。サーバーがロードバランサー（これは私のものです）の背後で実行されている場合、MicrosoftのKBと修正プログラムを参照するこの答えにぶつかりました。修正プログラムをインストールして再起動すると、CLOSE_WAITのすべてが解決されました。