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

Пул приложений IIS6: приложение не работает, пока не будет переработано

У меня возникла проблема с веб-сайтом, который использует ASP.net MVC или Webform.

Проблема: иногда веб-сайт не отображается. Если я перейду на веб-сайт, я получу, что просмотр каталогов не разрешен или что-то подобное.

Быстрое исправление: войдите на сервер и перезапустите пул приложений в приложении, связанном с веб-сайтом.

Сервер: Win2k3 Standard R2, IIS6, 4 ГБ ОЗУ, двухъядерный AMD. использовал его для некоторого общего хостинга. не так много активных веб-сайтов и посещаемость довольно низкая.

Я не совсем понимаю, почему веб-сайт просто не работает, и мне нужно переработать пул приложений. Я создал пул приложений с именем ASPNET4 для любого веб-сайта, использующего .Net 4, и ASPNET2 для платформы .Net 4 ниже. Кто-нибудь знает, в чем проблема и как я могу ее исправить, вместо того, чтобы проверять веб-сайт, чтобы узнать.

Редактировать: Я должен дополнительно объяснить, что этот сервер используется для общего хостинга, и я использую панель управления Helm3, которая создает ASPNET2 для .Net 3 и ниже веб-сайта и ASPNET4, который я создал для поддержки .Net4, и вручную связывает веб-сайт с этим пулом.

Если все веб-сайты не используют один и тот же код, создайте один пул приложений для каждого веб-сайта и поместите каждый веб-сайт в собственный пул приложений.

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

При переработке вы завершаете старый рабочий процесс (W3WP.EXE) и заменяете его новым. Поэтому потом это работает.

Что касается того, почему он ломается - вам нужно будет проверить веб-сайт, чтобы узнать. По моему опыту, W3WP обычно так не ломаются; это как-то связано с приложениями или модулями на вашем веб-сайте (или их взаимодействием с компонентами системного уровня, такими как AV).

В следующий раз получите дамп памяти процесса перед его повторным использованием (перейдите к DebugDiag 1.2) и посмотрите, сможете ли вы почерпнуть из него какую-либо полезную информацию. В качестве альтернативы обратитесь к разработчику и / или в службу поддержки Microsoft, чтобы помочь изучить дамп и попытаться установить первопричину.