Perché 1 delle mie 24 CPU è ancorato al 100%?

Ho un sistema HP ProLiant DL380 G7 che utilizza 2 CPU a 6 core, con Hyper-threading abilitato, per un totale di 24 CPU logiche (come visto da Windows).

Quando si esegue la nostra applicazione, l'utilizzo totale della CPU del sistema è buono, ma uno dei 24 CUP è ancorato al 100%:

Modifica: si tratta dei dati PerfMon per il processo di sistema durante questo periodo e per il processore con elevato utilizzo:

È normale? In caso contrario, esiste un modo per identificare quali processi stanno utilizzando quella CPU logica? Windows PerfMon, ResMon, Task Manager ed Process Explorer non sono stati d'aiuto, se non quello di identificare che la CPU è al 100%.

Come altri hanno già sottolineato, da quello screenshot possiamo vedere che la CPU che sta lavorando così duramente sta trascorrendo tutto il suo tempo in modalità kernel. (Il colore rosso.)

Eseguendo Powershell come amministratore, digitare:

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

Il processo in cima all'elenco è il processo che attualmente utilizza la maggior parte del tempo CPU in modalità kernel in questo momento. Se quel processo non è "Sistema", hai appena capito quale processo in modalità utente sta causando questo utilizzo della CPU. Se il processo con il tempo di processore privilegiato più alto è il sistema, che sospetto sia, allora è un po 'più complicato.

Apri Process Explorer. Facoltativamente, imposta il server dei simboli. Assicurati di eseguire con elevazione UAC completa. Fare clic con il tasto destro del mouse sul "processo" del sistema e andare su Proprietà. Quindi vai alla scheda Discussioni. Ordina i thread in base all'utilizzo della CPU. Il thread che sta causando tutto questo funzionamento in modalità kernel dovrebbe essere qui. Se guardi il modulo elencato in Indirizzo iniziale, dovrebbe darti un indizio su ciò a cui è correlato il lavoro. Se si tratta di NDIS.sys, ad esempio, si tratta di un driver di interfaccia di rete. Se imposti il ​​server dei simboli, dovresti vedere il nome di una funzione all'interno di un modulo (a meno che il modulo non sia Microsoft), altrimenti vedrai solo un offset numerico dall'indirizzo iniziale del modulo.

In alternativa, utilizzare Xperf dal Performance Toolkit di Windows per profilare interrupt, DPC, ecc.

xperf -on PROC_THREAD+LOADER+DPC+INTERRUPT

e interrompere la registrazione con xperf -d logfile.etl

Xperf sostituisce il vecchio strumento di Kernrate e può fornirti alcuni dati estremamente dettagliati.

Quando una CPU funziona in modalità kernel, esegue principalmente routine di servizio di interrupt. (ISR) Quando si verifica un interrupt, il lavoro in modalità utente viene sospeso su quel processore e la CPU esegue l'ISR registrato per quell'interrupt. Se si riscontra che la CPU impiega una quantità eccessiva di tempo su questi interrupt, ciò indica di solito un driver di dispositivo difettoso che deve essere aggiornato.

Ciò che mi infastidisce (nessun gioco di parole) su questo scenario è che sembra che qualsiasi thread del kernel che sta facendo questo sembra essere affine a quell'unico core. Mi chiedo perché il dispatcher sembra solo programmare il thread per essere eseguito su quello che sembra un nucleo arbitrario. Quindi ho la sensazione che dobbiamo trovare chiunque abbia scritto questo driver di dispositivo e mostrare loro come fare DPC con thread, e non impostare esplicitamente un'affinità sui thread del kernel, ecc.

Mostra la colonna "Tempo CPU" nella scheda "Dettagli" in "Task Manager" e cerca un processo con un conteggio del tempo della CPU in costante aumento. Questo è il tuo processo incuneato. Dovrebbe utilizzare costantemente circa il 4,17% di CPU.

Sembra essere tutto il tempo del kernel, potrebbero essere interruzioni, potrebbero essere gestite solo da una singola CPU.

Cercare un processo con un utilizzo costante della CPU del ~ 4% (= 1/24 della CPU disponibile totale). Dovrebbe essere quello che occupa continuamente una singola CPU.