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

An ASP.NET веб-приложение, работающее на IIS6, периодически снимает процессор до 100%. Это W3WP, который отвечает за почти все использование ЦП во время этих эпизодов. Процессор остается закрепленным на 100% в любом месте от нескольких минут до более чем часа.

Это на промежуточном сервере, и на данный момент сайт получает очень легкий трафик от тестировщиков.

мы запустили профилировщик муравьев на сервере, но он был непрозрачным.

с чего мы можем начать выяснение того, что вызывает эти эпизоды и какой код держит процессор занят в течение всего этого времени?

50
asp.net profiling red-gate-ants w3wp

9 ответов

  1. стандартные счетчики производительности Windows (ищите другие коррелированные действия, такие как многие запросы GET, чрезмерный сетевой или дисковый ввод-вывод и т. д.); Вы можете читать их из кода, а также из perfmon (например, для запуска сбора данных, если использование ЦП превышает порог)
  2. пользовательские счетчики производительности (в частности, время для автономных запросов и других вызовов, где время выполнения неопределенно)
  3. нагрузочное тестирование с помощью таких средств, как Visual Studio Team Test или Wcat все
  4. если можно протестировать или обновить IIS 7, можно настроить трассировку неудачных запросов для создания трассировки, если запросы занимают больше определенного времени
  5. используйте logparser, чтобы увидеть, какие запросы поступили во время всплеска процессора
  6. обзоры кода / пошаговые инструкции (в частности, ищите циклы, которые могут завершиться неправильно, например, если произойдет ошибка, а также блокировки и потенциальные проблемы с потоками, такие как использование статики)
  7. CPU и профилирование памяти (может быть затруднено в производственной системе)
  8. Процесс Explorer
  9. Монитор Ресурсов Windows
  10. подробный журнал ошибок
  11. пользовательский журнал трассировки, включая сведения о времени выполнения (возможно, условный, основанный на счетчике perf CPU-use)
  12. происходят ли ошибки, когда AppPool рециркулирует? Если так, это может быть подсказкой.
34

Это не большой ответ, но вам может потребоваться пойти старой школы и захватить снимок образа процесса IIS и отладить его. Вы также можете проверить Тесс Ferrandezблог-она удар * * инженер эскалации microsoft и ее блог фокусируется на отладке windows ASP.NET, но блог имеет отношение к отладке windows в целом. Если выбрать ASP.NET тег (с которым я связан), тогда вы увидите несколько похожих элементов.

11

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

4

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

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

4

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

1

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

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

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

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

0

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

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

0

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

  1. просто нажмите на свой сервер в левой панели IIS.
  2. нажмите на "Рабочие процессы"в главной панели. вы уже видите, что пул приложений занимает слишком много ЦП.
  3. дважды щелкните по этой строке (в конечном итоге обновите, нажав "показать все"), чтобы увидеть, какие страницы потребляют слишком много времени процессора ("время прошло" столбец) в этом пуле
-1

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

-2