Поделиться через

Устранение неполадок с высоким ЦП в пуле приложений IIS 7.x

Джим Чешир

Средства, используемые в этом средстве устранения неполадок:

  • Отладка диагностики 1.2
  • Системный монитор

Этот материал предоставляется только в информационных целях. Корпорация Майкрософт не предоставляет никаких гарантий, явных или подразумеваемых.

Обзор

Это средство устранения неполадок поможет определить причину устойчивого высокой загрузки ЦП в пуле приложений IIS. Важно помнить, что использование ЦП обычно увеличивается, так как веб-приложение обслуживает запросы. Однако если вы постоянно видите, что ЦП остается на высоком уровне (в области 80 % или выше) в течение длительного периода, производительность приложения будет страдать. По этой причине важно понять причину устойчивого высокой загрузки ЦП, чтобы ее можно было устранить и исправить, если это возможно.

Сценарий

В пуле приложений в IIS наблюдается длительный период высокой загрузки ЦП, превышающий 90 %. При тестировании приложения проблемы не возникают. Тем не менее, как только приложение испытывает фактическую нагрузку пользователя, ЦП поднимается на высокий процент и остается. Для восстановления пул приложений необходимо перезапустить, но после этого ЦП снова поднимается на высокий уровень.

Сбор данных

Первое, что необходимо сделать при обнаружении высокой загрузки ЦП, — определить процесс, который потребляет ЦП. Для этого можно использовать вкладку "Процессы" в диспетчере задач. Убедитесь, что установлен флажок "Показать процессы" для всех пользователей . На рис. 1 показан этот флажок и показан процесс w3wp.exe (процесс, в котором размещается пул приложений IIS), который потребляет высокий уровень ЦП.

Снимок экрана: диспетчер задач Windows. В столбце C P U выделено значение 85 в строке исполняемого файла w 3 w p. Выбрано отображение процессов от всех пользователей.

Рис. 1. Диспетчер задач с высокой загрузкой ЦП.

Вы также можете использовать Монитор производительности, чтобы определить, какой процесс использует ЦП. Дополнительные сведения об использовании Монитор производительности см. в разделе "Анализ данных о производительности" далее в этом средстве устранения неполадок.

Совет

Если необходимо определить, какой пул приложений связан с определенным процессом w3wp.exe, откройте командную строку администрирования, переключитесь в %windir%\System32\inetsrv папку cd %windir%\System32\inetsrv и запустите список appcmd wp. В кавычках отобразится идентификатор процесса (PID) процесса w3wp.exe. Этот идентификатор можно сопоставить с идентификатором PID, доступным в диспетчере задач.

Убедившись, что процесс w3wp.exe испытывает высокий уровень ЦП, необходимо собрать две части информации, чтобы определить причину проблемы.

  • Набор сборщиков данных Монитор производительности.
  • Дамп памяти в пользовательском режиме процесса w3wp.exe.

Оба из них должны быть собраны во время события высокой загрузки ЦП.

Сбор набора сборщика данных Монитор производительности

Монитор производительности (Perfmon) данные часто критически важны при определении причины проблем с высокой загрузкой ЦП. Кроме того, это может быть очень полезно при получении представления "большой картины" о том, как работает ваше приложение.

Данные perfmon можно просматривать в режиме реального времени или собирать в наборе сборщиков данных, который можно просмотреть позже. Чтобы устранить проблему с высокой загрузкой ЦП, необходимо собрать набор сборщиков данных. Чтобы создать набор сборщиков данных для устранения неполадок с высокой загрузкой ЦП, выполните следующие действия.

  1. Откройте средства администрирования из панель управления Windows.

  2. Дважды щелкните Монитор производительности.

  3. Разверните узел наборов сборщика данных.

  4. Щелкните правой кнопкой мыши определяемый пользователем элемент и выберите "Создать", "Набор сборщиков данных".

  5. Введите высокий ЦП в качестве имени набора сборщиков данных.

  6. Установите переключатель "Создать вручную (дополнительно)".

  7. Нажмите кнопку "Далее".

  8. Нажмите переключатель "Создать журналы данных".

  9. Установите флажок счетчика производительности.

  10. Нажмите кнопку "Далее".

  11. Нажмите кнопку Добавить.

    Если приложение не является ASP.NET приложением, перейдите к шагу 19.

  12. Прокрутите страницу до верхней части списка счетчиков и выберите память СРЕДЫ CLR .NET.

  13. В списке экземпляров выберите <все экземпляры>.

  14. Нажмите кнопку "Добавить", чтобы добавить счетчики в список добавленных счетчиков.

  15. Выберите ASP.NET в списке счетчиков и нажмите кнопку "Добавить".

  16. Выберите ASP.NET Приложения из списка счетчиков.

  17. Выберите <все экземпляры>из списка экземпляров.

  18. Нажмите кнопку "Добавить".

  19. Разверните процесс из списка счетчиков. (Убедитесь, что вы разворачиваете процесс, а не процессор.)

  20. Выберите % процессорного времени в объекте Process.

  21. Выберите <все экземпляры>из списка экземпляров.

  22. Нажмите кнопку "Добавить".

  23. Разверните поток из списка счетчиков.

  24. Выберите % процессорного времени в объекте Thread.

  25. Выберите <все экземпляры>из списка экземпляров.

  26. Нажмите кнопку "Добавить".

  27. Выберите поток идентификатора из списка экземпляров.

  28. Нажмите кнопку "Добавить".

Теперь диалоговое окно должно выглядеть так, как показано на рис. 2.

Снимок экрана: диалоговое окно

Рис. 2. Создание набора сборщиков данных.

Нажмите кнопку "ОК" и нажмите кнопку "Далее". Запишите место сохранения набора сборщиков данных. (Вы можете изменить это расположение, если это необходимо.) Затем нажмите кнопку "Готово".

Набор сборщиков данных еще не запущен. Чтобы запустить его, щелкните правой кнопкой мыши высокий ЦП в узле, определяемом пользователем, и выберите пункт "Пуск" в меню.

Создание правила диагностики отладки 1.2

Самый простой способ сбора дампов процессов в пользовательском режиме при возникновении высокой нагрузки ЦП — использовать диагностику отладки 1.2 или DebugDiag. DebugDiag можно скачать по следующему URL-адресу.

https://www.microsoft.com/download/en/details.aspx?id=26798

Установите DebugDiag 1.2 на сервере и запустите его. (Его можно найти в меню "Пуск" после установки.) При запуске DebugDiag откроется диалоговое окно "Выбор типа правила". Выполните следующие действия, чтобы создать правило сбоя для пула приложений.

  1. Выберите "Производительность" и нажмите кнопку "Далее".
  2. Выберите счетчики производительности и нажмите кнопку "Далее".
  3. Нажмите кнопку "Добавить триггеры perf".
  4. Разверните объект Processor (а не Process) и выберите % времени процессора. Обратите внимание, что если вы используете Windows Server 2008 R2 и имеете более 64 процессоров, выберите объект "Сведения о процессоре" вместо объекта Processor.)
  5. В списке экземпляров выберите _Total.
  6. Нажмите кнопку Добавить, а затем кнопку ОК.
  7. Выберите добавленный триггер и нажмите кнопку "Изменить пороговые значения", как показано на рис. 3.
  8. Выберите "Выше" в раскрывающемся списке.
  9. Измените пороговое значение на 80.
  10. Введите 20 в течение нескольких секунд. (При необходимости это значение можно настроить, но не указывайте небольшое количество секунд, чтобы предотвратить ложные триггеры.)
  11. Щелкните ОК.
  12. Нажмите кнопку "Далее".
  13. Нажмите кнопку "Добавить целевой дамп".
  14. Выберите пул веб-приложений в раскрывающемся списке.
  15. Выберите пул приложений из списка пулов приложений.
  16. Щелкните ОК.
  17. Нажмите кнопку "Далее".
  18. Нажмите Далее еще раз.
  19. Введите имя правила, если вы хотите, и запишите расположение, в котором будут сохранены дампы. При необходимости вы можете изменить это расположение.
  20. Нажмите кнопку "Далее".
  21. Нажмите кнопку "Активировать правило сейчас" и нажмите кнопку "Готово".

Совет

Вы можете создавать дампы нескольких пулов приложений, добавляя несколько целевых объектов дампа, используя один и тот же метод, используемый в шагах 13–15.

Снимок экрана: диалоговое окно

Рис. 3. Добавление триггеров perf в DebugDiag.

Это правило создаст 11 файлов дампа. Первые 10 будут "мини-дампы", которые будут довольно небольшими по размеру. Окончательный дамп будет дампом с полной памятью, и что дампы будут гораздо больше.

После возникновения высокой проблемы с ЦП необходимо остановить сборщик данных Perfmon от сбора данных. Для этого щелкните правой кнопкой мыши набор сборщика данных высокой загрузки ЦП, указанный в определяемом пользователем узле, и выберите "Остановить".

Анализ данных

После события высокой загрузки ЦП у вас будет два набора данных для просмотра; Набор сборщика данных Perfmon и дампы памяти. Начнем с просмотра данных Perfmon.

Анализ данных о производительности

Чтобы просмотреть данные Perfmon для проблемы, щелкните правой кнопкой мыши набор сборщика данных высокой загрузки ЦП, указанный в определяемом пользователем узле, и выберите "Последний отчет". Вы увидите что-то подобное на экране, показанном на рис. 4.

Снимок экрана: окно Монитор производительности.

Рис. 4. Perfmon, отображающий данные высокой загрузки ЦП.

Первое, что нужно сделать, — удалить все текущие счетчики, чтобы можно было добавить явные счетчики, которые требуется проверить. Выберите первый счетчик в списке. Затем прокрутите вниз до конца списка и щелкните последний счетчик, удерживая клавишу SHIFT на клавиатуре. Выбрав все счетчики, нажмите клавишу DELETE на клавиатуре, чтобы удалить их.

Теперь добавьте счетчик "Процесс / % времени процессора", выполнив следующие действия.

  1. Щелкните правой кнопкой мыши в любом месте в правой области Perfmon и выберите "Добавить счетчики".
  2. Разверните объект Process.
  3. Выберите % времени процессора в списке.
  4. Выберите <все экземпляры из списка экземпляров>.
  5. Нажмите кнопку "Добавить".
  6. Щелкните ОК.

Теперь будет отображаться график времени процессора, используемый каждым процессом на компьютере во время выполнения набора сборщика данных. Самый простой способ изолировать процесс, использующий самый высокий уровень ЦП, — включить функцию выделения Perfmon.

Для этого выберите первый счетчик в списке и нажмите клавиши CTRL+H. После этого выбранный процесс будет отображаться как полужирная черная линия на графике.

Используйте стрелку вниз на клавиатуре, чтобы перейти вниз по списку процессов, пока не найдешь процесс, показывающий большую загрузку ЦП. На рисунке 5 видно, что процесс w3wp.exe использовал большой объем ЦП на компьютере. Это подтверждает, что пул приложений IIS вызывает высокую загрузку ЦП на компьютере.

Снимок экрана: окно Монитор производительности. Perfmon показывает использование C P U исполняемого файла w 3 w p.

Рис. 5. Perfmon, показывающий использование ЦП w3wp.exe.

Совет

Perfmon может оказаться очень полезным при определении проблем с производительностью в приложении. Данные, собранные в журнале Perfmon, могут показать, сколько запросов выполняется (с помощью объектов ASP.NET и ASP.NET Приложений), а также может показать другие важные данные о производительности приложения.

Чтобы добраться до корня проблемы с высокой загрузкой ЦП, давайте рассмотрим дампы, созданные с помощью DebugDiag.

Анализ дампа с помощью DebugDiag

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

  1. Выберите вкладку "Расширенный анализ" в DebugDiag.
  2. Выберите анализаторы производительности.
  3. Нажмите кнопку "Добавить файлы данных".
  4. Браузер в расположение, в котором были созданы дампы. По умолчанию это будет вложенная папка C:\Program Files\DebugDiag\Logs папки.
  5. Выберите один из дампов и нажмите клавиши CTRL+A, чтобы выбрать все дампы в этой папке.
  6. Нажмите кнопку Открыть.
  7. Нажмите кнопку Начать анализ.

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

Снимок экрана: Internet Explorer. Отобразится страница отчета об анализе отладочной диагностики.

Рис. 6. Отчет об анализе DebugDiag.

Обратите внимание, что в верхней части отчета показано, что обнаружен высокий уровень ЦП. В правом столбце вы увидите рекомендации, содержащие ссылку на 7 потоков по среднему времени ЦП. Щелкните эту ссылку, и вы увидите сведения о том, что делают эти основные потребители ЦП. На рисунке 7 показано, что делают эти потоки в моем приложении.

Снимок экрана: страница

Рис. 7. Сведения о потоках ЦП с высоким уровнем загрузки.

Я могу сказать из этого анализа, что страница default.aspx в приложении FastApp запущена. Если посмотреть дальше вниз стек вызовов (в нижней части страницы), я вижу, что этот поток выполняет объединение строк. (Обратите внимание на вызов System.String.Concat в стеке вызовов.) Если проанализировать другие основные потоки ЦП, я вижу тот же шаблон.

Следующим шагом является просмотр события Page_Load на странице default.aspx приложения FastApp. Когда я делаю это, я нахожу следующий код.

htmlTable += "<table>";
for (int x = 0; x < 5000; x++)
{
htmlTable += "<tr>" + "<td>" + "Cell A" + x.ToString() + "</td>";
    htmlTable += "<td>" + "Cell B" + x.ToString() + "</td>" + "</tr>";
}
htmlTable += "</table>";

Этот вид кода, безусловно, приведет к высокой загрузке ЦП. Дополнительные сведения см https://support.microsoft.com/kb/307340 . в базе знаний Майкрософт.

Заключение

С помощью Perfmon и DebugDiag можно легко собирать данные, которые могут быть полезны при определении причины высокой загрузки ЦП в пулах приложений. Если вы не можете найти основную причину, используя эти методы, вы можете открыть запрос в службу поддержки с помощью https://support.microsoft.com/ Корпорации Майкрософт, и мы можем помочь вам определить причину проблемы. Подготовив данные и дампы Perfmon для нас при открытии дела, вы значительно сократите время, необходимое для нас, чтобы помочь вам.

Другие ресурсы