Por que 1 de minhas 24 CPUs está 100% indexado?

Eu tenho um sistema HP ProLiant DL380 G7 usando 2 CPUs de 6 núcleos, com o Hyper-threading ativado, para um total de 24 CPUs lógicas (como visto pelo Windows).

Ao executar nosso aplicativo, a utilização total da CPU do sistema é boa, mas um dos 24 CUPs está atrelado a 100%:

Editar: esses são os dados do PerfMon para o processo do sistema durante esse período e para o processador com alta utilização:

Isso é normal? Caso contrário, existe uma maneira de identificar quais processos estão usando essa CPU lógica? O Windows PerfMon, ResMon, Gerenciador de Tarefas e Process Explorer não ajudaram, além de identificar que a CPU está em 100%.

Como outros já apontaram, podemos ver nessa captura de tela que a CPU que está trabalhando tanto está gastando todo o seu tempo no modo kernel. (A cor vermelha.)

Executando o Powershell como administrador, digite:

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

O processo no topo da lista é o processo atualmente usando o tempo de CPU com mais kernel no momento. Se esse processo não for "Sistema", você acabou de descobrir qual processo do modo de usuário está causando esse uso da CPU. Se o processo com o maior tempo de processador privilegiado for System, que eu suspeito que seja, será um pouco mais complicado.

Abra o Process Explorer. Opcionalmente, configure seu servidor de símbolos. Verifique se você está executando com elevação total do UAC. Clique com o botão direito do mouse no "processo" do sistema e vá para Propriedades. Em seguida, vá para a guia Threads. Classifique os threads por uso da CPU. O thread que está causando todo esse trabalho no modo kernel deve estar aqui. Se você observar o módulo listado em Endereço inicial, ele deverá fornecer uma pista sobre o que o trabalho está relacionado. Se for NDIS.sys, por exemplo, esse é um driver de interface de rede. Se você configurar o servidor de símbolos, deverá ver o nome de uma função dentro de um módulo (a menos que o módulo não seja da Microsoft); caso contrário, verá apenas um deslocamento numérico do endereço inicial do módulo.

Como alternativa, use o Xperf do Windows Performance Toolkit para criar perfil de interrupções, DPCs, etc.

xperf -on PROC_THREAD+LOADER+DPC+INTERRUPT

e pare de gravar com xperf -d logfile.etl

O Xperf substitui a antiga ferramenta Kernrate e pode fornecer dados extremamente detalhados.

Quando uma CPU está trabalhando no modo kernel, geralmente executa rotinas de serviço de interrupção. (ISRs) Quando ocorre uma interrupção, o trabalho no modo de usuário é suspenso nesse processador e a CPU executa o ISR registrado para essa interrupção. Se você encontrar sua CPU gastando uma quantidade excessiva de tempo nessas interrupções, isso geralmente indica um driver de dispositivo com defeito que precisa ser atualizado.

O que me incomoda (sem trocadilhos) sobre esse cenário é que parece que qualquer thread do kernel que está fazendo isso parece estar afinizada nesse único núcleo. Eu me pergunto por que o expedidor parece apenas agendar o thread para executar nesse núcleo aparentemente arbitrário. Portanto, tenho a sensação de que precisamos encontrar quem escreveu esse driver de dispositivo e mostrar a eles como executar DPCs encadeados, e não definir explicitamente uma afinidade nos encadeamentos do kernel, etc.

Mostre a coluna "Tempo da CPU" na guia "Detalhes" em "Gerenciador de tarefas" e procure um processo com uma contagem de tempo da CPU que está aumentando constantemente. Esse é o seu processo em cunha. Ele deve usar cerca de 4,17% da CPU constantemente.

Parece que todo o tempo do Kernel pode ser interrompido, eles podem ser manipulados apenas por uma única CPU.

Procure um processo com uma utilização constante da CPU de ~ 4% (= 1/24 da CPU total disponível). Essa deve ser a que está continuamente ocupando uma única CPU.