У меня есть система HP ProLiant DL380 G7, использующая 2 6-ядерных ЦП с включенной гиперпоточностью, всего 24 логических ЦП (как видно из Windows).
При запуске нашего приложения общая загрузка ЦП системы хорошая, но один из 24 CUP привязан к 100%:
Редактировать: это данные PerfMon для системного процесса за это время и для процессора с высокой загрузкой:
Это нормально? Если нет, есть ли способ определить, какой процесс (ы) используют этот логический процессор? Windows PerfMon, ResMon, диспетчер задач и Process Explorer не помогли, кроме определения того, что загрузка процессора составляет 100%.
windows-server-2008-r2
performance
cpu-usage
Патрик Кафф
источник
источник
Ответы:
Как уже отмечали другие, из этого скриншота видно, что процессор, который работает так усердно, все время проводит в режиме ядра. (Красный цвет.)
Запустив Powershell от имени администратора, введите:
Процесс в верхней части списка - это процесс, который в настоящее время использует больше всего процессорного времени в режиме ядра. Если этот процесс не является «Системным», то вы только что выяснили, какой процесс пользовательского режима вызывает использование этого ЦП. Если процесс с наивысшим временем привилегированного процессора - это система, что, как я подозреваю, так и происходит, то это немного сложнее.
Откройте Process Explorer. При желании настройте свой сервер символов. Убедитесь, что вы работаете с полным уровнем UAC. Щелкните правой кнопкой мыши «Процесс» системы и перейдите в Свойства. Затем перейдите на вкладку Темы. Сортировка потоков по загрузке процессора. Поток, который вызывает всю эту работу в режиме ядра, должен быть здесь. Если вы посмотрите на модуль, указанный в поле «Начальный адрес», он должен дать вам представление о том, с чем связана работа. Например, если это NDIS.sys, это драйвер сетевого интерфейса. Если вы настроили сервер символов, вы должны увидеть имя функции в модуле (если модуль не является Microsoft), иначе вы просто увидите числовое смещение от начального адреса модуля.
В качестве альтернативы можно использовать Xperf из Windows Performance Toolkit для профилирования прерываний, DPC и т. Д.
и прекратить запись с
xperf -d logfile.etlXperf заменяет старый инструмент Kernrate и может предоставить вам очень подробные данные.
Когда процессор выполняет работу в режиме ядра, он в основном выполняет процедуры обработки прерываний. (ISR) Когда происходит прерывание, работа в пользовательском режиме приостанавливается на этом процессоре, и CPU запускает ISR, зарегистрированный для этого прерывания. Если ваш процессор тратит слишком много времени на эти прерывания, это обычно указывает на неисправный драйвер устройства, который необходимо обновить.
Что меня беспокоит (без каламбура) в этом сценарии, так это то, что кажется, что какой-то поток ядра, который делает это, кажется, привязан к этому ядру. Интересно, почему диспетчер, кажется, только планирует поток для запуска на этом, казалось бы, произвольном ядре. Поэтому у меня есть ощущение, что нам нужно найти того, кто написал этот драйвер устройства, и показать им, как делать многопоточные ЦОД, а не явно устанавливать привязку к потокам ядра и т. Д.
источник
Отобразите столбец «Время ЦП» на вкладке «Сведения» в «Диспетчере задач» и найдите процесс с постоянно увеличивающимся счетчиком времени ЦП. Это ваш заклиненный процесс. Он должен использовать около 4,17% ЦП постоянно.
источник
Кажется, все время ядра, это могут быть прерывания, они могут обрабатываться только одним процессором.
источник
Ищите процесс с постоянной загрузкой ЦП ~ 4% (= 1/24 от общего доступного ЦП). Это должен быть тот, который постоянно занимает один процессор.
источник