Пытаясь выяснить причину этой проблемы root в течение нескольких недель безуспешно, надеюсь, кто-то найдет новые идеи, где искать.
У нас есть Inprocess. NET Основное приложение, работающее на Windows 2012RC2 с IIS Ver 8.5 (net базовый хостинг 2.2.6). Это приложение дублируется на 2 серверах с одинаковым IP через Windows NLB. Обе машины являются физическими с недавним подключением HW и 1 ГБ
Трафик c, управляемый приложением, ИМХО не настолько высок (300 запросов в минуту !!)
Однако, случайным образом, когда IIS пул приложений перерабатывается, приложение не может отправить ACK из последовательности TCP для подтверждения CLOSE_WAIT. Завершение с экспоненциальным числом соединения close_wait сравнение ожиданий закрытия (см. Traffi c изображение 2 серверов на момент выдачи)
Сервер в одной точке больше не может ничего обслуживать.
Это закончится либо тем, что по умолчанию будет установлено время ожидания активности windows, либо если мы снова вручную перезапустим пул приложений.
Просмотр инструмента tcpview в то время, ожидание закрытия связано с системным процессом, поэтому он не может узнать, является ли новый рабочий процесс или закрывающим , который вызвал эту проблему.
Чего я не понимаю, так это почему вдруг приложение не может подтвердить новые вызовы close_wait?
- Из-за "VIP" (NLB), совместно используемого серверами? Для нас конфигурация и трафик HB c кажутся нормальными.
- Что-то не так с IIS и. net ядром Inprocess модель? Разве никто не жаловался на это
- Неправильно ли выполнено какое-либо определение httpclient в коде? разработчики посмотрели объявление, там тоже ничего плохого не нашли
- Разве приложение не может отправить
ACK или не может обнаружить FIN_ACK2? довольно трудно увидеть, когда увеличение ожидания закрытия увеличивается так быстро, даже при дампе Wireshark на большом сервере
Смягчение было направлено на сокращение Windows времени поддержки активности и контроль утилизации при очень низком трафике c времени, но я хотел бы знать, если любая другая идея, где копаться, или имел ту же проблему ...