Этот рабочий процесс загружает процессор

Обновлено: 21.11.2024

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

Я уже пробовал использовать ANTS. Однако с ANTS вам нужно знать, что это за сайт, а затем запустить его и ожидать в указанном веб-приложении, вызывающем сбой ЦП. Не совсем идеально.

3 ответа 3

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

Надеюсь, мой совет каким-то образом поможет решить проблему с IIS.

Ниже текст моего ответа:

Сколько пулов приложений? Вы можете начать с перемещения своих веб-сайтов в отдельные пулы приложений, а затем использовать диспетчер задач + командную строку iisapp, чтобы сопоставить, какой пул приложений соответствует какой задаче. Это поможет вам определить, с какой сети начинать.

Использование диагностики отладки IIS для устранения неполадок, связанных с использованием ЦП рабочим процессом в II6

Отслеживание неудачных запросов в IIS7 может помочь отследить многие проблемы с производительностью веб-сайтов, но у нас по-прежнему есть широкая клиентская база IIS6. Устранение проблем с производительностью в IIS6 было довольно сложной задачей, пока Microsoft не выпустила набор инструментов, позволяющих лучше анализировать трассировку стека.

Установите средство диагностики отладки IIS локально в системе.

Откройте средство диагностики отладки в меню "Пуск" > "Программы" > "Диагностика IIS" > "Средство диагностики отладки" > "Средство диагностики отладки".

Нажмите Инструменты > Параметры и настройки > вкладка Журнал производительности. Выберите параметр «Включить регистрацию данных счетчика производительности». Нажмите "ОК".

Используйте диспетчер задач, чтобы найти PID рабочего процесса.

Выберите вкладку «Процессы» и найдите процесс в списке.

Щелкните правой кнопкой мыши процесс и выберите «Создать полный пользовательский дамп». Это займет несколько минут, после чего появится всплывающее окно с указанием пути к файлу дампа.

Выберите вкладку «Расширенный анализ» и нажмите кнопку «Добавить файлы данных». Перейдите к файлу дампа, который был создан переходом, и нажмите OK.

Выберите «Анализаторы сбоев/зависаний» в поле «Доступные сценарии анализа» для производительности ЦП и анализа сбоев. Нажмите «Начать анализ».

Через несколько минут должен быть создан отчет, содержащий информацию о трассировке стека, а также информацию о любых запросах, выполняемых дольше 90 секунд. Обратите внимание, что дамп памяти занимает несколько сотен мегабайт, поэтому обязательно устанавливайте инструмент на диск с достаточным пространством для отладки. Также, если бокс находится под большой нагрузкой, вы можете создать дамп пользователя в системе, скопировать файл на свою рабочую станцию ​​и выполнить анализ локально.

Многие веб-сайты IIS будут испытывать снижение производительности из-за высокой загрузки ЦП w3wp… часто задолго до того, как вы достигнете 80% процессорного времени!

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

Использование 100 % процессорного времени обычно не является проблемой для более простых программ, которые выполняют одно действие с интенсивным использованием ЦП, такое как кодирование видео, сжатие или передача файлов.

К сожалению, это не относится к веб-приложениям.

(Для этого есть причины, об этом чуть позже)

Типичный веб-сайт IIS может столкнуться с большими проблемами при нагрузке, в том числе:

  1. 503/очереди переполнены.
  2. Высокая загрузка ЦП (когда веб-сайт перестает обслуживать запросы или запросы выполняются очень медленно)
  3. Удвоенная или более высокая стоимость хостинга (чтобы поддерживать низкую загрузку ЦП на каждом сервере, даже при пиковой нагрузке)

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

Почему высокая загрузка ЦП w3wp.exe приводит к снижению производительности?

Легко понять, почему производительность может страдать при 100%-й загрузке ЦП сервера, но почему приложение начинает зависать, когда процессор даже не используется полностью?

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

Веб-приложение «задыхается» при более высокой загрузке ЦП из-за неэластичных узких мест производительности.

Недавно я писал о конкретных причинах и способах их устранения в разделе Высокая загрузка ЦП в руководстве по рабочим процессам IIS. К ним относятся:

  1. Исчерпание пула потоков. Пул потоков не может эффективно увеличиваться под нагрузкой ЦП, что приводит к очередям запросов и тайм-аутам.
  2. Голодание асинхронной задачи. Асинхронные или параллельные задачи не могут быть выполнены из-за конкуренции за потоки пула потоков с входящими запросами (которые в основном обречены на тайм-аут по той же причине).
  3. Истощение пула потоков IIS. У IIS заканчиваются потоки для удаления входящих запросов из очереди, что приводит к большому количеству ошибок 503 по мере заполнения очереди пула приложений.
  4. Время ожидания и пустая обработка. Обработка запросов, которые в конечном итоге завершаются сбоем или истекают по времени, тратит впустую доступную пропускную способность ЦП без каких-либо полезных результатов.
  5. Переключение контекста, сборка мусора и конфликты блокировок. Это некоторые из наиболее распространенных действий, которые истощают полезную пропускную способность ЦП под нагрузкой.

Неэластичное приложение часто сталкивается с этими узкими местами под нагрузкой, и это приводит к тому, что его производительность хуже, чем должна быть теоретически, если бы оно могло «растягиваться» под нагрузкой.

Повышение гибкости веб-сайта IIS при высокой загрузке ЦП

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

Это означает устойчивую производительность при высокой нагрузке, более низкие затраты на хостинг и лучшую масштабируемость.

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

LeanSentry диагностирует код, вызывающий высокую загрузку ЦП в рабочей среде.

Затем вы можете использовать диагностические отчеты для оптимизации нужного кода.

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

Отчеты о диагностике ЦП LeanSentry, в которых выделяются возможности оптимизации кода, вызывающего высокую загрузку ЦП.

Этот материал предоставлен исключительно в ознакомительных целях. Microsoft не дает никаких явных или подразумеваемых гарантий.

Обзор

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

Сценарий

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

Сбор данных

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

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

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

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

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

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

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

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

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

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

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

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

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

Нажмите правой кнопкой мыши на User Defined и выберите New, Data Collector Set.

Введите High CPU в качестве имени набора сборщиков данных.

Выберите переключатель «Создать вручную (дополнительно)».

Выберите переключатель «Создать журналы данных».

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

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

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

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

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

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

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

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

Выберите ID Thread из списка экземпляров.

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

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

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

Набор сборщиков данных еще не запущен. Чтобы запустить его, щелкните правой кнопкой мыши High CPU в узле User Defined и выберите Start из меню.

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

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

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

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

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

Рис. 3. Добавление триггеров производительности в DebugDiag.

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

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

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

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

Анализ данных об эффективности

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

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

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

Теперь добавьте счетчик Process / % Processor Time, выполнив следующие действия.

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

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

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

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

Рисунок 5. Монитор производительности, показывающий загрузку ЦП программой w3wp.exe.

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

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

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

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

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

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

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

У меня есть локальная ферма SharePoint 2016 с двумя серверами, один интерфейсный и один для поиска. Все работало нормально, пока несколько дней назад.
Первый имеет постоянную загрузку процессора 100%, когда рабочий процесс IIS берет то, что находит, последний работает нормально. Я заметил, что экземпляр SQL SharePoint занимает 20 ГБ и 50% процессорного времени. Я проверил журналы IIS (SharePoint) и нашел много ошибок 401, но ферма работает, медленно, но работает. В средстве просмотра событий нет ошибок, связанных с SharePoint или авторизацией.

Я попытался перезапустить SQL Server и внешний интерфейс SharePoint, в течение ~5 минут процессор стабильно работает на уровне 30%, затем поднимается до 90-100%. Перезапуск только IIS приводит к такому же поведению.

В ULS нет ошибок.

Если я остановлю серверную службу Workflow Manager, загрузка ЦП снизится до 10 %. Когда я перезапускаю его, он возвращается к 100%.

Как найти проблему?

1 Ответ 1

Это развертывание с выходом в Интернет? Рабочие процессы работают правильно? 401, в основном означает исключение несанкционированного доступа. Может ли быть так, что серверная служба Workflow Manager каким-то образом неправильно настроена? Пробовали ли вы переустановить серверную службу Workflow Manager? Вы также должны убедиться, что нет забытых служб с устаревшим кэшированным паролем, пытающихся войти в API sharepoint.

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

Спасибо за ответ. Как я писал в вопросе, ферма работает, медленно, но работает. Переустановка WF-Manager требует времени и всегда требует усилий, это будет последний из моих вариантов. Я думаю, что проблема связана с серверами SharePoint->SQL.

Затем следует запустить отчет о расширенных событиях на сервере sql. Это покажет, что вы хотите, чтобы это происходило, и какие процедуры тормозятся. Я столкнулся с похожей проблемой, когда мой клиент изменил пороговое значение представления списка и пытался просмотреть библиотеку документов с тысячами элементов внутри. Повышение верхнего предела порога просмотра списка оказало огромное влияние на SQL Server, поскольку SQL-сервер искал 100 000 элементов при каждом запуске, и в целом это замедляло работу всей партии. Переключение порога просмотра списка сделало часть снова работоспособной.

В средстве просмотра событий -> Журналы приложений и служб -> Microsoft-Workflow -> Operational я видел много записей, примерно 20 в секунду. Я думаю, что это проблема, должен быть один или несколько зависших WF. Я написал сценарий PowerShell, чтобы найти их.

Читайте также: