Мы тоже занимались этим вопросом. Похоже, Amazon нашел основную причину и исправил ее. Вот информация, которую они дали мне.
Привет, я вставляю ниже объяснение того, что стало причиной этой проблемы. Хорошей новостью является то, что это было исправлено совсем недавно нашей командой инженеров. Чтобы исправить ситуацию, все, что вам нужно сделать, это ОСТАНОВИТЬ / НАЧАТЬ экземпляры Windows Server 2008, где вы видите эту проблему. Опять же, я не говорю о REBOOT, который отличается. STOP / START вызывает перемещение экземпляра на другой (исправный) хост. Когда эти экземпляры снова запустятся, они будут работать на хостах, на которых установлено исправление, поэтому у них больше не будет этой проблемы. Ниже приведено техническое объяснение этой проблемы. После тщательного изучения мы обнаружили, что при запуске Windows 2008 x64 на большинстве доступных типов экземпляров мы Мы выявили проблему, которая может привести к тому, что TCP-соединения остаются в TIME_WAIT / CLOSE_WAIT в течение слишком продолжительных периодов времени (в некоторых случаях они остаются в этом состоянии неопределенно долго). В то время как в этих состояниях определенные пары сокетов остаются непригодными и, если накопится достаточно, приведут к исчерпанию портов для рассматриваемых портов. Если возникает это конкретное обстоятельство, единственное решение для очистки рассматриваемых пар сокетов состоит в перезагрузке рассматриваемого экземпляра. Мы определили причину, являющуюся значениями, полученными функцией таймера в API ядра Windows 2008, которая на многих наших 64-битных платформах будет иногда извлекать значение, которое чрезвычайно далеко в будущем. Это влияет на стек TCP, так как в будущем метки времени на парах сокетов TCP будут проставлены на значительном расстоянии. Согласно Microsoft, существует хранимый накопительный счетчик, который не будет обновляться, пока значение, полученное этим вызовом API, не будет больше накопленного значения. Конечным результатом является то, что сокеты, созданные после этой точки, будут проставлены слишком далеко в будущем, пока не наступит это будущее время. В некоторых случаях мы видели это значение через несколько сотен дней в будущем, поэтому пары сокетов, похоже, застряли навсегда.
QueryPerformanceCounterосновная причина проблемы все еще остается на месте, и только имеющаяся проблема с TCP устранена? Спасибо за ваше понимание!Ответ Райана - хороший общий совет, за исключением того, что он не относится к состоянию, которое Рави испытывает в EC2. Мы тоже видели эту проблему, и по любой причине Windows полностью игнорирует TcpTimedWaitDelay и никогда не освобождает сокет из своего состояния TIMED_WAIT.
Ожидание не помогает ... перезапуск приложения не помогает ... единственное найденное средство - перезапуск ОС. Действительно некрасиво.
источник
Я совершенно случайно нашел эту ветку, пытаясь отладить отдельную проблему, но это небольшая, но хорошо известная проблема с Windows на EC2. Мы привыкли иметь поддержку премиум, и это обсуждали с ними в непубличной обстановке через этот канал, но это смежный вопрос , что мы даже обсуждать в общественных форумах .
Как уже упоминали другие, вам нужно настроить Windows Servers из коробки. Однако так же, как 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, мы только что столкнулись с этой проблемой, кажется, в результате этой статьи KB:
http://support.microsoft.com/kb/2553549/en-us
По сути, оно срабатывает, если система работает> 497 дней, а исправление не применено. Перезагрузка, конечно, очистила его - мы можем не знать в течение следующих 16 месяцев, сработало ли исправление, но это может помочь любому, у кого есть серверы с длительным временем работы.
источник
Я испытывал почти то же самое на некоторых компьютерах с Windows Server 2008 R2 x64 с пакетом обновления 1 (SP1), в основном с CLOSE_WAIT (что несколько отличается от TIME_WAIT). Я наткнулся на этот ответ, который ссылался на КБ в Microsoft и исправление, если серверы работали за балансировщиком нагрузки (который у меня). После установки исправления и перезагрузки все содержимое CLOSE_WAIT было решено.
источник