останавливается пул приложений iis
Останавливается пул приложений iis
Вопрос
После переноса веб-приложений с 2003 сервера (х32) столкнулся со следующей проблемой:
Раз в несколько дней падает пул приложений, на котором крутится одно из приложений. Почему и после чего это происходит, пока неясно.
В логах при падении появляются следующие записи:
После этого пул приложений, согласно настройкам пытается перезапуститься:
и благополучно выключается после последней попытки:
В application log появляется следующая запись:
День потыкавшись по интернету, нашел, что 0xc0000005 это access violation error, т.е. вроде как баг в самом w3wp.exe. Разрабочики утверждают, что приложение написано таким образом, что никак не может влиять на работу веб-сервера (что, в принципе, и похоже на правду, т.к. в течении двух лет это все без проблем крутилось на IIS 6 x32).
Поиск по интернету ничего толком не дал. Нашел несколько схожих тем, где, как варианты решения проблем, были указаны запуск пула приложений из-под существующего пользователя (что я попробовал) и дать права этому пользователю на чтение/запись каталога с веб-сайтом. Также найдена статья в базе знаний, описывающая нечто схожее http://support.microsoft.com/kb/913384 и предлагающая фикс, но он неприменим в моем окружении.
Каким образом можно отследить, в чем причина падения пула приложений?
IIS 7.5 установлен с минимальными настройками (IIS 6 до этого тоже стоял с настройками по-умолчанию).
Пул приложений превышает ограничения по времени при закрытии IIS
При превышении пулом приложений ограничений по времени при остановке Microsoft IIS (IIS) может возникнуть непредвиденное время работы.
Оригинальная версия продукта: службы IIS 7,0, 7,5
Исходный номер КБ: 2634635
Симптомы
На компьютере с iiS 7.0 или 7.5 сообщение будет выглядеть так же, как в следующем примере:
Причина
Это сообщение входит в журнал событий, когда пул приложений занимает больше времени, чем настроенное ShutdownTimeLimit свойство, чтобы закрыться. После превышения этого срока рабочий процесс будет принудительно закрыт и переработан. И сообщение журнала событий будет создано.
Возможно, это сообщение появится в журнале событий без негативного наблюдаемого поведения для конечных пользователей, просматривающих веб-сайты, которые будут отображаться в этом пуле приложений. Однако наличие события указывает на то, что одно из следующих условий верно:
Значение свойства конфигурации в IIS по умолчанию ShutdownTimeLimit составляет 90 секунд.
Чтобы устранить эту проблему, выберите один из следующих методов.
Разрешение 1. Увеличение значения ShutdownTimeLimit
Не исключено, что значение по умолчанию было изменено со значения по умолчанию ShutdownTimeLimit в 90 секунд. Пулу приложений необходимо время, чтобы полностью закрыться, так как все запросы, обрабатывающиеся в настоящее время при закрытии, должны быть предоставлены определенное время для завершения. Слишком низкое значение может привести к таким ошибочным предупреждениям журнала событий в веб-приложениях с высоким трафиком или в веб-приложениях с запросами, которые, как ожидается, будут завершены ShutdownTimeLimit некоторое время.
Чтобы изменить ShutdownTimeLimit значение IIS 7.0 и IIS 7.5, см. в Параметры process Model Параметры пула
Разрешение 2. Устранение неполадок, почему пул приложений не закрывается своевременно
Как уже упоминалось выше, возможно, что что-то происходит в пуле приложений. Поэтому его нельзя отключить своевременно. Одной из наиболее распространенных проблем является то, что существующие запросы по протоколу передачи HyperText (HTTP) не могут быть завершены. Чтобы устранить неполадки, из-за которых пул приложений закрывается слишком долго, запечатлеть свалку памяти процесса w3wp.exe, в котором работает пул приложений, когда возникает проблема остановки.
Дополнительные сведения о захвате демпингов памяти процессов IIS см. в дополнительных сведениях, доступных в средствах диагностики отлаговок v1.2.
IIS ApplicationPool не запускается должным образом без ошибок
Мы столкнулись со странной проблемой с нашими развертываниями IIS.
ApplicationPools иногда не запускается должным образом, но при этом не выдает ошибок. Единственный содержащий сайт в пуле приложений не отвечает (даже не возвращает 500 или что-то подобное, просто время ожидания истекает через некоторое время).
ApplicationPool и сайты запущены и работают (не остановлены), что касается IIS.
Перезапуск сайта или ApplicationPool не решает проблему.
Однако удаление сайта и ApplicationPool и воссоздание его с идентичными свойствами исправляет это.
Мы бы с радостью сделали это автоматически, но нет ошибок, которые нужно было бы вылавливать и обрабатывать соответственно.
Некоторые исходные данные:
Мы подозреваем, что проблема может заключаться в одновременном запуске нескольких ApplicationPool (поскольку они автоматически запускаются нашим конвейером CI / CD).
Я ни в коем случае не эксперт IIS, поэтому мои вопросы:
2 ответа
Решение
Мы реализовали это 2 дня назад, и с тех пор проблема не возникала в более чем 100 развертываниях.
Возможно ли, что запуск многих пулов приложений (около 20-60), происходящих примерно в одно и то же время, вызовет такое поведение?
Что я мог сделать, чтобы расследовать это дальше?
Если у вас неработающий пул приложений, запустите на своем сервере из PowerShell или ISE (от имени администратора) следующую команду, чтобы просмотреть запущенные рабочие процессы IIS:
(замените имя пула приложений на NAMEOFMYAPPPOOL и запустите от имени администратора)
Настройка IIS
Веб-сервер IIS, как среда выполнения веб-приложения, имеет некоторое влияние на общую производительность. Например, чем короче конвейер обработки запросов в IIS, тем меньше кода будет выполняться и тем выше будет скорость работы. В IIS имеются механизмы, которые можно использовать для увеличения производительности приложения за счет снижения задержек и увеличения пропускной способности, а также некоторые механизмы, которые при правильной настройке могут увеличить общую производительность приложения.
Кэширование вывода
Мы уже знаем, что ASP.NET поддерживает собственный механизм кеширования вывода, зачем же использовать еще один подобный механизм в IIS? Ответ на этот вопрос прост: помимо страниц ASP.NET существуют и другие виды содержимого, которое можно кешировать. Например, мы можем кешировать часто запрашиваемые статические файлы изображений или вывод собственных обработчиков HTTP-запросов. Для этой цели как раз и можно использовать механизм кеширования, поддерживаемый веб-сервером IIS.
В IIS имеется два механизма кеширования: кеш в пространстве пользователя и кеш в пространстве ядра.
Кеширование в пространстве пользователя
Так же как ASP.NET, веб-сервер IIS способен кешировать ответы в памяти, чтобы ответы на последующие запросы могли отправляться из кеша в памяти, без обращения к статическим файлам на диске и без вызова программного кода на стороне сервера.
Чтобы настроить кеширование, откройте приложение IIS Manager, выберите свое веб-приложение, откройте настройку Output Caching (Кеширование вывода), щелкните на ссылке Add (Добавить) в панели Actions (Действия), чтобы добавить новое правило кеширования, или выберите существующее правило для редактирования.
Чтобы создать новое правило кеширования в пространстве пользователя, добавьте новое правило, введите расширение имен файлов, которые требуется кешировать, и отметьте флажок User-mode caching (Кеширование в режиме пользователя) в диалоге Add Cache Rule (Добавить правило кеширования), как показано на рисунке ниже:
Отметив флажок, вы получите возможность выбирать, когда кешированный элемент будет удаляться из памяти, после обновления файла на диске или спустя некоторое время с момента кеширования. Для статических файлов больше подходит вариант удаления после обновления, тогда как определение интервала времени больше подходит для динамического содержимого. Щелкнув на кнопке Advanced (Дополнительно) можно получить доступ к настройкам, управляющим кешированием различных версий вывода (согласно параметрам в строке запроса или HTTP-заголовкам).
Кеширование в пространстве ядра
В отличие от механизма кеширования в пространстве пользователя, сохраняющего информацию в памяти рабочего процесса IIS, механизм кеширования в пространстве ядра сохраняет информацию в памяти драйвера HTTP.sys. Кеширование в пространстве ядра обеспечивает более короткое время отклика, однако оно поддерживается не всегда. Например, кеширование в пространстве ядра нельзя использовать, когда запрос содержит строку с параметрами запроса или когда запрос не является анонимным запросом.
Настройка правил кеширования в пространстве ядра выполняется почти так же, как кеширование в пространстве пользователя. В диалоге настройки правила установите флажок Kernel-mode caching (Кеширование в режиме ядра) и выберите желаемый способ кеширования.
В одном правиле допускается использовать оба режима кеширования, в пространстве ядра и в пространстве пользователя. В этом случае IIS будет сначала пытаться применить кеширование в пространстве ядра. Если попытка не увенчается успехом, например, когда запрос содержит строку с параметрами, применяется кеширование в пространстве пользователя.
Если выбран вариант кеширования на определенный интервал времени в обоих режима, в пространстве ядра и в пространстве пользователя, оба интервала должны совпадать, в противном случае в обоих режимах будет использоваться интервал, установленный для кеширования в режиме ядра.
Настройка пула приложения
Понимание значения некоторых из этих настроек может помочь вам настроить работу пула и тем самым более полно удовлетворить потребности приложения.
Перезапуск
Изменяя параметр настройки перезапуска можно управлять моментом, когда пул приложения будет перезапускать рабочий процесс. Например, можно организовать перезапуск рабочего процесса через каждые несколько часов или когда будет превышен некоторый предел занимаемой памяти. Если с течением времени веб-приложение начинает потреблять большие объемы памяти (например, для хранения объектов), увеличение количества перезапусков может помочь удерживать его производительность на высоком уровне. С другой стороны, если веб-приложение не проявляет никаких проблем в процессе работы, уменьшение количества перезапусков предотвратит потерю информации о состоянии.
Для проверки количества и частоты перезапусков пула приложения можно использовать счетчик производительности ASP.NET\Worker Process Restarts. Если вы увидите слишком большое количество перезапусков без явной на то причины, попробуйте сопоставить полученные значения с потреблением памяти приложением и нагрузкой на процессор, потому что перезапуски могут быть обусловлены превышением других пределов, определяемых настройками пула приложения.
Тайм-аут простоя
По умолчанию пул приложения прекращает работу через 20 минут простоя. Если такие перерывы в работе ожидаемы, например, когда все пользователи уходят на обед, попробуйте увеличить тайм-аут или даже вообще отменить его.
Привязка процессов к ядрам процессора
По умолчанию пул приложения настроен так, что может использовать все доступные ядра процессора. Если у вас имеется какой-либо специализированный фоновый процесс, использующий все процессорное время, какое ему будет выделено, можете настроить привязку пула к определенным ядрам, освободив остальные для фонового процесса. Разумеется, при этом также потребуется настроить привязку фонового процесса к другим ядрам процессора, чтобы избежать конкуренции между ним и рабочим процессом за одни и те же ядра.
Веб-сад
По умолчанию пул приложения запускает один рабочий процесс, обслуживающий все запросы, поступающие приложению. Если рабочему процессу приходится одновременно обрабатывать несколько запросов, конкурирующих за обладание одним и тем же ресурсом, это может привести к задержкам при подготовке ответов.
В настройках IIS пула приложения можно определить максимальное количество рабочих процессов, которое можно запустить для обслуживания запросов. Если установить этот параметр в значение больше 1 (значение по умолчанию), с ростом нагрузки на веб-приложение для него будут запускаться дополнительные рабочие процессы, вплоть до указанного максимума. Пул приложения, имеющий более одного процесса, называется «веб-садом» («Web Garden»). Каждый раз, когда устанавливается соединение с клиентом, оно связывается с рабочим процессом, который будет обслуживать запросы от этого клиента, при этом соблюдается равномерное распределение запросов от пользователей между процессами и уменьшаются накладные расходы на конкуренцию.
Имейте в виду, что использование веб-сада имеет и недостатки. Большее количество рабочих процессов занимает больший объем памяти, исключается возможность использовать механизм по умолчанию хранения информации о сеансе в памяти процесса, при выполнении нескольких рабочих на одном компьютере, между ними может возникать конкуренция за локальные ресурсы, например, за использование общего файла журнала.
Пулы приложений, не запускаемые после iisreset
прежде чем я начну, я знаю, что использование iisreset считается плохой практикой, но этого не должно произойти в любом случае..
что у нас есть:
несколько машин с IIS6 на Windows Server 2003 R2 (64 и 32 бита)
несколько веб-сервисов WCF (.NET runtime 2.0), развернутых в нескольких приложениях, каждый со своим собственным пулом приложений, каждый пул приложений работает под другой windows счет.
что будет:
5 ответов
пулы приложений должны перезапускаться в iisreset, но они работают вне iis (в COM+) для надежности. Это означает, что они могут не вернуться, если приложение плохо себя ведет, но IIS и другие приложения(должны) вернуться. Так что да, это «нормально».
С. П. Я также хотел бы «выйти» из себя как горда пользователь iisreset. Плохая практика? Бах!; D
IIS не запускается сразу ASP.NET рабочие процессы (w3wp.exe), пока не поступит первый запрос. Когда вы говорите «не запущен», означает ли это, что вы пытаетесь получить доступ к некоторым веб-службам WCF (после iisreset), и вы получаете ошибку недоступности службы, потому что appPool не может быть запущен? Вы видите какие-либо связанные записи IIS W3SVC в журналах событий?
Если есть, они могут подсказать вам, почему они не могут начать; разместите их здесь.
была аналогичная проблема-после перезапуска IIS DefaultAppPool был остановлен.
в журналах событий приложений обнаружена ошибка:
Windows не может войти, потому что ваш профиль не может быть загружен. Проверьте, что вы подключены к сети и что сеть правильно работает. Если эта проблема не устранена, обратитесь к сетевому администратору.
DETAIL-Доступ запрещен.
исправлено путем установки в DefaultAppPool Дополнительные Параметры опции Загрузить Профиль Пользователя to False.
надеюсь, что это может быть полезно.
IIS не запускается сразу ASP.NET рабочие процессы (w3wp.exe), пока не поступит первый запрос. Когда он говорит «не запущен», это означает, что попытка доступа к некоторым веб-службам WCF (после iisreset) не удалась из-за того, что объект занимал некоторое пространство в памяти, и вы получаете ошибку недоступности службы, потому что appPool не может быть запущен.
создайте пакетный файл со следующими командами и запланируйте его.
net stop PleskControlPanel
net stop HTTPFilter
команду iisreset /перезагрузка
сеть запустить службу w3svc
net start msftpsvc
net start PleskControlPanel
net Start HTTPFilter