Устранение неполадок с высокой загрузкой ЦП в пуле приложений IIS

Применимо к: Службы IIS

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

Сценарий

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

Инструменты

Сбор данных

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

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

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

Совет

Если вам нужно определить, какой пул приложений связан с определенным w3wp.exe процессом, откройте командную строку администрирования, переключитесь в папку %windir%\System32\inetsrvcd %windir%\System32\inetsrv и выполните команду appcmd list wp. Будет отображаться идентификатор процесса (PID) w3wp.exe процесса в кавычках. Этот ИДЕНТИФИКАТОР можно сопоставить с PID, доступным в диспетчере задач.

Убедившись, что в процессе w3wp.exe используется высокая загрузка ЦП, вам потребуется собрать следующие сведения, чтобы определить причину проблемы:

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

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

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

Монитор производительности данные часто имеют решающее значение при определении причины проблем с высокой загрузкой ЦП. Это также может быть очень полезно для получения "информатриной картины" о том, как работает ваше приложение.

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

  1. Откройте администрирование из панель управления Windows.
  2. Дважды щелкните Монитор производительности.
  3. Разверните узел Наборы сборщиков данных .
  4. Щелкните правой кнопкой мыши Элемент User Defined (Определяемый пользователем ) и выберите Создать —>Набор сборщиков данных.
  5. Введите Высокий ЦП в качестве имени набора сборщиков данных.
  6. Выберите Создать вручную (дополнительно).
  7. Нажмите кнопку Далее.
  8. Выберите Создать журналы данных.
  9. Установите флажок Счетчик производительности .
  10. Нажмите кнопку Далее.
  11. Нажмите Добавить. Если приложение не является ASP.NET приложением, перейдите к шагу 19.
  12. Прокрутите страницу до верхней части списка счетчиков и выберите .NET CLR Memory (Память CLR для .NET).
  13. В списке экземпляров выберите <все экземпляры>.
  14. Нажмите кнопку Добавить , чтобы добавить счетчики в список добавленных счетчиков.
  15. Выберите ASP.NET в списке счетчиков, а затем нажмите кнопку Добавить.
  16. Выберите ASP.NET Приложения в списке счетчиков.
  17. Выберите <все экземпляры> из списка экземпляров.
  18. Нажмите Добавить.
  19. Разверните узел Процесс из списка счетчиков. (Убедитесь, что разверните узел Процесс , а не Обработчик.)
  20. Выберите % процессорного времени в объекте Process .
  21. Выберите <все экземпляры> из списка экземпляров.
  22. Нажмите Добавить.
  23. Разверните узел Поток из списка счетчиков.
  24. Выберите % процессорного времени в объекте Thread .
  25. Выберите <все экземпляры> из списка экземпляров.
  26. Нажмите Добавить.
  27. Выберите Id Thread в списке экземпляров.
  28. Нажмите Добавить.

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

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

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

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

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

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

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

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

Совет

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

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

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

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

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

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

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

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

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

Теперь добавьте счетчик время процессораобработки / % с помощью следующих действий:

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

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

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

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

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

Совет

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

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

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

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

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

ОтладкаDiag занимает несколько минут, чтобы проанализировать дампы и предоставить анализ. Когда анализ завершится, вы увидите страницу, похожую на ту, которая показана на следующем рисунке.

Снимок экрана: интернет-Обозреватель. Отобразится страница отчета об анализе Отладка диагностики.

Обратите внимание, что в верхней части отчета показано, что обнаружен высокий уровень ЦП. В правом столбце вы увидите рекомендации, которые включают ссылку на первые 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>";

Такой код определенно приведет к высокой загрузке ЦП.

Заключение

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

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