システムの取得に十分なバッファスペースがないか、キューがいっぱいだったため
ASP.NETおよびSQL Server 2012アプリケーションがWindows Server 2008 R2で実行されています。突然、サーバー上のインターネットが機能しなくなり、アプリケーションがスローし始めました。
An operation on a socket could not be performed because the system lacked sufficient buffer
space or because a queue was full
PID = 0が多くのポートを開いていることを示すnetstatの実行。 Netstatは、
Process Id = 0, State = TIME_WAIT have 130,053 ports open
Process Id = 38840, State = CLOSE_WAIT have 5 ports open
Process Id = Any, State = LISTENING have 30 ports open
Process Id = Any, State = ESTABLISHED have 10 ports open
統計2015年12月22日
CLOSE_WAIT 5
ESTABLISHED 146
TIME_WAIT 646750
LAST_ACK 1
LISTENING 30
複数のモバイルデバイスからブラウザーによってアクセスされるWebサーバーを実行しています。
TCP/IPの仕組みにより、接続をすぐに閉じることはできません。パケットは順不同で到着するか、接続が閉じられた後に再送信される場合があります。 CLOSE_WAITは、リモートエンドポイント（接続の反対側）が接続を閉じたことを示します。 TIME_WAITは、ローカルエンドポイント（こちら側）が接続を閉じたことを示します。遅延パケットを接続に一致させて適切に処理できるように、接続は維持されています。接続は、デフォルトの4分以内にタイムアウトになると削除されます。
それにもかかわらず、TIME_WAIT統計の横の数値646750は非常に大きくなっています。つまり、過去4分間に646750の接続が閉じられ、1秒あたり2694になります。明らかに、これらのモバイルデバイスの一部は非常に誤動作しており、クライアント側から適切に閉じられていない接続、または膨大な数のクライアントにサービスを提供している（単一のサーバーには意味がありません）接続でサーバーを攻撃しています。
問題の原因となっているモバイルデバイスまたはアプリケーションを特定して修正できない場合は、クライアント側を制御せず、サーバー側でのみ問題を軽減できます。
この輻輳を改善できる1つのパラメーターは TcpTimedWaitDelay で、次のように記述されます。
TCPが閉じた接続を解放してそのリソースを再利用できるようになるまでに経過する必要のある時間を決定します。この閉じと解放の間隔はTIME_WAIT状態または2MSL状態と呼ばれます。この間、接続は新しい接続を確立するよりもはるかに少ないコストでクライアントとサーバーを再開できます。
このエントリの値を減らすと、TCPが閉じた接続をより早く解放し、新しい接続により多くのリソースを提供できるようになります。ただし、値が低すぎる場合、TCP接続が完了する前に接続リソースを解放し、サーバーが追加のリソースを使用して接続を再確立するように要求します。
TcpTimedWaitDelayはHKLM\SYSTEM\CurrentControlSet\Services\Tcpip\Parametersのregeditで変更できます。待機する秒数が含まれています。デフォルトは240秒（4分）です。変更した場合は再起動が必要です。
たとえば、30秒に変更し、1秒あたりの接続数が2694の場合、80820接続のみがクローズを待機していることになります。この数は依然として膨大ですが、この変更により接続リソースの使用量が削減されます。