ОС: Windows Server 2008, SP2 (работает на EC2 Amazon).
Запуск веб-приложения с использованием Apache httpd и tomcat server 6.02 и веб-сервера имеет настройки проверки активности.
Существует около 69 250 (http-порт 80) + 15000 (кроме порта 80) TCP-соединений в состоянии TIME_WAIT (используется netstat и tcpview). Эти соединения не закрываются даже после остановки веб-сервера (ожидание 24 часа)
Счетчики монитора производительности:
HKEY_LOCAL_MACHINE\System \CurrentControlSet\Services\Tcpip\Parameters не имеет ключа TcpTimedWaitDelay, поэтому значение должно быть значением по умолчанию (2 * MSL, 4 минуты)
Даже если одновременно поступают тысячи запросов на подключение, почему ОС Windows не может их очистить?
В чем могут быть причины такой ситуации?
Есть ли способ принудительно закрыть все эти соединения TIME_WAIT без перезапуска ОС Windows?
Через несколько дней приложение перестает принимать новые подключения.
Мы тоже занимаемся этой проблемой. Похоже, Amazon нашла первопричину и устранила ее. Вот информация, которую они мне дали.
Привет, я вставляю ниже объяснение причин этой проблемы. Хорошая новость заключается в том, что совсем недавно это было исправлено нашей командой инженеров. Чтобы получить исправление, все, что вам нужно сделать, это ОСТАНОВИТЬ / ЗАПУСТИТЬ экземпляры Windows Server 2008, в которых вы наблюдаете эту проблему. Опять же, я не говорю о REBOOT, который отличается. STOP / START заставляет экземпляр перемещаться на другой (исправный) хост. Когда эти экземпляры запускаются снова, они будут работать на хостах, на которых установлено исправление, поэтому у них больше не будет этой проблемы. Ниже приводится инженерное объяснение этой проблемы. После тщательного исследования мы обнаружили, что при запуске Windows 2008 x64 на большинстве доступных типов экземпляров мы выявили проблему, которая может привести к тому, что TCP-соединения остаются в TIME_WAIT / CLOSE_WAIT в течение чрезмерно длительных периодов времени (в некоторых случаях , оставаясь в этом состоянии неопределенно долго). Находясь в этих состояниях, определенные пары сокетов остаются непригодными для использования, и если их накопится достаточно, это приведет к исчерпанию ресурсов соответствующих портов. Если возникает это конкретное обстоятельство, единственным решением для очистки рассматриваемых пар сокетов является перезагрузка рассматриваемого экземпляра. Мы определили, что причиной являются значения, создаваемые функцией таймера в API ядра Windows 2008, которая на многих наших 64-битных платформах время от времени будет извлекать значение, которое очень далеко в будущем. Это влияет на стек TCP, заставляя метки времени на парах сокетов TCP быть отмеченными значительно в далеком будущем. Согласно Microsoft, существует сохраненный накопительный счетчик, который не будет обновляться, если значение, созданное этим вызовом API, не будет больше накопленного значения. Конечным результатом является то, что все сокеты, созданные после этого момента, будут отмечены слишком далеко в будущем, пока не наступит это будущее время. В некоторых случаях мы видели это значение через несколько сотен дней в будущем, поэтому пары сокетов кажутся застрявшими навсегда.
Ответ Райана - хороший общий совет, за исключением того, что он не относится к состоянию, которое Рави испытывает в EC2. Мы тоже видели эту проблему, и по какой-то причине Windows полностью игнорирует TcpTimedWaitDelay и никогда не освобождает сокет из состояния TIMED_WAIT.
Ожидание не помогает ... перезапуск приложения не помогает ... единственное средство, которое мы нашли, - это перезапустить ОС. Действительно некрасиво.
Я совершенно случайно нашел этот поток, пытаясь отладить отдельную проблему, но это малоизвестная, но хорошо известная проблема с Windows на EC2. Раньше у нас была премиальная поддержка, и мы обсуждали это с ними в закрытом режиме через этот канал, но это связанный вопрос, который мы сделал обсудить на публичных форумах.
Как уже упоминали другие, вам нужно настроить серверы Windows прямо из коробки. Однако точно так же, как StopWatch не работает в указанном выше потоке, стек TCP / IP также использует QueryPerformanceCounter вызов, чтобы точно определить, когда должен длиться период TCP_TIME_WAIT. Проблема в том, что на EC2 они столкнулись и знают о проблеме, в которой QueryPerformanceCounter идет наперекосяк и может вернуться в далекое-далекое будущее; дело не в том, что ваше состояние TIME_WAIT игнорируется, а в том, что время истечения TIME_WAIT потенциально может наступить на годы вперед. При запуске с настройкой httpd вы можете увидеть, как вы быстро накапливаете эти зомби-сокеты после того, как обнаружите состояние (мы обычно видим, что это дискретное событие, а не то, что вы медленно накапливаете зомби).
Что мы делаем, так это запускаем службу в фоновом режиме, которая запрашивает количество сокетов в состоянии TIME_WAIT, и как только это значение превышает определенный порог, мы предпринимаем действия (перезагружаем сервер). Как-то в последние 45 секунд, кто-то указал, что вы можете остановить / запустить сервер, чтобы исправить проблему - я предлагаю вам объединить эти два подхода.
Настройки по умолчанию для стека TCP в Windows, мягко говоря, не оптимальны для систем, в которых будет размещаться HTTP-сервер.
Чтобы получить максимальную отдачу от вашей машины с Windows при использовании в качестве HTTP-сервера, есть несколько параметров, которые вы обычно настраиваете, например MaxUserPort TcpTimedWaitDelay, TcpAckFrequency, EnableDynamicBacklog, KeepAliveInterval и т. Д.
Я написал заметка для себя об этом несколько лет назад, на всякий случай мне нужно для начала несколько быстрых настроек по умолчанию. Не стесняйтесь разбираться в параметрах, а затем настраивать их.
Не относящийся к AWS, мы просто столкнулись с этой проблемой, кажется, в результате этой статьи базы знаний:
http://support.microsoft.com/kb/2553549/en-us
По сути, он срабатывает, если система работает> 497 дней, а исправление не было применено. Перезагрузка, конечно, устранила это - мы можем не знать в следующие 16 месяцев, сработало ли исправление, но это может помочь любому, у кого есть серверы с длительным временем безотказной работы.
Я испытал почти то же самое на нескольких компьютерах с Windows Server 2008 R2 x64 с SP1, в основном с CLOSE_WAIT (который несколько отличается от TIME_WAIT). Я наткнулся на этот ответ который ссылался на КБ в Microsoft и исправление если серверы работали за балансировщиком нагрузки (каковым является мой). После установки исправления и перезагрузки все проблемы с CLOSE_WAIT были решены.