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%:
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:
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
la source
la source
Réponses:
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:
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.
et arrêter l'enregistrement avec
xperf -d logfile.etlXperf 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.
la source
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.
la source
Cela semble être tout le temps du noyau, peut être des interruptions, elles ne peuvent être gérées que par un seul processeur.
la source
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.
la source