大量のTCP Windows 2008のTIME_WAIT状態の接続-Amazon AWSで実行中
OS：Windows Server 2008、SP2（EC2 Amazonで実行）。
Apache httpdとTomcatサーバー6.02およびWebサーバーを使用してWebアプリを実行すると、キープアライブ設定が行われます。
約69,250（httpポート80）+ 15000（ポート80以外）がありますTCP TIME_WAIT状態の接続（netstatおよびtcpviewを使用）。これらの接続は、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を実行しているときに、TCP接続が非常に長い時間TIME_WAIT/CLOSE_WAITに残る可能性がある問題を特定しました。時間の経過（場合によっては、この状態がいつまでも続く）。これらの状態にある間、特定のソケットペアは引き続き使用できず、十分に蓄積されると、問題のポートのポートが枯渇します。この特定の状況が発生した場合、問題のソケットペアをクリアする唯一の解決策は、問題のインスタンスを再起動することです。原因は、Windows 2008カーネルAPIのタイマー関数によって生成された値であると判断しました。64ビットプラットフォームの多くでは、将来的に極端に遠い値を取得することがあります。これは、TCPソケットペアのタイムスタンプに将来的に大幅にスタンプが付けられるため、TCPスタックに影響します。 Microsoftによると、このAPI呼び出しによって生成された値が累積値よりも大きくない限り更新されない、保存された累積カウンターがあります。最終的な結果として、この時点以降に作成されたソケットは、将来、その未来の時刻に到達するまで、すべてスタンプされすぎてしまいます。場合によっては、この値が数百日先に見られるため、ソケットペアが永久に動かなくなっているように見えます。
Ryanの回答は、RaviがEC2で発生している状態には当てはまらないことを除いて、一般的なアドバイスとして適切です。私たちもこの問題を見てきました。何らかの理由でWindowsがTcpTimedWaitDelayを完全に無視し、ソケットをTIMED_WAIT状態から解放することはありません。
待っても役に立たない...アプリを再起動しても役に立たない...私たちが見つけた唯一の救済策は、OSを再起動することです。本当に醜い。
別の問題をデバッグしようとしているときにこのスレッドを完全にランダムに見つけましたが、これはEC2上のWindowsでのちょっとした、しかしよく知られた問題です。以前はプレミアムサポートがあり、そのチャネルを介して非公開の設定でこれについて話し合いましたが、- これはdid公開フォーラムで話し合います 。
他の人が述べたように、Windows Serversをすぐにチューニングする必要があります。ただし、StopWatchが上記のスレッドで機能していないのと同じように、TCP/IPスタックはQueryPerformanceCounter呼び出しも使用して、TCP_TIME_WAIT期間がいつ続くかを正確に判断します。問題は、EC2でQueryPerformanceCounterが問題を引き起こし、はるか遠い未来に時間を返す可能性があるという問題に遭遇し、それを知っていることです。 TIME_WAIT状態が無視されているのではなく、TIME_WAITの有効期限が将来何年も経過している可能性があるということです。 httpd設定で実行している場合、状態が発生するとこれらのゾンビソケットをすばやく蓄積する方法を確認できます（これは通常、ゾンビをゆっくりと蓄積するのではなく、個別のイベントであることがわかります）。
私たちが行うことは、TIME_WAIT状態のソケットの数を照会するサービスをバックグラウンドで実行し、これが特定のしきい値を超えると、アクション（サーバーの再起動）を実行することです。どういうわけか過去45秒で、問題を修正するためにサーバーを停止/起動できると誰かが指摘しました-これらの2つのアプローチを組み合わせることをお勧めします。
AWSとは関係なく、この問題に遭遇しました。これは、このKB記事の結果であると思われます。
http://support.Microsoft.com/kb/2553549/en-us
基本的に、システムが497日を超えて稼働していて、修正プログラムが適用されていない場合に起動します。もちろん、再起動によって問題は解決しました。修正プログラムが機能したかどうかは、次の16か月間はわからないかもしれませんが、これにより、稼働時間の長いサーバーを使用しているすべての人に役立ちます。
WindowsのTCPスタックのデフォルト設定は、控えめに言っても、HTTPサーバーをホストするシステムには最適ではありません。
HTTPサーバーとして使用するときにWindowsマシンを最大限に活用するために、MaxUserPort TcpTimedWaitDelay、TcpAckFrequency、EnableDynamicBacklog、KeepAliveIntervalなど、通常は微調整するいくつかのパラメーターがあります。
数年前にこれについて self to note を書きましたが、最初に簡単なデフォルトが必要な場合に備えて。パラメータを自由に理解してから、微調整してください。
私はWindows Server 2008 R2 x64 SP1の多くのボックスでほとんど同じ問題を経験していました。サーバーがロードバランサーの背後で実行されている場合、私は この回答 が MicrosoftでのKBとホットフィックス を参照した場合に遭遇しました（私のものです）。修正プログラムをインストールして再起動した後、CLOSE_WAITに関するすべての問題が解決されました。