- 11/16/2020
- 3 minutes à lire
-
-
D -
v
-
Cet article fournit une solution de contournement pour le problème d’utilisation élevée du CPU par le processus WmiPrvSE.exe à intervalles réguliers.
Version du produit d’origine : Windows Server 2019, Windows Server 2016, Windows Server 2012 R2, Window 10 – toutes les éditions
Numéro de KB original : 4483874
Symptômes
Lorsque vous utilisez un ordinateur basé sur Windows, vous remarquez que l’hôte fournisseur de Windows Management Instrumentation (WMI) (WmiPrvSE.exe) utilise une capacité CPU élevée (près de 100 pour cent) pendant plusieurs minutes toutes les 15 à 20 minutes.
Lorsque le problème se produit, utilisez le Gestionnaire des tâches pour identifier l’identifiant de processus (PID) du processus WmiPrvSE.exe qui consomme beaucoup de CPU. Ensuite, ouvrez une invite de commande élevée et exécutez la commande suivante :
tasklist /m wmiperfclass.dllLa liste des processus WmiPrvSE.exe qui ont ce module chargé s’affiche. Habituellement, un seul processus est répertorié. Cependant, si vous avez des clients 32 bits et 64 bits, vous pouvez voir deux processus. Voici un exemple de sortie:
Image Name PID Modules
========== ======== ==========================
WmiPrvSE.exe 2140 WmiPerfClass.dll
Si le PID du processus listé correspond à celui que vous avez trouvé dans le Gestionnaire des tâches, il est probable que vous rencontriez le problème décrit dans cet article.
Cause
Ce problème peut être causé par l’un des facteurs suivants.
Un ou plusieurs processus utilisent un nombre élevé de handles
Tous les handles sont stockés dans la structure du noyau \BaseNamedObjects. Le fournisseur WMIPerfClass doit analyser cette structure lors de la création de la classe de performance qui est liée aux objets Job.
Si cette structure est gonflée en raison du nombre élevé de handles, l’opération aura une utilisation élevée du CPU et prendra plus de temps que la normale.
Vous pouvez vous attendre à un impact pour cette condition lorsqu’un processus utilise plus d’environ 30 000 handles, ou que le nombre total de handles sur le système dépasse 50 000.
Une mise à jour qui est publiée en mars 2020 pour les versions du système d’exploitation prises en charge comprend une certaine optimisation des performances et traite certaines variantes de ce problème. Reportez-vous à l’historique des mises à jour Windows pour plus d’informations sur la mise à jour qui s’applique à votre version de Windows.
Un ou plusieurs processus en cours d’exécution sur le système utilisent beaucoup de mémoire
Cela affecte la création des classes de performance de processus car la zone de mémoire de chaque processus en cours d’exécution devra être interrogée. La mémoire utilisée par le processus peut être fragmentée, ce qui rend l’opération plus gourmande en ressources. Cela se produit parce que WMIPerfClass interroge également les compteurs de performance « Costly ».
Vous pouvez vérifier si les compteurs de performance Costly sont activés en exécutant la commande PowerShell suivante :
(gwmi -query 'select * from meta_class').Name | ? { $_ -match "costly"} Si la commande renvoie des résultats, cela indique les compteurs de performance Costly qui sont activés. Par exemple :
Win32_PerfFormattedData_PerfProc_FullImage_Costly
Win32_PerfRawData_PerfProc_FullImage_Costly
Win32_PerfFormattedData_PerfProc_Image_Costly
Win32_PerfRawData_PerfProc_Image_Costly
Win32_PerfFormattedData_PerfProc_ProcessAddressSpace_Costly
Win32_PerfRawData_PerfProc_ProcessAddressSpace_Costly
Win32_PerfFormattedData_PerfProc_ThreadDetails_Costly
Win32_PerfRawData_PerfProc_ThreadDetails_Costly
Workaround
Pour résoudre le problème, identifiez le processus qui utilise un grand nombre de handles ou une grande quantité de mémoire.Le processus peut avoir une fuite de mémoire ou un problème de fuite de handle. Comme solution de contournement, redémarrez le processus.
Par défaut, si vous utilisez Windows Server 2016 ou une version ultérieure de Windows, les compteurs de performance coûteux sont désactivés à partir des mises à jour cumulatives suivantes :
- Windows Server 2016 / Windows 10 version 1607 (RS1)
18 octobre 2018-KB4462928 (OS Build 14393.2580) - Windows 10 version 1703 (RS2)
24 juillet 2018-KB4338827 (OS Build 15063.1235) - Windows 10 version 1709 (RS3)
24 juillet 2018-KB4338817 (OS Build 16299.579) - Windows 10 version 1803 (RS4)
16 juillet 2018-KB4345421 (OS Build 17134.167)
Note
Après l’installation de la mise à jour cumulative, si vous avez besoin des classes qui sont liées aux compteurs de performance Costly, définissez la valeur Enable Costly Providers à 1 (DWORD) sous la sous-clé de registre suivante pour les rendre à nouveau disponibles :
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Wbem
La mise à jour cumulative n’affectera pas le comportement lorsqu’un processus utilise un grand nombre de handles.
Ce problème se produit lorsqu’un client interroge les classes de performance. Il s’agit généralement d’une application de surveillance.
Comme solution de contournement, vous pouvez également désactiver l’application de surveillance pour empêcher la création des classes de performance.
Plus d’informations
WMI fournit plusieurs classes de performance. Pour plus d’informations, voir Classes de compteurs de performance.
Ces classes sont créées dynamiquement en fonction des compteurs de performance disponibles sur le système. Toutes les classes sont créées en même temps, pas seulement les classes qui sont interrogées.
WMIPerfClass est le module qui gère la création de ces classes lorsque le client WMI interroge l’une d’entre elles ou énumère les classes disponibles.
Ces classes de performance sont stockées dans un cache qui est invalidé après 15 à 20 minutes. Dès que le cache est invalidé, les classes de performance doivent être créées à nouveau si un client les demande.
Créer les classes de performance signifie que le module WMIPerfClass.dll devra être chargé à l’intérieur d’un processus WmiPrvSE.exe et que le code associé devra être exécuté.