Веб-приложение ASP.NET, работающее на IIS6, периодически загружает процессор до 100%. Именно W3WP отвечает почти за все использование ЦП во время этих эпизодов. ЦП остается на 100% от нескольких минут до более часа.
Это находится на промежуточном сервере, и на данный момент сайт получает очень мало трафика от тестировщиков.
Мы запустили профилировщик ANTS на сервере, но это ничего не дает.
Где мы можем начать выяснять, что вызывает эти эпизоды и какой код загружает процессор все это время?
Это не лучший ответ, но вам, возможно, придется пойти по старой школе и сделать снимок образа процесса IIS и отладить его. Возможно, вы также захотите проверить Тесс Феррандес блог - она отличный ** инженер по эскалации Microsoft, и ее блог посвящен отладке Windows ASP.NET, но блог имеет отношение к отладке Windows в целом. Если вы выберете тег ASP.NET (с которым я связался), вы увидите несколько похожих элементов.
Если ваш процессор достигает 100% и остается там, вполне вероятно, что у вас либо сценарий тупика, либо бесконечный цикл. Профилировщик кажется хорошим выбором для поиска бесконечного цикла. Однако тупиковые ситуации отследить гораздо сложнее.
Process Explorer - отличный инструмент для устранения неполадок. Вы можете попробовать его, чтобы найти проблему высокой загрузки CPU. Это дает вам представление о том, как работает ваше приложение.
Вы также можете попробовать Procdump, чтобы создать дамп процесса и проанализировать, что на самом деле произошло. на CPU.
Также посмотрите на свои счетчики perfmon. Они могут сказать вам, на что тратится много времени процессора. Вот ссылка на наиболее часто используемые счетчики:
У нас было это в рекурсивном запросе, который сбрасывал тонны данных на выход - вы дважды проверили, все ли завершается и не существует бесконечных циклов?
Можно попытаться сузить его до одной страницы - мы обнаружили, что ANTS тоже не очень помогает в том же случае - в итоге мы запустили сайт, переходили на страницу, наблюдая за процессором - переходили на следующую страницу, наблюдали за процессором - очень методично и отнимает много времени, но если вы не можете найти его с помощью трассировки кода, вам может не повезти -
Мы смогли использовать файлы журнала IIS, чтобы отследить его до ряда подозрительных страниц -
Надеюсь, это поможет !
В лучшем случае это предположение, но, возможно, ваша группа разработчиков создает и развертывает приложение в режиме отладки, а не в режиме выпуска. Это вызовет появление файлов .pdb. Следствием этого является то, что ваше приложение будет занимать дополнительные ресурсы для сбора информации о состоянии системы и отладочной информации во время выполнения вашей системы, что приведет к большей загрузке процессора.
Таким образом, было бы достаточно просто убедиться, что они строятся и развертываются в режиме выпуска.
Я знаю, что это очень старый пост, но это тоже распространенная проблема. Все предлагаемые методы очень хороши, но они всегда будут указывать на процесс, и есть много шансов, что мы уже знаем, что наш сайт создает проблемы, но мы просто хотим знать, какая конкретная страница тратит слишком много времени на обработку. На мой взгляд, самый точный и простой инструмент - это сам IIS.
Если вы определили страницу, для которой требуется время для загрузки, используйте SharePoint Панель инструментов разработчика, чтобы узнать, какой компонент требует времени.
