Возможно ли, что исключение в приложении aspx одного пула приложений может вызвать проблемы и для других пулов приложений?
У меня возникли проблемы с IIS v7.5, когда весь IIS перестал отвечать после какой-то ошибки приложения, а все HTTP-запросы истекли. Однако файлы журнала не содержат много информации о такой проблеме во время простоя.
Если да, то при каких обстоятельствах это может произойти?
Не обычно, но это зависит от причины исключений и от того, находится ли основная причина в (или нарушает) общий ресурс.
В типичном мире веб-сайтов по умолчанию без совместного использования ресурсов каждый W3WP имеет собственное пространство памяти, таблицу дескрипторов и связанные ресурсы, которые уникальны для процесса. Один падает, всем плевать. (В сторону: на самом деле, если это действительно веб-сайт по умолчанию, то есть только статический контент, сбой будет потрясающе странный и хороший показатель того, что что-то действительно неправильно происходит на коробке).
Если веб-приложение решает использовать ресурсы (например, таблицу базы данных или файл где-то на диске), а несколько веб-приложений используют один и тот же ресурс, то проблема в одном может косвенно привести к проблеме в других.
Например: это очень дорого SQL-запрос, который вы запустили в процессе A, из которого вы не поймали исключение тайм-аута, по-прежнему связывает тот же плохой сервер базы данных, который используется процессами B C и D, которые тоже собираются на тайм-аут ...
Или, если веб-приложение выполняет HTTP-вызовы в другой пул приложений в том же самом поле, тогда да, это явная зависимость и явный случай возникновения проблемы!
Но обычно, когда все идет не так сразу, если вы запускаете более одного веб-приложения, они вряд ли являются причиной ... скорее всего, причина в другом программном обеспечении, в 90% случаев с компонентом режима ядра, работающим на коробке.
Ключевые примеры: Материал, который полагается на общие ресурсы SMB (то есть содержимое на \ server \ share), особенно когда целью является эмулятор SMB, отличный от Windows (поэтому он несовместим с ошибками) или используется другой интересный драйвер фильтра ввода-вывода ... который аккуратно подводит нас к антивирусным и фильтрующим драйверам такого рода ... Драйверы K-режима получают доступ к файлам, перенаправляют запрос через процесс u-режима, который становится занятым или пересекается, вызывая задержку ввода-вывода в k-режиме, вызывая бесконечные весело). (Достойное упоминание о трудностях аутентификации, вызванных сбоями инфраструктуры аутентификации).
Тем не менее, это всего лишь догадки без каких-либо данных, поэтому лучший первый шаг - получить дамп памяти (DebugDiag или диспетчер задач), скормить их DebugDiag или дружественной шутке с поддержкой Windbg и заставить их попытаться определить, есть ли причина задержки в пользовательском режиме.
Если нет, то вы переходите к поиску и устранению неисправностей в k-режиме, и все становится немного запутаннее (чаще всего, синий экран экрана, чтобы получить аварийный дамп k-режима, пока что-то странное).