Чому 1 з 24 моїх процесорів прив’язаний до 100%?

У мене є система HP ProLiant DL380 G7, що використовує 2 6-ядерних процесора з увімкненою Hyper-Thading, для загальної кількості 24 логічних процесорів (як це бачило Windows).

Під час запуску нашого додатка загальне використання системного процесора добре, але одна з 24 CUP прив’язана до 100%:

Редагувати: це дані PerfMon для системного процесу за цей час та для процесора з високим рівнем використання:

Це нормально? Якщо ні, чи є спосіб визначити, які процеси використовують цей логічний процесор? Windows PerfMon, ResMon, диспетчер завдань та провідник процесів не допомогли, окрім того, щоб визначити, що CPU на 100%.

Як вже зазначали інші, з цього знімка ми бачимо, що процесор, який так важко працює, весь свій час проводить у режимі ядра. (Червоний колір.)

Запуск Powershell як адміністратора, введіть:

Get-Process | Select Name, PrivilegedProcessorTime | `
Sort-Object PrivilegedProcessorTime -Descending

Процес у верхній частині списку - це процес, який зараз використовує найбільше час процесора в режимі ядра. Якщо цей процес не "Системний", то ви тільки що з'ясували, який процес в режимі користувача викликає це використання процесора. Якщо процес із найвищим привілейованим процесорним часом - це система, на яку я підозрюю, що це, то це трохи складніше.

Відкрийте Провідник процесів. За бажанням встановіть свій сервер символів. Переконайтеся, що ви бігаєте з повним підйомом UAC. Клацніть правою кнопкою миші «процес» системи та перейдіть до Властивості. Потім перейдіть на вкладку "Нитки". Сортування потоків за використанням процесора. Тут повинен бути потік, що викликає всю роботу цього режиму ядра. Якщо ви подивитеся на модуль, вказаний у розділі "Початкова адреса", він повинен дати вам зрозуміти, з чим пов'язана робота. Наприклад, це NDIS.sys, наприклад, це драйвер мережевого інтерфейсу. Якщо ви налаштуєте сервер символів, вам слід побачити назву функції в модулі (якщо модуль не є Microsoft), інакше ви просто побачите числове зміщення зі стартової адреси модуля.

Крім того, використовуйте Xperf з інструментарію Windows Performance Toolkit для переривання профілю, DPC тощо.

xperf -on PROC_THREAD+LOADER+DPC+INTERRUPT

і припиніть запис за допомогою xperf -d logfile.etl

Xperf замінює старий інструмент Kernrate, і він може представити вам надзвичайно детальні дані.

Коли центральний процесор працює в режимі ядра, він в основному виконує процедури переривання обслуговування. (ISR) Коли відбувається переривання, на цьому процесорі призупиняється робота в режимі користувача, і ЦП запускає зареєстрований в цьому перериванні ISR. Якщо ви виявите, що ваш процесор витрачає непомірну кількість часу на ці перерви, це, як правило, вказує на несправний драйвер пристрою, який потрібно оновити.

Що мене помиляє (не каламбур) щодо цього сценарію, це те, що він здається, ніби будь-яка нитка ядра, що робить це, здається, є спорідненою до цього одного ядра. Цікаво, чому диспетчер, здається, лише планує потік, щоб він працював на тому, здавалося б, довільному ядрі. Тож у мене виникає відчуття, що нам потрібно знайти того, хто написав цей драйвер пристрою, і показати їм, як робити потокові DPC, а не чітко встановлювати спорідненість у потоках ядра тощо.

Покажіть стовпець «Час процесора» на вкладці «Деталі» в «Диспетчері завдань» та шукайте процес із кількістю часу процесора, який постійно збільшується. Це ваш укладений процес. Він повинен постійно використовувати близько 4,17% процесора.

Здається, весь час в ядрі, може бути Переривання, їх може обробляти лише один процесор.

Шукайте процес із постійною витратою процесора ~ 4% (= 1/24 від загальної кількості доступних процесорів). Це має бути той, хто постійно займає один процесор.