w3wp иногда зависает на ночных утилитах

Question

Я столкнулся с проблемой с нашим приложением ASP.NET, из-за которой иногда из-за ночного перезапуска w3wp зависает.

Вот что происходит:

Recycle запущен. очевидно, это вызывает исключение ThreadAbortException во всех запущенных потоках. Однако он, похоже, не запускает новый w3wp, или это новый w3wp, который на самом деле выдает исключение (пока не смог его воспроизвести).

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

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

Мы используем Monorail MVC, который, вероятно, не имеет к этому никакого отношения, однако мы используем их систему RescueController. Если мы хотим непреднамеренно перехватить исключение ThreadAbortException при обработке ошибок, может ли это привести к бесконечному циклу, который так сильно повредит w3wp, что IIS не сможет восстановить его?

Answer 1

IIS не может запустить новый рабочий процесс успешно из-за ограниченности ресурсов, вероятно, из-за нехватки свободной памяти.

Попытайтесь отрегулировать свой предел частной памяти в IIS, уменьшив число Максимальных рабочих процессов, иначе говоря, Web Garden (редко устанавливайте его больше 1 - если он установлен выше, чем, вероятно, основная проблема, которую нужно решить), увеличивая физическая оперативная память доступна на ваших серверах, соответственно вызывая Marshal.ReleaseComObject и в противном случае разбираясь с тем, что мешает освобождению памяти. Вы можете даже подумать об изменении режима сбора мусора с сервера на рабочую станцию ​​(см. http://msdn.microsoft.com/en-us/library/ms229357.aspx).

Answer 2

Оказывается, у нас был рекурсивный цикл try catch для Exception, который перехватывает ThreadAbortException и вызывает себя из-за наследования, поэтому он стал бесконечной рекурсией.

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