У меня есть приложение службы WCF, размещенное в IIS. При запуске оно идет и извлекает очень дорогой (с точки зрения времени и процессора) ресурс для использования в качестве локального кэша.
К сожалению, IIS, похоже, довольно регулярно перезапускает процесс. Поэтому я пытаюсь изменить настройки в Application Pool, чтобы убедиться, что IIS не перезапускает приложение. Пока что я изменил следующее:
- Предельный интервал под CPU от 5 до 0.
- Время простоя в модели процесса от 20 до 0.
- Регулярный временной интервал при рециркуляции с 1740 по 0.
Этого будет достаточно? И у меня есть конкретные вопросы по пунктам, которые я изменил:
- Что конкретно означает параметр Limit Interval в разделе CPU? Означает ли это, что при превышении определенного использования CPU пул приложений будет перезапущен?
- Что именно означает «переработано»? Приложение полностью снесено и запущено заново?
- В чем разница между «Завершением рабочего процесса» и «Перезапуском пула приложений»? В документации по тайм-ауту простоя в разделе «Модель процесса» говорится о завершении рабочего процесса. В то время как в документации по регулярному интервалу времени в разделе «Перезапуск» говорится о перезапуске пула приложений. Я не совсем понимаю разницу между ними. Я думал, что w3wp.exe — это рабочий процесс, который запускает пул приложений. Может кто-нибудь объяснить разницу для приложения между ними?
Причина наличия тегов IIS7 и IIS7.5 заключается в том, что приложение будет работать в обеих версиях и надеяться, что ответы будут одинаковыми для обеих версий.
Изображение для справки:
решение1
Переработка
Повторное использование обычно* происходит, когда IIS запускает новый процесс в качестве контейнера для вашего приложения, а затем позволяет старому процессу ShutdownTimeLimitзавершиться по собственной воле, прежде чем он будет завершен.
*- обычно: см. DisallowOverlappingRotation/ Настройка «Отключить перекрывающуюся перезагрузку»
Эторазрушительный, в котором исходный процесс и вся информация о его состоянии отбрасываются. Использование состояния сеанса вне процесса (например, State Server или базы данных, или даже cookie, если ваше состояние крошечное) может позволить вам обойти это.
Но это по умолчаниюперекрывающиеся- это означает, что продолжительность простоя сводится к минимуму, поскольку новый процесс запускается и подключается к очереди запросов до того, как старому будет сообщено: «У вас есть [ ShutdownTimeLimit] секунд, чтобы уйти. Пожалуйста, подчинитесь».
Настройки
На ваш вопрос: все настройки на этой странице каким-то образом управляют переработкой. «Выключение» можно описать как «упреждающую переработку» — когда процесс сам решает, что пора идти, и завершается упорядоченным образом.
Реактивная переработка — это процесс, при котором WAS обнаруживает проблему и прекращает процесс (после установления подходящей замены W3WP).
Итак, вот некоторые вещи, которые могут стать причиной переработки в той или иной форме:
- ISAPI решает, что это нездорово
- любой модуль падает
- тайм-аут простоя
- ограничение процессора
- настройка свойств пула приложений
- как твоя мамаможетв какой-то момент закричали: «Стойсборв этом, иначе лучше уже не будет!»
- Ошибка "ping" * на самом деле это не пинг, как таковой, поскольку используется именованный канал - больше "обнаружение жизни"
- все настройки на скриншоте выше
Что делать:
В целом:
ЗапрещатьТайм-ауты простоя. 20 минут бездействия = бум! Старый процесс исчез! Новый процесс при следующем входящем запросе. Установите его на ноль.
ЗапрещатьРегулярный интервал времени- 29-часовой дефолт описывался разными сторонами как «безумный», «раздражающий» и «умный». На самом деле, только два из этих утверждений верны.
НеобязательноВключатьDisallowRotationOnConfigChange(выше,Отключить повторное использование для изменений конфигурации) если вы просто не можете перестать играть с ним - это позволяет вам изменять любые настройки пула приложений без мгновенного сигнала рабочим процессам о том, что его нужно завершить. Вам нужно вручную перезапустить пул приложений, чтобы настройки вступили в силу, что позволяет вам предварительно задать настройки, а затем использовать окно изменений, чтобы применить их через процесс перезапуска.
Как общий принцип,оставлятьпингованиевключено. Это ваша страховочная сетка. Я видел, как люди отключали ее, и тогда сайт иногда зависал на неопределенное время, что приводило к панике... так что если настройки слишком агрессивны для вашего, по-видимому, очень-очень медленно реагирующего приложения, немного уменьшите их и посмотрите, что получится, вместо того, чтобы отключать ее. (Если только у вас не настроена автоматическая выгрузка режима сбоя для зависших W3WP через ваш собственный процесс мониторинга)
Этого достаточно, чтобы заставить хорошо работающий процесс жить вечно. Если он умирает, конечно, он будет заменен. Если он зависает, пинг должен это обнаружить, и новый должен начаться в течение 2 минут (по умолчанию; худший расчет должен быть: дочастота пинга+тайм-аут пинга+ограничение времени запускадо того, как запросы снова начнут работать).
Ограничение ЦП необычноинтересно, потому что по умолчанию он выключен, и он также настроен на то, чтобы ничего не делать; если бы он был настроен на завершение процесса, конечно, это был бы триггер переработки. Оставьте его выключенным. Примечание для IIS 8.x, CPU Throttling также становится опцией.
(IIS) AppPool не является (.Net) AppDomain (но может содержать один/несколько)
Но... затем мы попадаем в мир .Net и AppДоменпереработка, которая также может привести к потере состояния. (См.:https://blogs.msdn.microsoft.com/tess/2006/08/02/asp-net-case-study-lost-session-variables-and-appdomain-recycles/)
Коротко говоря, это можно сделать, открыв файл web.config в папке с содержимым (снова с подбором!), или создав папку в этой папке, или файл ASPX, или... другие вещи... и этоостоль же разрушительный, как и переработка App Pool,минусзатраты на запуск собственного кода (это чисто концепция управляемого кода (.Net), поэтому здесь происходит только инициализация управляемого кода).
Антивирус также может вызвать эту ошибку, поскольку он сканирует файлы web.config, вызывая уведомление об изменении, что приводит к...
решение2
Пожалуйста, проверьте,
Почему мы перерабатываем наши пулы приложений?
Если вы просматриваете веб-страницы, чтобы найти причину, по которой пулы приложений настроены на автоматическую периодическую очистку,вам будет трудно найти разумный ответ, который не относится к проблемам памяти. Похоже, сообщество в целом в значительной степени приняло тот факт, что наши веб-приложения(или уровни служб, размещенные в IIS) необходимо будет перезапустить, чтобы избежать проблем с памятью.
Я всегда придерживался мнения, чтоЕсли ваш код требует периодических перезапусков для корректной работы, то что-то явно не так. Ошибкагде-то в вашем коде, и вам нужно это исправить, вместо того чтобы время от времени перезапускать процесс, чтобы проблема «исчезла».
Действительно нужно начать больше концентрироваться науправление памятьюв .NET и на обеспечении бесперебойной работы наших приложений.
решение3
Исходя из сценария OP (долгая инициализация при запуске/прогреве), еще одна вещь, которую следует проверить, этоОграничение по времени запуска(секунды), значение по умолчанию которого составляет 90 секунд. Если инициализация занимает больше времени, чем предел запуска, рабочий процесс может быть завершен.
решение4
Ответ: выможетпредотвратить перезапуск AppPool, но выне должна.
Причина в том, что если произойдет утечка памяти, она в конечном итоге съест всю память сервера, и Windows выдаст синий экран или исключения нехватки памяти, которые приведут к остановке других сайтов на том же сервере IIS.
Итак, решите, какой объем памяти разрешено использовать этому сайту, и установите указанные выше настройки для перезарядки при достижении этого лимита.
Обычно перезапуск выполняется изящно, так что конечные пользователи не знают об этом. Но если вы используете Blazor Server, то все сеансы выполняются на сервере, и все состояние будет потеряно. На практике я вижу, как приложение Blazor показывает сообщение «подключение...» в течение примерно 5 секунд, пока происходит перезапуск. Другими словами, это не изящно для приложений Blazor на стороне сервера.
Мораль истории такова, как уже упоминалось ранее: убедитесь, что ваш сайт не допускает утечек памяти. Проверяйте память на ранних этапах процесса разработки, не ждите, пока все заработает, поскольку Blazor Server потребляет много памяти, и по моему опыту мне пришлось потратить немало времени на отладку проблем с памятью. Это не недостаток Blazor, просто в природе приложений Blazor Server заложено требование очень плотного кода. Раньше в .net я никогда не беспокоился о памяти, так как GC справлялся со всем этим, но запуск внутри IIS — это совсем другая история.