Вопрос

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

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

Мы запустили профилировщик ANTS на сервере, но он не дал никаких результатов.

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

Это было полезно?

Решение

  1. Стандартные счетчики производительности Windows (ищите другую коррелированную деятельность, например, многие получают запросы, чрезмерную сеть или диск ввод/вывода и т. Д.); Вы можете прочитать их как из кода, так и из Perfmon (например, для запуска данных, если использование ЦП превышает порог)
  2. Пользовательские счетчики производительности (в частности, к временному времени для запросов без коробки и других вызовов, где время выполнения неясно)
  3. Нагрузочное тестирование, используя такие инструменты, как Team Team Team Visual Studio или WCAT
  4. Если вы можете тестировать или обновить до IIS 7, вы можете настроить сбой сбой запроса, чтобы создать трассировку, если запросы занимают более определенное количество времени
  5. Используйте Logparser, чтобы увидеть, какие запросы поступили во время Spike ЦП
  6. Обзоры кода / прохождения (в частности, ищите петли, которые могут не заканчиваться должным образом, например, если возникает ошибка, а также блокировки и потенциальные проблемы с потоком, такие как использование статики)
  7. Профилирование процессора и памяти (может быть затруднено в производственной системе)
  8. Процесс -исследователь
  9. Windows Resource Monitor
  10. Подробный журнал ошибок
  11. Пользовательский регистр трассировки, включая детали времени выполнения (возможно, условное, основываясь на счетчике PERF USERE-USER)
  12. Происходят ли ошибки при переработке Apppool? Если это так, это может быть подсказкой.

Другие советы

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

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

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

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

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

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

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

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

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

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

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

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

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

Если вы идентифицируете страницу, которая требует времени для загрузки, используйте SharePoint Developer Dashboard Чтобы увидеть, какой компонент требует времени.

Лицензировано под: CC-BY-SA с атрибуция
Не связан с StackOverflow
scroll top