Почему 1 из моих 24 процессоров привязан на 100%?
У меня есть система HP ProLiant DL380 G7, использующая 2 6-ядерных ЦП с включенной Hyper-Threading, в общей сложности 24 логических ЦП (как видно из Windows).
При запуске нашего приложения общая загрузка ЦП системы хорошая, но один из 24 CUP привязан к 100%:
Редактировать: это данные PerfMon для системного процесса за это время и для процессора с высокой загрузкой:
Это нормально? Если нет, есть ли способ определить, какой процесс (ы) используют этот логический процессор? Windows PerfMon, ResMon, диспетчер задач и Process Explorer не помогли, кроме определения того, что загрузка процессора составляет 100%.
4 ответа
Как уже отмечали другие, из этого скриншота видно, что процессор, который работает так усердно, все время проводит в режиме ядра. (Красный цвет.)
Запустив Powershell от имени администратора, введите:
Get-Process | Select Name, PrivilegedProcessorTime | `
Sort-Object PrivilegedProcessorTime -Descending
Процесс в верхней части списка - это процесс, который в настоящее время использует больше всего процессорного времени в режиме ядра. Если этот процесс не "Системный", то вы только что выяснили, какой процесс пользовательского режима вызывает использование этого ЦП. Если процесс с наивысшим временем привилегированного процессора - это система, что, как я подозреваю, происходит, то это немного сложнее.
Откройте Process Explorer. При желании настройте свой сервер символов. Убедитесь, что вы работаете с полным уровнем UAC. Щелкните правой кнопкой мыши "Процесс" системы и перейдите в Свойства. Затем перейдите на вкладку Темы. Сортировка потоков по загрузке процессора. Поток, который вызывает всю эту работу в режиме ядра, должен быть здесь. Если вы посмотрите на модуль, указанный в поле "Начальный адрес", он должен дать вам представление о том, с чем связана работа. Например, если это NDIS.sys, это драйвер сетевого интерфейса. Если вы настроили сервер символов, вы должны увидеть имя функции в модуле (если модуль не является Microsoft), иначе вы просто увидите числовое смещение от начального адреса модуля.
В качестве альтернативы можно использовать Xperf из Windows Performance Toolkit для профилирования прерываний, DPC и т. Д.
xperf -on PROC_THREAD+LOADER+DPC+INTERRUPT
и прекратить запись с xperf -d logfile.etl
Xperf заменяет старый инструмент Kernrate и может предоставить вам очень подробные данные.
Когда процессор выполняет работу в режиме ядра, он в основном выполняет процедуры обработки прерываний. (ISR) Когда происходит прерывание, работа в пользовательском режиме приостанавливается на этом процессоре, и CPU запускает ISR, зарегистрированный для этого прерывания. Если ваш процессор тратит слишком много времени на эти прерывания, это обычно указывает на неисправный драйвер устройства, который необходимо обновить.
Что меня беспокоит (без каламбура) в этом сценарии, так это то, что он выглядит так, как будто какой-либо поток ядра, который делает это, кажется, привязан к этому ядру. Интересно, почему диспетчер, кажется, только планирует поток для запуска на этом, казалось бы, произвольном ядре. Поэтому у меня сложилось впечатление, что нам нужно найти того, кто написал этот драйвер устройства, и показать им, как делать многопоточные DPC, а не явно устанавливать привязку к потокам ядра и т. Д.
Откройте столбец "Время ЦП" на вкладке "Сведения" в "Диспетчере задач" и найдите процесс с постоянно увеличивающимся счетчиком времени ЦП. Это ваш заклиненный процесс. Он должен использовать около 4,17% ЦП постоянно.
Кажется, все время ядра, это могут быть прерывания, они могут обрабатываться только одним процессором.
Ищите процесс с постоянной загрузкой ЦП ~4% (= 1/24 от общего доступного ЦП). Это должен быть тот, который постоянно занимает один процессор.