Тон з'єднань TCP у стані TIME_WAIT у Windows 2008 - працює на Amazon AWS

ОС: Windows Server 2008, SP2 (працює на EC2 Amazon).

Запуск веб-програми за допомогою сервера Apache httpd & tomcat 6.02 та веб-сервера має налаштування збереження.

Є близько 69 250 (http-порт 80) + 15000 (крім порту 80) TCP-з'єднань у стані TIME_WAIT (використовується netstat & tcpview). Схоже, ці з’єднання не припиняються навіть після зупинки веб-сервера (чекали 24 години)

Лічильники монітора продуктивності:

• Активні підключення TCPv4: 145K
• Пасивні з'єднання TCPv4: 475K
• TCPv4 несправності підключення: 16K
• Скидання з'єднань TCPv4: 23K

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, ми щойно стикалися з цією проблемою, здається, в результаті цієї статті KB:

http://support.microsoft.com/kb/2553549/en-us

В основному, він починається, якщо система працює більше 497 днів, а виправлення не застосовано. Перезавантаження, безумовно, очистило його - ми можемо не знати наступні 16 місяців, чи виправлення спрацьовувало, але це може допомогти кожному, хто має довготривалі сервери там.

У багатьох ящиках із Windows Server 2008 R2 x64 із SP1 у мене спостерігалось майже точно те саме, в основному з CLOSE_WAIT (що дещо відрізняється від TIME_WAIT). Я наткнувся на цю відповідь, в якій посилався на КБ у Microsoft, і виправлення, якщо сервери працювали за балансиром навантаження (який у мене є). Після встановлення виправлення та перезавантаження всіх матеріалів CLOSE_WAIT було вирішено.