Pourquoi 1 de mes 24 CPU est-il indexé à 100%?

12

J'ai un système HP ProLiant DL380 G7 utilisant 2 processeurs 6 cœurs, avec Hyper-threading activé, pour un total de 24 processeurs logiques (comme vu par Windows).

Lors de l'exécution de notre application, l'utilisation totale du processeur du système est bonne, mais l'un des 24 CUP est indexé à 100%: entrez la description de l'image ici

Modifier: Il s'agit des données PerfMon pour le processus système pendant cette période et pour le processeur avec une utilisation élevée: entrez la description de l'image ici

Est-ce normal? Sinon, existe-t-il un moyen d'identifier le ou les processus qui utilisent ce processeur logique? Windows PerfMon, ResMon, le Gestionnaire des tâches et l'Explorateur de processus n'ont été d'aucune aide, à part l'identification que le CPU est à 100%.

windows-server-2008-r2 performance cpu-usage

— Patrick Cuff
source

29

Je suppose qu'il est utilisé parce qu'un processus l'utilise.

— HopelessN00b

1

Vous savez que vous pouvez survoler le graphique et obtenir un indice vous indiquant quel processus prend le plus de CPU sur ce processeur?!

— Lieven Keersmaekers

Je me méfierais du delta d'interruption de 100k. Vous devriez publier une capture d'écran de la liste des processus Process Explorer où nous pouvons voir ce qu'il dit pour des choses comme le système, les DPC, les interruptions.

— Gabe

@RyanRies; notre "application" se compose de plusieurs services .Net WCF qui incluent également WebSphere MQ et certains logiciels de surveillance tiers.

— Patrick Cuff

2

Il est relativement coûteux de déplacer un processus d'un processeur à un autre, par rapport au fait qu'il soit planifié sur le même processeur, donc si un processus demande vraiment le processeur, le système d'exploitation préférera très souvent ne pas le déplacer.

— Michael Hampton

11

Comme d'autres l'ont déjà souligné, nous pouvons voir sur cette capture d'écran que le processeur qui travaille si dur passe tout son temps en mode noyau. (La couleur rouge.)

Pour exécuter Powershell en tant qu'administrateur, tapez:

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

Le processus en haut de la liste est le processus qui utilise actuellement le plus de temps CPU en mode noyau. Si ce processus n'est pas "Système", alors vous venez de découvrir quel processus en mode utilisateur est à l'origine de cette utilisation du processeur. Si le processus avec le temps de processeur privilégié le plus élevé est le système, ce que je soupçonne, c'est un peu plus compliqué.

Ouvrez Process Explorer. Facultativement, configurez votre serveur de symboles. Assurez-vous que vous exécutez avec une élévation UAC complète. Cliquez avec le bouton droit sur le "processus" du système et accédez à Propriétés. Allez ensuite dans l'onglet Threads. Triez les threads par utilisation du processeur. Le thread qui cause tout ce travail en mode noyau devrait être ici. Si vous regardez le module répertorié sous Adresse de départ, il devrait vous donner une idée de ce à quoi le travail est lié. Si c'est NDIS.sys, par exemple, c'est un pilote d'interface réseau. Si vous configurez le serveur de symboles, vous devriez voir le nom d'une fonction dans un module (à moins que le module ne soit pas Microsoft), sinon vous verrez juste un décalage numérique par rapport à l'adresse de début du module.

Vous pouvez également utiliser Xperf à partir de Windows Performance Toolkit pour profiler les interruptions, les DPC, etc.

xperf -on PROC_THREAD+LOADER+DPC+INTERRUPT

et arrêter l'enregistrement avec xperf -d logfile.etl

Xperf remplace l'ancien outil Kernrate et peut vous fournir des données extrêmement détaillées.

Lorsqu'un processeur fonctionne en mode noyau, il exécute principalement des routines de service d'interruption. (ISR) Lorsqu'une interruption se produit, le travail en mode utilisateur est suspendu sur ce processeur et le CPU exécute l'ISR enregistré pour cette interruption. Si vous trouvez que votre processeur passe trop de temps sur ces interruptions, cela indique généralement un pilote de périphérique défectueux qui doit être mis à jour.

Ce qui me dérange (sans jeu de mots) dans ce scénario, c'est qu'il semble que le thread du noyau qui fait cela semble être affinité à ce noyau. Je me demande pourquoi le répartiteur semble planifier uniquement le thread pour qu'il s'exécute sur ce noyau apparemment arbitraire. J'ai donc le sentiment que nous devons trouver la personne qui a écrit ce pilote de périphérique et leur montrer comment faire des DPC threadés, et non pas définir explicitement une affinité sur les threads du noyau, etc.

— Ryan Ries
source

IIRC, c'est un comportement assez standard pour un OS de n'utiliser qu'un seul CPU pour gérer les interruptions matérielles ...

— Massimo

1

@Massimo Cela aurait pu être le cas avec les anciens systèmes d'exploitation, mais pas plus. Chaque CPU a sa propre table de descripteurs d'interruption, et chaque processeur a son propre IRQL. Si un processeur est bloqué à un IRQL élevé pour une raison quelconque (c'est-à-dire qu'il sert déjà une interruption), il ne peut pas recevoir d'interruptions de même niveau ou de niveau inférieur et donc Windows donnera l'interruption à un autre processeur, ou le conservera jusqu'à ce qu'un CPU devienne disponible. Même les temporisateurs (un objet auparavant réputé pour ne fonctionner que sur CPU0) disposent désormais d'un algorithme de sélection de processeur.

— Ryan Ries

Mais oui, cela peut être aussi simple que d'exécuter une application héritée ou mal écrite qui est mal affinisée, et qui fait ensuite beaucoup d'appels système. Les interruptions doivent généralement commencer et se terminer sur le même processeur à partir duquel elles ont été appelées ... mais normalement, même une application à un seul thread serait "équilibrée en charge" entre les cœurs pendant son exécution ... celle-ci semble avoir une étrange affinité.

— Ryan Ries

@RyanRies; J'ai installé Windows Performance Toolkit sur le système et utilisé l'enregistreur de performances Windows; la commande xperf ci-dessus a continué à donner des erreurs. Le CPU élevé semble provenir de: Process - System; Module - ntoskrnl.exe; Thread - Phase1Initialize; Fonction - KeZeroPages. Cela ne se produit que lorsque l'application est en cours d'exécution, donc je pense (j'espère) que j'ai assez à ramener aux développeurs, mais je suis également intéressé par toutes les idées que vous pourriez avoir.

— Patrick Cuff

23

Affichez la colonne "CPU Time" sous l'onglet "Details" dans "Task Manager" et recherchez un processus avec un temps CPU qui augmente régulièrement. C'est votre processus coincé. Il devrait utiliser environ 4,17% de CPU en permanence.

— Evan Anderson
source

10

Cela semble être tout le temps du noyau, peut être des interruptions, elles ne peuvent être gérées que par un seul processeur.

— MichelZ
source

+1 - Cela ressemble à l'heure du noyau, n'est-ce pas?

— Evan Anderson

Cela apparaîtrait-il dans le cadre du processus "Système"? Les données PerfMon que nous avons collectées lors d'un test ont 100% de CPU pour le processus "Système".

— Patrick Cuff

Oui, je pense que cela relèverait du système (s'il est répertorié du tout ...)

— MichelZ

6

Cela ne pourrait-il pas aussi être un bug de pilote ou un morceau de mauvais matériel interagissant avec un pilote sans récupération d'erreur? Ou peut-être un logiciel appelant le noyau en boucle serrée.

— Zan Lynx le

1

@MichelZ, Un processus utilisateur effectuant un tas d'appels système (qui comprendrait tout type d'E / S) ressemblerait à cela.

— reirab

6

Recherchez un processus avec une utilisation constante du processeur de ~ 4% (= 1/24 du total du processeur disponible). Ce devrait être celui qui utilise continuellement un seul processeur.

— Massimo
source