У нас есть проблема с Windows 2008 Datacenter edition SP2 64bit. У нас есть процесс, который очень часто опрашивает и устанавливает новые TCP-соединения. Система переходит в состояние, при котором более 16 тыс. Соединений находятся в состоянии TIME_WAIT. Тайм-аут ОС по умолчанию составляет 120 секунд, после чего эти соединения должны исчезнуть, но этого никогда не происходит. Эти соединения сохраняются и никогда не очищаются даже после того, как исходный процесс давно завершился (мы все еще находимся на уровне 16k соединений через два дня после того, как процесс был убит). Предполагается, что ОС будет их отключать, но это не так.
Кто-нибудь еще видел такое поведение, и если да, то что было сделано для его устранения. Мы знаем, как настроить стек tcp, чтобы уменьшить время ожидания или разрешить больше подключений, но здесь проблема не в этом.
Спасибо!
У Amazon EC2 с этим была большая проблема. Недавно они исправили ошибку. Может быть, та же проблема применима к вашей ситуации?
Привет, я вставляю ниже объяснение причин этой проблемы. Хорошая новость заключается в том, что совсем недавно это было исправлено нашей командой инженеров. Чтобы получить исправление, все, что вам нужно сделать, это ОСТАНОВИТЬ / ЗАПУСТИТЬ экземпляры Windows Server 2008, в которых вы наблюдаете эту проблему. Опять же, я не говорю о REBOOT, который отличается. STOP / START заставляет экземпляр перемещаться на другой (исправный) хост. Когда эти экземпляры запускаются снова, они будут работать на хостах, на которых установлено исправление, поэтому у них больше не будет этой проблемы. Ниже приводится инженерное объяснение этой проблемы. После тщательного исследования мы обнаружили, что при запуске Windows 2008 x64 на большинстве доступных типов экземпляров мы выявили проблему, которая может привести к тому, что TCP-соединения остаются в TIME_WAIT / CLOSE_WAIT в течение чрезмерно длительных периодов времени (в некоторых случаях , оставаясь в этом состоянии неопределенно долго). Находясь в этих состояниях, определенные пары сокетов остаются непригодными для использования, и если их накопится достаточно, это приведет к исчерпанию ресурсов соответствующих портов. Если возникает это конкретное обстоятельство, единственным решением для очистки рассматриваемых пар сокетов является перезагрузка рассматриваемого экземпляра. Мы определили, что причиной являются значения, создаваемые функцией таймера в API ядра Windows 2008, которая на многих наших 64-битных платформах время от времени будет извлекать значение, которое очень далеко в будущем. Это влияет на стек TCP, заставляя метки времени на парах сокетов TCP быть отмеченными значительно в далеком будущем. Согласно Microsoft, существует сохраненный накопительный счетчик, который не будет обновляться, если значение, созданное этим вызовом API, не будет больше накопленного значения. Конечным результатом является то, что все сокеты, созданные после этого момента, будут отмечены слишком далеко в будущем, пока не наступит это будущее время. В некоторых случаях мы видели это значение через несколько сотен дней в будущем, поэтому пары сокетов кажутся застрявшими навсегда.
Eсть Статья Microsoft в котором описаны несколько способов решения этой проблемы. Обычно это происходит из приложений, которые плохо закодированы и неправильно закрывают порты. Вам нужно посмотреть, какие приложения вы установили или какие задачи вы выполняете, и отключить их, чтобы увидеть, что вызывает проблему.
Чтобы решить эту проблему, вы хотите посмотреть:
У меня была такая же проблема с сервером Windows 2003. Проблема была решена, когда я перезагружал машину после изменения параметра TCPIP в реестре. Может быть, вы можете попробовать на сервере 2008
Я заметил, что эта проблема отличается, когда одна и та же виртуальная машина (Windows 2008r2) развертывается на сервере Intel или AMD Magny-Cours VMware. На AMD соединения остаются в TIME_WAIT неопределенно долго, на машинах Intel они подчиняются стандартному 4-минутному таймауту TIME_WAIT.