Что происходит с другими пользователями, если происходит сбой рабочего процесса .NET? - PullRequest
6 голосов
/ 26 марта 2010

Мои знания о том, как процессы обрабатываются рабочим процессом ASP.Net, крайне неадекватны. Я надеюсь, что некоторые из экспертов могут заполнить меня.

Если я произвожу крах рабочего процесса с исключением System.OutOfMemoryException, что будет для других пользователей, обслуживаемых тем же процессом? Получат ли они пустой экран? Ошибка 503?

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

ОБНОВЛЕНИЕ : Наши результаты варьировались. Если бы мы искусственно вызвали исключение OOM (например, загрузив все большие и большие PDF-файлы в память), другие потоки, обслуживаемые этим рабочим процессом, временно «зависали» и затем завершались, тогда как другие, по-видимому, никогда не возвращались. Спасибо за ваши ответы.

Ответы [ 4 ]

9 голосов
/ 26 марта 2010

W3WP.exe это процесс

IIS запускает все веб-приложения в общем рабочем процессе - w3wp.exe. Независимо от того, пишете ли вы в ASP.NET, или ISAPI, или в какой-то другой среде, процесс, который обслуживает веб-запрос, называется w3wp.exe. В случае ASP.NET w3wp.exe загружает скомпилированные JIT-библиотеки ASP.NET и обслуживает запросы через них. В других случаях это работает по-другому. Но ключевой момент заключается в том, что w3wp.exe - это процесс. Эта модель началась в IIS6.0 и продолжается в IIS7.0.

Неожиданные сбои

Если W3WP.exe неожиданно завершится сбоем, по какой-либо причине все транзакции, которые он обрабатывал, вероятно, получат 500 ошибок (ошибка сервера). Вместо этого IIS запустит новый рабочий процесс ( MS называет это «Мониторинг работоспособности» ), что означает, что веб-приложение будет продолжать работать. Пользователи, у которых не было запроса, обслуживаемого сбойным процессом во время сбоя, не будут знать об этом.

Ошибка HTTP 500, которую клиент получает в этом случае, будет неотличима от ошибки 500, которую клиент получает в случае ошибки приложения, скажем, неперехваченного исключения в коде приложения ASPNET.

Для тех запросов, которые были в процессе сбоя, нет способа их восстановить. Они приведут к 500 ошибкам в браузере. 503 Server Busy является результатом того, что IIS активно отказывает в соединении из-за порогового значения числа соединений. 503 не является результатом сбоя приложения, поэтому вы не должны ожидать появления 503 для транзакций в полете в сценарии с нехваткой памяти и сбоем. В сильно загруженной системе вы можете увидеть 503-е, когда происходит сбой-и-перезапуск процесса, как вторичный эффект. Если это действительно то, что вы видите, вам нужен больший запас прочности для обработки нагрузки в условиях единичной ошибки.

Очередь запросов

В IIS есть подход к передаче запросов . Когда они поступают на сетевой уровень (Http.sys), они помещаются в очередь для обработки рабочим процессом. Любые запросы, ожидающие обработки в очереди IIS WP, останутся без изменений, хотя они могут увидеть небольшое временное увеличение задержки (времени обслуживания) из-за конфликта ресурсов, так как на сервере выполняется меньше процессов. Время ожидания в этой очереди, как правило, очень и очень мало в системе, которая настроена правильно.

Когда эта очередь заполнится, вы увидите 503 ошибки.

Автоматический перезапуск W3WP.exe

IIS имеет функцию автозапуска (или «няни»), с помощью которой перезапускает рабочие процессы после того, как они превысили настроенные пороги , такие как объем памяти, количество запросов или время Бег. Во всех этих случаях IIS будет приостанавливать и перезапускать рабочие процессы при достижении настроенного порога. Эти активные перезапуски обычно не приводят к прерыванию запросов. Когда IIS решает, что перезапуск рабочего процесса необходим, он предотвращает поступление любых новых запросов на этот ожидаемый WP. Существующие запросы истощаются : любые транзакции в полете в этом WP разрешены для нормального завершения. Когда все запросы в WP завершены, тогда WP умирает, и IIS запускает новый вместо него. Этот новый процесс сразу же начинает собирать новые запросы из очереди отправки. Это все прозрачно для пользователей или браузеров.

Я говорю обычно , потому что вполне возможно, что рабочий процесс действительно заболел одновременно с достижением порога. В этом случае w3wp.exe может не отвечать на IIS в течение настроенного тайм-аута "quiesce" , и поэтому IIS должен в конечном итоге завершить процесс, даже если он не сообщил, что все его запросы в полете завершено. Это должно быть чрезвычайно редко, потому что это два разных исключительных условия, но это случается. В этом случае запросы в полете снова получат 500 ошибок.

Веб-сады

Также - IIS допускает несколько рабочих процессов на одном сервере. MS называет это «веб-садом» , игрой слов «веб-фермы». Если у вас настроен веб-сад, то транзакции, обслуживаемые экземплярами w3wp.exe, отличными от сбойного, останутся без изменений. Однако «незатронутый» предполагает, что ошибка нехватки памяти локализована, а не общесистемная проблема.

Итог

Суть в том, что ничто не заменит ваше собственное тестирование. Параметры конфигурации довольно широки - от порогов перезапуска до веб-садов и так далее. Кроме того, режимы сбоев имеют тенденцию быть довольно сложными и разнообразными, будь то память, время ожидания, слишком занят и т. Д. Вы хотите понять, чего ожидать.

ps: этот Q & A действительно принадлежит на serverfault.com !!


ссылки:
http://blogs.iis.net/thomad/archive/2008/05/07/the-iis-process-model-features.aspx

0 голосов
/ 26 марта 2010

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

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

0 голосов
/ 26 марта 2010

Если это нехватка памяти, iis обычно просто перезагружает пул приложений.

0 голосов
/ 26 марта 2010

Будет запущен новый рабочий поток, и пользователь не узнает, что случилось. Если он не отключится полностью из-за быстрого отказа (http://technet.microsoft.com/en-us/library/cc779127(WS.10).aspx)

...