Назад | Перейти на главную страницу

Win2k8R2 / IIS 7.5 - пользователи получают ответ 503, в журналах не сообщается об ошибке 503

У меня есть 2 веб-сервера с зеркальным контентом. Перед ними стоит балансировщик нагрузки.

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

Они указали на несколько ошибок в журнале событий приложений Windows, которые выглядят следующим образом:

Log Name:      Application
Source:        ASP.NET 4.0.30319.0
Date:          3/31/2012 8:35:37 PM
Event ID:      1309
Task Category: Web Event
Level:         Warning
Keywords:      Classic
User:          N/A
Computer:      6251.local
Description:
Event code: 3005 
Event message: An unhandled exception has occurred. 
Event time: 3/31/2012 8:35:37 PM 
Event time (UTC): 4/1/2012 1:35:37 AM 
Event ID: e7a580c7b38545cca3416a8595408f24 
Event sequence: 97 
Event occurrence: 1 
Event detail code: 0 

Application information: 
    Application domain: /LM/W3SVC/2/ROOT-1-129777167518960645 
    Trust level: Full 
    Application Virtual Path: / 
    Application Path: C:\inetpub\wwwroot\mywebsite\ 
    Machine name: 6252 

Process information: 
    Process ID: 20000 
    Process name: w3wp.exe 
    Account name: IIS APPPOOL\MyAppPool

В частности, они говорят, что имя учетной записи в разделе «Информация о процессе» указывает на то, что пул приложений перерабатывается. Они сказали, что если бы пул приложений не был переработан, имя учетной записи вместо этого было бы папкой, в которой расположены файлы веб-сайта.

Я проверил настройки пула приложений - он перезаряжается каждые 29 часов. А для быстрой защиты от сбоев по умолчанию установлено 5 сбоев за 5 минут. Но я не видел 5 отказов в журнале событий за такой короткий промежуток времени.

Может ли кто-нибудь помочь мне подтвердить, действительно ли 503 ответа генерируются переработкой пулов приложений? Или эти ошибки откуда-то еще? Я предполагал, что в то время их балансировщик нагрузки действительно возвращал ошибку 503. Но это было всего лишь предположением.

Вы упомянули «файл журнала IIS» (в единственном числе), но есть всегда два журналы, которые вам нужно оценить:

  • W3SVCnn журналы (C: \ Inetpub \ Logs) из рабочего процесса веб-сайта и
  • HTTPERR журналы (C: \ Windows \ System32 \ Logfiles \ HTTPERR) из HTTP.SYS, который направляет запросы рабочим процессам и предоставляет очередь режима ядра, предназначенную для буферизации клиентов от изменений рабочего процесса (например, повторное использование)

Ошибки 503 с гораздо большей вероятностью появятся в журналах HTTPERR вместе с причиной сбоя, потому что они с большей вероятностью отражают отказ HTTP.SYS для связи с рабочим процессом (или переполнение очереди, что равносильно аналогичной вещи. ).

Смотрите также http://support.microsoft.com/kb/820729 - не уверен, почему есть «Исправить», когда в статье описывается, что делает журнал и (внизу) причины, по которым он может регистрироваться для сбоя.

Еще немного

В большинстве платформ приложений есть две очереди: очередь запросов HTTP.SYS (в режиме ядра) и очередь запросов пользовательского режима. Если инфраструктура пользовательского режима (например, ASP.Net) ставит запросы в очередь внутри, то сбой рабочего процесса приведет к 503 (или, в лучшем случае, 500) для всех запросов, поставленных в очередь внутри него, в результате чего HTTP.SYS будет рассматривать эти запросы. как заброшенные и не подлежащие спасению.

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

Спасибо tristanK за ваш ответ. я не знал о журналах httperr.

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