Назад | Перейти на главную страницу

Что мне делать, чтобы убедиться, что IIS не перерабатывает мое приложение?

У меня есть приложение службы WCF, размещенное в IIS. При запуске он извлекает очень дорогой (с точки зрения времени и ЦП) ресурс для использования в качестве локального кеша.

К сожалению, похоже, что IIS перерабатывает этот процесс на довольно регулярной основе. Поэтому я пытаюсь изменить настройки пула приложений, чтобы убедиться, что IIS не перерабатывает приложение. Пока что я изменил следующее:

Этого будет достаточно? И у меня есть конкретные вопросы по предметам, которые я изменил:

  1. Что конкретно означает установка предельного интервала для CPU? Означает ли это, что при превышении определенной загрузки ЦП пул приложений будет переработан?
  2. Что именно означает «переработанный»? Приложение полностью разорвано и снова запущено?
  3. В чем разница между «Завершением рабочего процесса» и «перезапуском пула приложений»? В документации для тайм-аута простоя в модели процесса говорится о завершении рабочего процесса. В то время как в документации для Regular Time Interval в разделе Recycling говорится о переработке пула приложений. Я не совсем понимаю разницу между ними. Я думал, что w3wp.exe - это рабочий процесс, который запускает пул приложений. Может ли кто-нибудь объяснить разницу между двумя приложениями?

Причина наличия тегов IIS7 и IIS7.5 заключается в том, что приложение будет работать в обоих и надеяться, что ответы будут одинаковыми для разных версий.

Изображение для справки:

Переработка

Переработка обычно * заключается в том, что IIS запускает новый процесс как контейнер для вашего приложения, а затем передает старый процесс ShutdownTimeLimit, чтобы тот ушел по собственному желанию, прежде чем он будет уничтожен.

* - обычно: см. параметр DisallowOverlappingRotation / «Отключить повторное использование с перекрытием»

это разрушительный, в том, что исходный процесс и вся информация о его состоянии отбрасываются. Использование внепроцессного состояния сеанса (например, сервера состояний или базы данных или даже файла cookie, если ваше состояние крошечное) может позволить вам обойти это.

Но по умолчанию перекрытый - это означает, что продолжительность простоя сведена к минимуму, потому что новый процесс запускается и подключается к очереди запросов, прежде чем старому сообщается, что «у вас есть [ShutdownTimeLimit] секунд до завершения. Пожалуйста, подчинитесь».

Настройки

На ваш вопрос: все настройки на этой странице так или иначе контролируют переработку. «Завершение работы» можно описать как «упреждающую переработку» - когда сам процесс решает, что пора идти, и завершается упорядоченным образом.

Реактивная переработка - это когда WAS обнаруживает проблему и запускает процесс (после создания подходящей замены W3WP).

Вот некоторые вещи, которые могут вызвать переработку в той или иной форме:

  • ISAPI решает, что это нездорово
  • сбой любого модуля
  • время простоя
  • ограничение процессора
  • настройка свойств пула приложений
    • как твоя мама может кричали в какой-то момент: "Стоп сбор на это, иначе никогда не станет лучше! "
  • Ошибка "ping" * на самом деле не ping как таковой, потому что он использует именованный канал - больше "обнаружение жизни"
  • все настройки на скриншоте выше

Что делать:

В общем-то:

  • Отключить Таймауты простоя. 20 минут бездействия = бум! Новый процесс при следующем входящем запросе. Установите это на ноль.

  • Отключить Обычный временной интервал - значение по умолчанию в 29 часов было охарактеризовано различными сторонами как «безумное», «раздражающее» и «умное». На самом деле только два из них верны.

  • Необязательно Включи DisallowRotationOnConfigChange (выше, Отключить повторное использование для изменений конфигурации), если вы просто не можете перестать играть с ним - это позволяет вам изменить любую настройку пула приложений без мгновенного сообщения рабочим процессам о том, что его нужно убить. Вам необходимо вручную переработать пул приложений, чтобы настройки вступили в силу, что позволяет вам предварительно установить настройки, а затем использовать окно изменения, чтобы применить их в процессе переработки.

  • Как правило, покинуть звон включен. Это ваша подстраховка. Я видел, как люди выключали его, а затем сайт иногда зависал на неопределенное время, что приводило к панике ... поэтому, если настройки слишком агрессивны для вашего явно-очень-очень-очень медленно реагирующего приложения, немного их отключите и посмотрите, что у вас получится, а не выключите его. (Если у вас не настроен дамп в автоматическом режиме сбоя для зависших W3WP через ваш собственный процесс мониторинга)

Этого достаточно, чтобы хорошо управляемый процесс жил вечно. Если он сдохнет, конечно, его заменит. Если он зависает, пинг должен это исправить, и новый должен начаться в течение 2 минут (по умолчанию; в худшем случае calc должно быть: до частота пинга + время ожидания пинга + ограничение по времени запуска прежде, чем запросы снова начнут работать).

Ограничения ЦП нет как обычно интересно, потому что по умолчанию он выключен, а также настроен на то, чтобы ничего не делать; если бы он был настроен на уничтожение процесса, конечно, это было бы триггером перезапуска. Оставь это. Обратите внимание, что для IIS 8.x регулирование ЦП также становится опцией.

(IIS) AppPool не является (.Net) AppDomain (но может содержать один или несколько)

Но ... затем мы попадаем в область .Net и перезапуск AppDomain, что также может вызвать потерю состояния. (Видеть: https://blogs.msdn.microsoft.com/tess/2006/08/02/asp-net-case-study-lost-session-variables-and-appdomain-recycles/)

В сокращенной версии вы делаете это, касаясь файла web.config в папке с контентом (снова с помощью выбора!), Или создавая папку в этой папке, или файл ASPX, или ... другие вещи ... и это около так же разрушительно, как и переработка пула приложений, минус стоимость запуска собственного кода (это чисто концепция управляемого кода (.Net), поэтому здесь происходит только управляемый код).

Антивирус также может вызвать это, поскольку он сканирует файлы web.config, вызывая уведомление об изменении, вызывая ....

Пожалуйста, проверьте,

Почему мы перерабатываем пулы приложений?

если вы просматриваете Интернет, чтобы найти причину, по которой пулы приложений настроены на периодическую автоматическую переработку, вам будет сложно найти разумный ответ, не имеющий отношения к проблемам с памятью. Как будто сообщество в целом согласилось с тем фактом, что наши веб-приложения (или слои служб, размещенные в IIS) необходимо будет переработать, чтобы избежать проблем с памятью.

Я всегда считал, что Если ваш код требует периодических перезапусков для правильной работы, значит, что-то явно не так. Есть ошибка где-то в вашем коде, и вам нужно это исправить, вместо того, чтобы время от времени перезапускать процесс, чтобы проблема «исчезла».

На самом деле нужно сосредоточиться больше на управление памятью в .NET и убедиться, что наши приложения могут работать без проблем.

На основе сценария OP (длительная инициализация при запуске / прогреве) еще одна вещь, которую нужно проверить, это Ограничение времени запуска (секунды), значение по умолчанию - 90 секунд. Если инициализация занимает больше времени, чем лимит времени запуска, рабочий процесс может быть прекращен.