Windows 2008 Server SP2 64ビット-TCP TIME_WAIT後に接続が解放されない
Windows 2008 DatacenterエディションSP2 64ビットに問題があります。非常に頻繁にポーリングして新しいTCP=接続を確立するプロセスがあります。システムは、TIME_WAIT状態で16kを超える接続で終了する状態になります。デフォルトのOSタイムアウトは、120秒後にこれらの接続はなくなりますが、それは決して起こりません。これらの接続は持続し、元のプロセスが長時間終了した後でもクリーンアップされません（プロセスが終了してから2日後も16k接続のままです）。それらは出ますが、そうではありません。
他の誰かがこの振る舞いを見たことがありますか？ tcpスタックを調整してタイムアウトを短くしたり、接続数を増やしたりする方法はわかっていますが、ここでは問題になりません。
ありがとう！
Amazon EC2はこれに関して大きな問題を抱えていました。彼らは最近バグを修正しました。多分同じ問題があなたの状況に当てはまりますか？
こんにちは、私はこの問題を引き起こしているものの説明の下に貼り付けています。幸いなことに、これはごく最近、エンジニアリングチームによって修正されました。修正するには、この問題が発生しているWindows Server 2008インスタンスを停止/開始するだけです。繰り返しますが、私は違うREBOOTについて話していません。 STOP/STARTにより、インスタンスは別の（正常な）ホストに移動します。これらのインスタンスが再度起動すると、修正が適用されているホスト上で実行されるため、この問題は再び発生しなくなります。次に、この問題の技術的な説明を示します。詳細な調査の結果、ほとんどの利用可能なインスタンスタイプでWindows 2008 x64を実行しているときに、TCP接続が過度に長期間TIME_WAIT/CLOSE_WAITに残る可能性がある問題を特定しました。時間の経過（場合によっては、この状態がいつまでも続く）。これらの状態にある間、特定のソケットペアは使用できないままであり、十分に蓄積されると、問題のポートのポートが枯渇します。この特定の状況が発生した場合、問題のソケットペアをクリアする唯一の解決策は、問題のインスタンスを再起動することです。原因は、Windows 2008カーネルAPIのタイマー関数によって生成された値であると判断しました。64ビットプラットフォームの多くでは、将来的に極端に遠い値を取得することがあります。これは、TCPソケットペアのタイムスタンプに将来大幅にスタンプされることにより、TCPスタックに影響を与えます。 Microsoftによると、このAPI呼び出しによって生成された値が累積値よりも大きくない限り更新されない、保存された累積カウンターがあります。最終的な結果として、この時点以降に作成されたソケットは、将来、その未来の時刻に到達するまで、あまりに遠くにスタンプされます。場合によっては、この値が数百日先に見られるため、ソケットペアが永久に動かなくなっているように見えます。
これを解決するいくつかの方法を説明する Microsoft Article があります。これは一般的に、正しくコーディングされておらず、ポートを正しく閉じないアプリケーションから発生します。インストールしたアプリケーション、または実行しているタスクを確認し、これらを無効にして、問題の原因を特定する必要があります。
この問題を修正するには、どちらかを確認する必要があります。
- クライアントのTCP/IPソケット接続に動的に割り当てられる一時ポートの上限を増やします。
- クライアントのTCP/IPソケット接続タイムアウト値をデフォルト値の240秒から減らします（より永続的な修正）。
同じVM（Windows 2008r2）がIntelまたはAMDのいずれかのMagny-Cours VMwareサーバーにデプロイされている場合、この問題が異なることに気づきました。AMDでは、接続は無制限にTIME_WAITのままです。 Intelマシンは標準の4分のTIME_WAITタイムアウトに従います。
Windows 2003サーバーでも同じ問題が発生しました。レジストリのTCPIPパラメータを変更した後でマシンを再起動すると問題が解決しました。サーバー2008で試してみてください。