Устранение неполадок с высоким ЦП в пуле приложений IIS
Применимо к: службы IIS
Это средство устранения неполадок поможет определить причину устойчивого высокого ЦП в пуле приложений службы IIS (IIS). Важно помнить, что это нормально для увеличения использования ЦП, так как веб-приложение обслуживает запросы. Однако если вы постоянно видите, что ЦП остается на высоком уровне (в области 80 % или больше) в течение длительного периода, производительность вашего приложения будет страдать. По этой причине важно понять причину устойчивого высокого ЦП, чтобы его можно было устранить и исправить, если это возможно.
Сценарий
Пул приложений в IIS испытывает длительный период высокого ЦП, превышающий 90%. При тестировании приложения не возникают проблемы. Однако после того, как приложение испытывает фактическую нагрузку пользователя, ЦП поднимается на высокий процент и остается. Чтобы восстановить, пул приложений должен быть перезапущен, но после этого ЦП снова поднимается на высокий уровень.
Инструменты
- Отладка диагностики (DebugDiag)
- Монитор производительности (Perfmon)
Сбор данных
Первое, что необходимо сделать при возникновении проблем с высоким потреблением ЦП, — определить процесс, который потребляет ЦП. Для этого можно использовать вкладку "Процессы " в диспетчере задач. Убедитесь, что установлен флажок "Показать процессы" для всех пользователей . На следующем рисунке показан флажок и показан w3wp.exe
процесс (процесс, на котором размещен пул приложений IIS), который потребляет высокий уровень ЦП.
Вы также можете использовать Монитор производительности для определения того, какой процесс использует ЦП. Дополнительные сведения об использовании Монитор производительности см. в статье "Анализ данных о производительности".
Совет
Если необходимо определить, какой пул приложений связан с определенным процессом w3wp.exe, откройте командную строку администрирования, переключитесь в %windir%\System32\inetsrv
папку cd %windir%\System32\inetsrv
и запустите appcmd list wp
. Откроется идентификатор процесса (PID) процесса w3wp.exe процесса в кавычках. Этот идентификатор можно сопоставить с идентификатором PID, доступным в диспетчере задач.
Убедившись, что процесс w3wp.exe испытывает высокий уровень ЦП, необходимо собрать следующие сведения, чтобы определить, что вызывает проблему:
- Набор сборщика данных Монитор производительности.
- Дамп памяти в пользовательском режиме процесса w3wp.exe.
Оба из них должны быть собраны во время большого события ЦП.
Сбор Монитор производительности набор сборщика данных
Монитор производительности данные часто критически важны при определении причины проблем с высоким ЦП. Кроме того, это может быть очень полезно в получении представления о том, как работает ваше приложение.
Данные perfmon можно просматривать в режиме реального времени или собирать их в наборе сборщиков данных, который можно просмотреть позже. Чтобы устранить проблему с высоким уровнем ЦП, необходимо собрать набор сборщиков данных. Чтобы создать набор сборщиков данных для устранения неполадок с высоким уровнем ЦП, выполните следующие действия.
- Откройте средства администрирования из Панель управления Windows.
- Дважды щелкните Монитор производительности.
- Разверните узел наборов сборщиков данных.
- Щелкните правой кнопкой мыши определяемый пользователем и выберите новый> набор сборщика данных.
- Введите высокий ЦП в качестве имени набора сборщиков данных.
- Выберите "Создать вручную" (дополнительно).
- Выберите Далее.
- Выберите "Создать журналы данных".
- Установите флажок счетчика производительности.
- Выберите Далее.
- Выберите Добавить. Если приложение не является ASP.NET приложением, перейдите к шагу 19.
- Прокрутите страницу до верхней части списка счетчиков и выберите память .NET CLR.
- В списке экземпляров выберите <все экземпляры>.
- Нажмите кнопку "Добавить ", чтобы добавить счетчики в список добавленных счетчиков.
- Выберите ASP.NET из списка счетчиков и нажмите кнопку "Добавить".
- Выберите ASP.NET Приложения из списка счетчиков.
- Выберите <все экземпляры> из списка экземпляров.
- Выберите Добавить.
- Разверните процесс из списка счетчиков. (Убедитесь, что развернуто Процесс и не процессор.)
- Выберите %Processor Time из объекта Process .
- Выберите <все экземпляры> из списка экземпляров.
- Выберите Добавить.
- Разверните поток из списка счетчиков.
- Выберите % времени процессора из объекта Thread .
- Выберите <все экземпляры> из списка экземпляров.
- Выберите Добавить.
- Выберите поток идентификатора из списка экземпляров.
- Выберите Добавить.
Диалоговое окно должно выглядеть следующим образом.
Нажмите кнопку ОК ->Далее. Запишите, где сохраняется набор сборщиков данных. (Вы можете изменить это расположение, если вам нужно.) Затем нажмите кнопку "Готово".
Набор сборщиков данных еще не запущен. Чтобы запустить его, щелкните правой кнопкой мыши высокий ЦП в узле, определяемом пользователем, и выберите " Пуск " в меню.
Создание правила диагностики отладки
Самый простой способ сбора дампов процесса в пользовательском режиме при возникновении высокого состояния ЦП — использовать диагностику отладки.
Скачайте DebugDiag, установите его на сервере и запустите его. (Найдите его наМеню "Пуск " после установки.) При запуске DebugDiag откроется диалоговое окно "Выбор типа правила". Выполните следующие действия, чтобы создать правило сбоя для пула приложений:
- Нажмите кнопку "Производительность -> Далее".
- Выберите счетчики производительности ->Далее.
- Выберите " Добавить триггеры perf".
- Разверните объект Обработчика (а не процесс) и выберите % Времени процессора. Обратите внимание, что если вы находитесь в Windows Server 2008 R2 и имеете более 64 процессоров, выберите объект Processor Information вместо объекта Processor .
- В списке экземпляров выберите _Total.
- Нажмите кнопку "Добавить -> ОК".
- Выберите только что добавленный триггер и выберите пункт "Изменить пороговые значения".
- Выберите выше в раскрывающемся списке.
- Измените пороговое значение на 80.
- Введите 20 секунд. (При необходимости можно настроить это значение, но не следует указывать небольшое количество секунд, чтобы предотвратить ложные триггеры.)
- Нажмите кнопку ОК.
- Выберите Далее.
- Выберите " Добавить целевой дампа".
- Выберите пул веб-приложений в раскрывающемся списке.
- Выберите пул приложений из списка пулов приложений.
- Нажмите кнопку ОК.
- Выберите Далее.
- Снова выберите Далее.
- Введите имя правила, если вы хотите, и запишите расположение, в котором будут сохранены дампы. Это расположение можно изменить при желании.
- Выберите Далее.
- Нажмите кнопку "Активировать правило сейчас", а затем нажмите кнопку "Готово".
Совет
Вы можете создать дампы нескольких пулов приложений, добавив несколько целевых объектов дампа с помощью одного метода, используемого в шагах 13-15.
Это правило создаст 11 файлов дампа. Первые 10 будут "мини-дампы", которые будут довольно небольшим размером. Последний дамп будет дампом с полной памятью, и что дампы будут гораздо больше.
После возникновения проблемы с высокой загрузкой ЦП необходимо остановить набор сборщика данных Perfmon от сбора данных. Для этого щелкните правой кнопкой мыши набор сборщика данных высокого уровня ЦП, указанный в узле, определяемом пользователем, и нажмите кнопку "Остановить".
Анализ данных
После события высокой загрузки ЦП у вас будет два набора данных для просмотра; Набор сборщика данных Perfmon и дампы памяти. Начнем с просмотра данных Perfmon.
Анализ данных о производительности
Чтобы просмотреть данные Perfmon для вашей проблемы, щелкните правой кнопкой мыши набор сборщика данных высокого уровня ЦП, указанный в узле, определенном пользователем, и выберите последний отчет. Вы увидите отчет, аналогичный следующему снимку экрана.
Первое— удалить все текущие счетчики, чтобы можно было добавить явные, которые требуется проверить. Выберите первый счетчик в списке. Затем прокрутите страницу до нижней части списка и выберите последний счетчик, удерживая клавишу SHIFT. Выбрав все счетчики, нажмите клавишу DELETE, чтобы удалить их.
Теперь добавьте счетчик времени процессора Process / % с помощью следующих действий:
- Щелкните правой кнопкой мыши в правой области Perfmon и выберите "Добавить счетчики".
- Разверните объект Process.
- Выберите % времени процессора в списке.
- Выберите все экземпляры из списка экземпляров>.<
- Выберите Добавить.
- Нажмите кнопку ОК.
Теперь появится дисплей, показывающий график времени процессора, используемый каждым процессом на компьютере во время выполнения набора сборщиков данных. Самый простой способ изолировать процесс, который использовал самый высокий уровень ЦП, — включить функцию выделения Perfmon.
Для этого выберите первый счетчик в списке, а затем нажмите клавиши CTRL+H. После этого выбранный процесс будет отображаться как полужирная черная линия на графе.
Используйте стрелку вниз на клавиатуре, чтобы перейти к списку процессов, пока не найдите процесс, показывающий наибольшее использование ЦП. На следующем снимке экрана видно, что w3wp.exe процесс использовал большой объем ЦП на компьютере. Это подтверждает, что пул приложений IIS вызывает высокую загрузку ЦП на компьютере.
Совет
Perfmon может оказаться очень полезным при определении проблем с производительностью в приложении. Данные, собранные в журнале Perfmon, могут показать, сколько запросов выполняется (с помощью объектов ASP.NET и ASP.NET Приложений), а также может показать другие важные данные о производительности вашего приложения.
Чтобы получить корень того, что вызывает высокую проблему ЦП, давайте рассмотрим дампы, созданные с помощью DebugDiag.
Анализ дампа с помощью DebugDiag
DebugDiag имеет возможность распознавать множество проблем, выполняя автоматический анализ дампа. Для этой конкретной проблемы Анализатор производительности DebugDiag хорошо подходят для выявления первопричины проблемы с высоким ЦП. Чтобы использовать анализатор, выполните следующие действия.
- Выберите вкладку "Расширенный анализ" в DebugDiag.
- Выберите Анализатор производительности.
- Выберите " Добавить файлы данных".
- Браузер в расположение, в котором были созданы дампы. По умолчанию это будет вложенная папка папки C:\Program Files\DebugDiag\Logs .
- Выберите один из дампов и нажмите клавиши CTRL+A, чтобы выбрать все дампы в этой папке.
- Выберите Открыть.
- Выберите Начало анализа.
DebugDiag занимает несколько минут, чтобы проанализировать дампы и предоставить анализ. После завершения анализа вы увидите страницу, аналогичную приведенной на следующем рисунке.
Обратите внимание, что в верхней части отчета сообщается, что обнаружен высокий ЦП. В правом столбце вы увидите рекомендации, которые включают ссылку на первые 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 и дампы готовы при открытии дела, вы значительно сократите время, необходимое для инженеров, чтобы помочь вам.