Рабочий процесс достиг своего разрешенного времени обработки

Question

Эта проблема возникает примерно раз в месяц. Это очень трудно определить причину, поэтому любая помощь будет оценена. Это приводит к остановке пула приложений и отключению сайта. Мы просмотрели все файлы журнала и ничего не сделали. Мы используем версию 2.0.3 на IIS 6.

Answer 1

Я заметил, что IIS использует веб-приложения по умолчанию с 29-часовым графиком перезарядки, что может быть хлопотно, так как оно может перерабатываться в тех случаях, когда пользователи этого не ожидают.

Например: веб-приложение запускается в 12 часов утра, что означает, что на следующий день оно перезапускается в 5 часов утра, на следующий день после этого - в 10 часов утра, на следующий день - в 3 часа дня и т. Д. приложение, чтобы оно оставалось в живых, чтобы оно не отключалось из-за неактивности)

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

Проверьте расписание перезарядки и убедитесь, что оно перерабатывается в то время, которое вы ожидаете. Смотрите это для скриншотов: http://remy.supertext.ch/2010/08/iis7-worker-process-reached-its-allowed-processing-time-limit/

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

Answer 2

Это, вероятно, указывает на бесконечный цикл в коде вашего приложения.

Обычно каждый раз, когда запрос поступает на веб-сервер, IIS передает запрос рабочему процессу. Вы можете настроить в IIS, сколько таких работников и какое значение времени ожидания. Тайм-аут заключается в том, что все должно двигаться, если код приложения зависает - он уничтожается, поэтому поток может вернуться в пул для обслуживания новых запросов.

Так что просмотрите свой код на наличие вероятных бесконечных циклов. Или, в качестве альтернативы, это может быть чрезвычайно длительный запрос к базе данных, который в конечном итоге мог завершиться, но превысил значение тайм-аута. Возможно, ваше веб-приложение предлагает конечному пользователю возможность сделать слишком широкий запрос, который возвращает слишком много данных или требует слишком много времени на обработку БД.

Трудно, конечно, привести конкретную причину для вас, но постарайтесь мыслить в этом направлении.

Answer 3

Если в результате происходит сбой (звучит так, как вы), то вы можете взять копию Средства отладки для Windows и потратить некоторое время на чтение Тесс Феррандез 'блог - она ​​предлагает отличный совет по выполнению анализа после аварии и делает WinDbg намного более доступным.