W3WP.EXE с использованием 100% CPU - с чего начать?

Ответ 1

• Стандартные счетчики производительности Windows (ищите другую коррелированную активность, например, многие запросы GET, чрезмерную сетевую или дисковый ввод-вывод и т.д.); вы можете прочитать их как из кода, так и из perfmon (для запуска сбора данных, если использование ЦП превышает пороговое значение, например)
• Пользовательские счетчики производительности (в частности, время для запросов на "вне коробки" и другие вызовы, где время выполнения не определено)
• Загрузка тестирования с использованием таких инструментов, как Visual Studio Team Test или WCAT
• Если вы можете протестировать или обновить IIS 7, вы можете настроить Failed Request Tracing для генерации трассировки, если запросы занимают больше определенного времени.
• Используйте logparser, чтобы узнать, какие запросы были получены во время всплеска CPU.
• Кодовые обзоры/проходы (в частности, найдите циклы, которые могут не завершиться должным образом, например, если произошла ошибка, а также блокировки и потенциальные проблемы с потоками, такие как использование статики).
• Профилирование CPU и памяти (может быть затруднено в производственной системе)
• Проводник процессов
• Монитор ресурсов Windows
• Подробное ведение журнала ошибок
• Пользовательский журнал трассировки, включая данные о времени выполнения (возможно, условно, на основе счетчика производительности процессора)
• Ошибки происходят, когда AppPool перерабатывается? Если это так, это может быть ключом.

Ответ 2

Это не большая часть ответа, но вам может потребоваться старая школа и захватить снимок образа процесса IIS и отладить его. Вы также можете проверить блог Тесс Феррандес - она ​​является пинком инженера эскалации Microsoft, а ее блог сосредоточен на отладке окон ASP.NET, но блог относится к отладке Windows в целом. Если вы выберете тег ASP.NET(с которым я связан), вы увидите несколько похожих элементов.

Ответ 3

Если ваш процессор достигает 100% и остается там, вполне вероятно, что у вас либо есть сценарий взаимоблокировки, либо бесконечный цикл. Профилировщик кажется хорошим выбором для поиска бесконечного цикла. Однако тупики гораздо труднее отследить.

Ответ 4

Process Explorer - отличный инструмент для устранения неполадок. Вы можете попробовать найти проблему высокого уровня CPU. Это дает вам представление о том, как работает ваше приложение.

Вы также можете попробовать Procdump, чтобы свалить процесс и проанализировать, что на самом деле произошло на процессоре.

Ответ 5

Кроме того, посмотрите на свои счетчики перфонов. Они могут рассказать вам, где потрачено много времени на процессор. Здесь ссылка на наиболее распространенные счетчики для использования:

• http://www.microsoft.com/technet/prodtechnol/WindowsServer2003/Library/IIS/852720c8-7589-49c3-a9d1-73fdfc9126f0.mspx?mfr=true
• http://www.microsoft.com/technet/prodtechnol/WindowsServer2003/Library/IIS/be425785-c1a4-432c-837c-a03345f3885e.mspx?mfr=true

Ответ 6

У нас это было на рекурсивном запросе, который выгружал тонны данных на выходе - вы дважды проверили, что все выходит, и не существует бесконечных циклов?

Можете попытаться сузить его с помощью одной страницы - мы обнаружили, что ANTS не будет очень полезной в том же случае - то, что мы закончили, - это запуск сайта, который попал на страницу, наблюдая за процессором - на следующей странице смотрите CPU - очень методично и трудоемко, но если вы не найдете его с некоторой трассировкой кода, вам может быть не повезло -

Мы смогли использовать файлы журнала IIS для отслеживания его на несколько подозрительных страниц -

Надеюсь, что это поможет!

Ответ 7

Это предположение в лучшем случае, но, возможно, ваша команда разработчиков создает и развертывает приложение в режиме отладки вместо режима выпуска. Это вызовет появление файлов .pdb. Следствием этого является то, что ваше приложение будет использовать дополнительные ресурсы для сбора состояния системы и отладки информации во время выполнения вашей системы, что приведет к большему использованию процессора.

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

Ответ 8

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

• Просто нажмите на свой сервер в левой панели IIS.
• Нажмите "Рабочие процессы" в главной панели. вы уже видите, какой пул приложений занимает слишком много CPU.
• Дважды щелкните по этой строке (в конечном итоге обновите, нажав "Показать все" ), чтобы увидеть, на каких страницах потребляется слишком много процессорного времени ( "Время, прошедшее" ) столбец) в этом пуле

Ответ 9

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