Windows 2008 Server SP2 64bit - Соединения TCP, никогда не выпускающие после TIME_WAIT

Существует Microsoft Article, которая описывает несколько способов разрешить это. Это обычно прибывает из Приложений, которые плохо кодируются и не закрывают порты правильно. Необходимо посмотреть, в каких приложениях Вы установили, или какие задачи Вы выполняете и отключаете их для наблюдения, который вызывает проблему.

Для устранения проблемы Вы хотите посмотреть также;

1. Увеличьте верхний диапазон эфемерных портов, которые динамично выделяются клиенту сокетные соединения TCP/IP.
2. Уменьшите клиент значение тайм-аута сокетного соединения TCP/IP от значения по умолчанию 240 секунд (Более постоянная фиксация)

Amazon EC2 имел основную проблему с этим. Они недавно исправили ошибку. Возможно, та же проблема применяется в Вашей ситуации?

Привет, я вставляю ниже объяснения того, что вызывало эту проблему. Хорошие новости - то, что это было зафиксировано совсем недавно нашей командой инженеров. Для получения фиксируют, все, что необходимо будет сделать, ОСТАНАВЛИВАЮТСЯ/НАЧИНАЮТ экземпляры Windows Server 2008, где Вы видите эту проблему. Снова, я не говорю о ПЕРЕЗАГРУЗКЕ, которая отличается. ОСТАНОВИТЕСЬ/НАЧНИТЕ заставляет экземпляр перемещаться в другой (здоровый) хост. Когда эти экземпляры запустятся снова, они будут работать на хостах, которые имеют в распоряжении фиксацию, таким образом, у них не будет этой проблемы снова. Теперь ниже техническое объяснение этой проблемы. После подробно расследования, мы нашли, что при выполнении Windows 2008 x64 на большинстве доступных типов экземпляра, определили проблему, которая может привести к соединениям TCP, которые остаются в TIME_WAIT/CLOSE_WAIT в течение чрезмерно длительных промежутков времени (в некоторых случаях, оставаясь в этом состоянии неограниченно долго). В то время как в этих состояниях, конкретные пары сокета остаются неприменимыми и если достаточно накопятся, то приведет к исчерпанию порта для рассматриваемых портов. Если это конкретное обстоятельство происходит, единственное решение очистить рассматриваемых пар сокета состоит в том, чтобы перезагрузить рассматриваемый экземпляр. Мы определили причину быть значениями, произведенными таймерной функцией в ядре Windows 2008 API, который, на многих наших 64-разрядных платформах, будет иногда получать значение, которое чрезвычайно далеко в будущем. Это влияет на стек TCP, заставляя метки времени на парах сокета TCP быть штампованным значительно далеко в будущем. По данным Microsoft, существует сохраненный кумулятивный счетчик, который не будет обновлен, если значение, произведенное этим вызовом API, не будет больше, чем кумулятивное значение. Окончательный результат состоит в том, что сокеты, созданные после этой точки, будут все штампованы слишком далеко в будущем, пока то будущее время не будет достигнуто. В некоторых случаях мы видели это значение несколько сотен дней в будущее, таким образом пары сокета, кажется, застревают навсегда.

У меня была та же проблема с сервером окон 2003. Проблема была решена, когда я перезагружаю машину после реестра изменение параметра TCPIP.. Можете быть Вы, может дать ему попытку в сервере 2008

Я заметил, что эта проблема отличается, когда тот же VM (Windows 2008r2) развертывается или на Intel или на Magny-Cours AMD сервер VMware. На AMD соединения остаются в TIME_WAIT неограниченно долго, на машинах Intel они повинуются стандартным 4 минутам тайм-аут TIME_WAIT.