Что вызывает перезапуск пула приложений в IIS?

Question

Я искал информацию об этом безрезультатно. Контекст того, зачем мне это нужно, это другой вопрос, который я задал здесь . Более конкретно, вызывает ли создание / обновление / удаление файлов в App_Data перезапуск пула?

Если бы кто-то мог предоставить подробный список причин, по которым происходит переработка, это было бы замечательно.

ОБНОВЛЕНИЕ : Как уже заметили два пользователя, я также был бы рад ответить на него, указав причины перезапуска только домена приложений, а не всего пула.

Answer 1

Статья, которая вам понравилась в другом посте, действительно отлично справилась с этой задачей.

Немедленная переработка

• Web.config изменения
• Изменения Machine.config
• Global.asax изменения
• Изменения в каталоге бинов
• Изменения кода приложения

Задержка корзины

Может произойти с несколькими изменениями в других местах, как правило, я заметил это только с изменениями в файлах .aspx или .cs / .vb. Добавление временного текста, csv или других файлов не привело к проблемам для меня.

ПРИМЕЧАНИЕ. Все это повторы использования домена приложения, а не фактические повторения пула. Обычно POOL приложения будет перезагружаться только на основе настроек в IIS (количество запросов, ограничение памяти, время простоя или запланированный перезапуск).

Answer 2

Два разных эффекта - процесс AppPool является хостом для потенциально нескольких доменов приложений. Как правило, это может быть переработано с помощью ряда эффектов, например, время - каждые n часов, отсутствие запросов, использование памяти и т. д. Настроено в IIS Config Manager.

AppDomain - размещенный экземпляр корневого каталога вашего приложения, который можно циклически чаще выполнять, не затрагивая другие домены приложений в AppPool. Сообщение Тесс об утилизации AppDomain довольно проницательное

http://blogs.msdn.com/tess/archive/2006/08/02/asp-net-case-study-lost-session-variables-and-appdomain-recycles.aspx

Вы пишете в папку, отслеживаемую на предмет перекомпиляции - это в какой-то момент вызовет воссоздание домена приложения.

Журнал событий поможет вам определить причину, инициировавшую переработку.

Answer 3

Возможно, вы захотите включить полные журналы событий AppPool Recycle:

cscript adsutil.vbs Set w3svc/AppPools/DefaultAppPool/LogEventOnRecycle 255 

Возможно, вы также захотите взглянуть на статью блога Скотта Гатри: http://weblogs.asp.net/scottgu/archive/2005/12/14/433194.aspx, в которой показано, как писать код в Global.ASAX для регистрации фактической причины события Application.End.

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

Answer 4

Это может происходить ежедневно на основе предпочтений или при превышении максимальной виртуальной памяти для процесса.

Answer 5

Это параметр, которым вы можете манипулировать для перезапуска пула приложений в зависимости от количества запущенных минут или количества обработанных запросов.

Он также будет перерабатывать изменения web.config и другие вещи, которые были опубликованы здесь.

Сброс IIS также поможет, как и остановка / запуск служб.

Answer 6

w3wp.exe произошла ошибка. Это вызывало вызов Application_Start в Global.asax.

Чтобы это выяснить, я открыл Просмотр событий .

Под Журналы Windows Я перешел на Приложение .

Я увидел Ошибка приложения :

Faulting application name: w3wp.exe, version: 10.0.16299.15, time stamp: 0x0aeb5595
Faulting module name: KERNELBASE.dll, version: 10.0.16299.334, time stamp: 0x6369e29f
Exception code: 0xe0434352
Fault offset: 0x0000000000014008
Faulting process id: 0x2900
Faulting application start time: 0x01d43b16f726cbb9
Faulting application path: c:\windows\system32\inetsrv\w3wp.exe
Faulting module path: C:\WINDOWS\System32\KERNELBASE.dll
Report Id: 998cf55d-2cd9-4b8d-9884-2110e3fd1411
Faulting package full name: 
Faulting package-relative application ID: