Периодически запросы IIS7 застревают в модуле WindowsAuthenticationModule.
У нас работает сервер IIS7, на котором размещены несколько десятков веб-сайтов. Некоторые из этих веб-сайтов являются частью одного и того же унаследованного приложения, которое мы разработали. Все эти сайты запускают один и тот же код и работают в одном пуле приложений.
Примерно раз в месяц в течение последних нескольких месяцев мы обнаружили, что все запросы на этот пул приложений начинают зависать бесконечно. Когда это происходит, мы получаем предупреждение и перерабатываем пул приложений. После этого сайты снова начинают работать.
Это влияет только на один пул приложений, но никак не на другие на одном сервере. Пару раз, прежде чем перерабатывать пул, я смотрел на текущие запросы в рабочем процессе. Все они отображаются как выполняющиеся внутри модуля WindowsAuthenticationModule. Что странно, потому что подавляющее большинство приложений не требует аутентификации. Существует небольшой раздел администратора, который использует аутентификацию Windows... но все остальные запросы должны быть анонимными.
Кто-нибудь знает, что может быть причиной этого?
Есть несколько необычных вещей о том, как эти сайты создаются. Как я уже говорил, все они выполняют один и тот же код - несколько сайтов указывают на один и тот же физический каталог. Единственная разница - привязки заголовка хоста. Я не уверен, почему не существует только одного сайта со всеми заголовками хоста, но так оно и работает.
На некоторых из этих сайтов один и тот же физический каталог отображается на двух уровнях - в качестве корня сайта и снова в качестве приложения на сайте. Поэтому, если пользователь заходит на http://oursite.com/index.aspx, он отображается в c:\files\oursite\index.aspx. Если пользователь заходит на http://oursite.com/foo/index.aspx, он также отображается в c:\files\oursite\index.aspx. Я думаю, что есть код, который смотрит на URL запроса и обрабатывает два запроса по-разному.
Это странно, потому что тот же файл web.config в конечном итоге интерпретируется как файл конфигурации сайта, а также как файл конфигурации приложения на сайте. Я не знаю, может ли это быть связано с проблемой аутентификации.
Если мы не можем найти причину, мы думаем о нескольких обходных путях, которые мы могли бы попробовать:
Переместите раздел администратора на отдельный сайт и дайте клиенту новый URL администратора. Запустите этот отдельный сайт в своем пуле приложений. Затем в файле web.config, доступном для всех других сайтов, удалите модуль WindowsAuthenticationModule. Таким образом, не должно быть возможности зависания в модуле WindowsAuthenticationModule.
Попробуйте запустить все эти сайты в классическом конвейере вместо интегрированного конвейера. Они хорошо работали на нашем старом сервере IIS6...
(Если мы впадаем в отчаяние) Настройте сторожевой скрипт, который отслеживает сайты и автоматически перезапускает пул приложений, когда он обнаруживает, что запросы застревают.
Как вы думаете?
Спасибо за вашу помощь,
Ричард
1 ответ
Я бы попытался щелкнуть правой кнопкой мыши по процессу w3wp.exe, выполняющемуся в вашем пуле приложений. Щелкните правой кнопкой мыши и выберите, создать файл дампа.
Или:
- Откройте файл дампа в Visual Studio 2010
- Под опциями> отладка (или аналогичная) вы можете добавить серверы символов. Добавить http://msdl.microsoft.com/download/symbols
- Дважды щелкните местоположение зависания и щелкните правой кнопкой мыши на трассировке стека и выберите, чтобы загрузить код / символы.
- Прочитайте код и посмотрите, почему он завис
ИЛИ ЖЕ:
- Следуйте этой статье, чтобы установить WinDbg
- Сделай то, что она делает, и посмотри, сможешь ли ты найти проблему
Активируйте протоколирование с помощью netsh, чтобы видеть запросы токенов Kerberos по мере их появления (я не пробовал этот IRL):
PS C:\> netsh trace show providers | select-string kerberos
PS C:\> netsh trace show providers | select-string auth
... а потом что-то вроде:
netsh trace start provider={5BBB6C18-AA45-49B1-A15F-085F7ED0AA90}
ИЛИ ЖЕ:
- Наймите консультанта.:)