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


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

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

  • Предельный интервал под CPU от 5 до 0.
  • Idle Time-out в модели процесса от 20 до 0.
  • Регулярный интервал времени при переработке с 1740 до 0.

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

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

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

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


65
2017-11-22 23:29


Источник


Где вы взяли этот снимок экрана с настройками IIS? - Andrew William Ross


Ответы:


Переработка

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

* - обычно: см. DisallowOverlappingRotation / Настройка "Disable overlapped recycle"

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

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

настройки

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

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

Теперь, вот некоторые вещи, которые могут вызвать рециркуляцию той или иной формы:

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

Что делать:

В общем:

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

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

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

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

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

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

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

Но ... тогда мы попадаем в .Net землю и утилиту AdDomain, которая также может привести к потере состояния. (Видеть: 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, вызывая уведомление об изменении, вызывая ....


86
2017-11-23 05:07





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

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

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

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

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


1
2017-11-19 08:03



Одна из причин заключалась в том, что .NET использует отдельную кучу для «больших объектов» (обычно 85 КБ или больше или что-то еще), которая не сжимается при сборке мусора (хотя в .NET 4.5.1 я думаю, что они добавили вариант для уплотнения LOH) и в ASP.NET при рендеринге HTML на стороне сервера нередко можно увидеть 85K HTML (особенно для повторяющегося контента, такого как таблицы и сетки), и этот HTML-код в основном в какой-то момент является просто огромным объектом String на сервере, и если он квалифицируется как большой объект, он способствует фрагментации кучи больших объектов, что в конечном итоге приводит к исключению OutOfMemoryException, следовательно, к рециркуляции - nothingisnecessary


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


0
2017-08-29 07:59