À propos des compteurs de performance
Les compteurs de performances Windows fournissent une couche d’abstraction de haut niveau avec une interface cohérente pour collecter différents types de données système telles que les statistiques d’utilisation du processeur, de la mémoire et du disque. Les administrateurs système utilisent des compteurs de performances pour le monitoring des problèmes de performances ou de comportement. Les développeurs de logiciels utilisent des compteurs de performances pour inspecter l’utilisation des ressources de leurs composants.
Important
Les compteurs de performances Windows sont optimisés pour la découverte et la collecte des données d’administration/de diagnostic. Ils ne conviennent pas à la collecte de données à haute fréquence ou au profilage des applications, car elles ne sont pas conçues pour être collectées plusieurs fois par seconde. Pour un accès aux informations système avec moins de traitement, vous pouvez préférer des API plus directes telles que Process Status Helper, GlobalMemoryStatusEx, GetSystemTimes ou GetProcessTimes. Pour le profilage, vous pouvez collecter des journaux ETW avec des données de profilage système à l’aide de tracelog.exe avec les options -critsec
, -dpcisr
, -eflag
ou -ProfileSource
. Vous pouvez également utiliser le profilage du compteur matériel.
Remarque
Ne confondez pas les compteurs de performances Windows avec l’API QueryPerformanceCounter. Les compteurs de performances Windows fournissent une abstraction de haut niveau pour de nombreux types d’informations système. La fonction QueryPerformanceCounter fournit un accès optimisé à un horodatage haute précision.
Mise en route
- Utilisez les outils de compteur de performances lorsque vous souhaitez collecter ou afficher les données de performances à partir d’un système.
- Utilisez les API de collecte des compteurs de performances lorsque vous souhaitez écrire un script ou un programme qui collecte les données de performances à partir du système local.
- Utilisez les classes de compteur de performances WMI lorsque vous souhaitez collecter des données de performances à partir d’un système local ou distant à l’aide de WMI.
- Utilisez les API du fournisseur de compteurs de performances lorsque vous souhaitez publier des données de performances à partir de votre composant logiciel.
Concepts
Le système de compteur de performances Windows est organisé en consommateurs, fournisseurs, ensembles de compteurs, compteurs, instances et valeurs de compteur.
Un consommateur est un composant logiciel qui utilise des données de performances. Windows inclut plusieurs outils intégrés qui utilisent des données de performances. Il s’agit notamment du Gestionnaire des tâches, du Moniteur de ressource, de l’Analyseur de performances, de typeperf.exe, de logman.exe et de relog.exe. Les développeurs peuvent écrire des scripts et des applications qui accèdent aux compteurs de performances via les API de compteur de performances.
Un fournisseur est un composant logiciel qui génère et publie des données de performances. Un fournisseur publie des données pour un ou plusieurs ensembles de compteurs. Par exemple, un système de base de données peut s’inscrire en tant que fournisseur de données de performances.
- Un fournisseur V1 est un composant logiciel qui publie des données de performances via une DLL de performances qui s’exécute dans le processus du consommateur. Un fournisseur V1 est installé sur un système via un fichier
.ini
. L’architecture du fournisseur V1 est déconseillée. Les nouveaux fournisseurs doivent utiliser l’architecture du fournisseur V2. - Un fournisseur V2 est un composant logiciel qui publie des données de performances via les API du fournisseur de compteurs de performances. Un fournisseur V2 est installé sur un système via un fichier (manifeste XML)
.man
.
Un ensemble de compteurs est un regroupement de données de performances au sein d’un fournisseur. Un ensemble de compteurs a un nom et un ou plusieurs compteurs. La collecte des données à partir d’un compteur retourne un certain nombre d’instances. Dans certaines API Windows, les compteurs sont appelés objets de performances. Par exemple, un fournisseur de données de performances pour un système de base de données peut fournir un compteur pour les statistiques par base de données.
Un compteur est la définition d’un seul élément de données de performances. Un compteur a un nom et un type. Par exemple, un ensemble de compteurs « statistiques par base de données » peut contenir un compteur nommé « transactions par seconde » avec le type PERF_COUNTER_COUNTER
.
Une instance est une entité sur laquelle les données de performances sont signalées. Une instance a un nom (chaîne) et une ou plusieurs valeurs de compteur. Par exemple, un compteur « par base de données » peut contenir une instance par base de données. Le nom de l’instance est le nom de la base de données, et chaque instance contient des valeurs de compteur pour les compteurs « transactions par seconde », « utilisation de la mémoire » et « utilisation du disque ».
Une valeur de compteur est la valeur d’un seul élément de données de compteur de performances. Une valeur de compteur est un entier non signé, 32 bits ou 64 bits en fonction du type du compteur correspondant. Lorsque vous parlez d’une instance, une valeur de compteur peut parfois être appelée compteur ou valeur.
Conseil
Il peut être utile de faire un parallèle entre la terminologie des compteurs de performances et celle, plus familière, des feuilles de calcul. Un ensemble de compteurs est semblable à un tableau. Un compteur est semblable à une colonne. Une instance est semblable à une ligne. Une valeur de compteur est semblable à une cellule du tableau.
Les ensembles de compteurs à instance unique contiennent toujours des données pour une seule instance. Cela est courant pour les ensembles de compteurs qui signalent des statistiques globales dans le système. Par exemple, Windows dispose d’un ensemble de compteurs à instance unique intégré nommé « Mémoire » qui signale l’utilisation globale de la mémoire.
Les ensembles de compteurs multi-instances contiennent des données pour un nombre variable d’instances. Cela est courant pour les compteurs qui signalent des entités au sein du système. Par exemple, Windows dispose d’un ensemble de compteurs à plusieurs instances intégré nommé « Informations sur le processeur » qui signale une instance pour chaque processeur installé.
Les consommateurs collectent et enregistrent régulièrement les données à partir de l’ensemble de compteurs d’un fournisseur. Par exemple, le consommateur peut collecter des données une fois par seconde ou une fois par minute. Les données collectées sont appelées un échantillon. Un échantillon se compose d’horodatages et des données des instances du compteur. Les données de chaque instance incluent le nom de l’instance (sous forme de chaîne) et un ensemble de valeurs de compteur (sous forme d’entiers, une valeur pour chaque compteur dans l’ensemble de compteurs).
En temps normal, les noms d’instances doivent être uniques dans un échantillon, c’est-à-dire qu’un fournisseur ne doit pas retourner deux instances portant le même nom au sein d’un même échantillon. Certains fournisseurs plus anciens ne suivent pas cette règle, de sorte que les consommateurs doivent être en mesure de tolérer des noms d’instance non uniques. Les noms d’instance ne respectent pas la casse. Les instances ne doivent donc pas avoir de noms qui diffèrent uniquement au niveau de la casse.
Remarque
Pour des raisons de compatibilité descendante, l’ensemble de compteurs « Processus » retourne des noms d’instances non uniques en fonction du nom de fichier EXE. Cela peut entraîner des résultats déroutants, en particulier lorsqu’un processus avec un nom non unique démarre ou s’arrête, car cela entraîne généralement des problèmes de données en raison d’une correspondance incorrecte des noms d’instances entre les échantillons. Les consommateurs de l’ensemble de compteurs « Processus » doivent être en mesure de tolérer ces noms d’instance non uniques et les problèmes de données résultants.
Dans Windows 11 et versions ultérieures, vous pouvez utiliser l’ensemble de compteurs Process V2
pour éviter ce problème.
Les noms d’instances doivent être stables entre les échantillons, c’est-à-dire qu’un fournisseur doit utiliser le même nom d’instance pour la même entité chaque fois que l’ensemble de compteurs est collecté.
Chaque compteur a un type. Le type de compteur indique le type de la valeur brute du compteur (entier 32 bits non signé ou entier 64 bits non signé). Le type de compteur indique également ce que représente la valeur brute du compteur, qui détermine la façon dont la valeur brute doit être traitée pour générer des statistiques utiles.
Bien que certains types de compteurs soient simples et ont une valeur brute directement utile, de nombreux types de compteurs nécessitent un traitement supplémentaire pour créer une valeur mise en forme utile. Pour produire la valeur mise en forme, certains types de compteurs nécessitent des valeurs brutes issues de deux échantillons, certains types de compteurs nécessitent des horodatages, tandis que certains types de compteurs nécessitent des valeurs brutes provenant de plusieurs compteurs. Par exemple :
PERF_COUNTER_LARGE_RAWCOUNT
est une valeur brute 64 bits qui ne nécessite aucun traitement pour être utile. Il est approprié pour les valeurs à un point dans le temps, telles que « Octets de mémoire en cours d’utilisation ».PERF_COUNTER_RAWCOUNT_HEX
est une valeur brute 32 bits qui nécessite uniquement une mise en forme hexadécimale simple pour être utile. Il est approprié pour des informations ponctuelles ou d’identification telles que « Indicateurs » ou « Adresse de base ».PERF_COUNTER_BULK_COUNT
est une valeur brute 64 bits qui indique un nombre d’événements et est utilisée pour calculer la fréquence à laquelle les événements se produisent. Pour être utile, ce type de compteur nécessite deux échantillons séparés dans le temps. La valeur mise en forme est la fréquence de l’événement, c’est-à-dire le nombre de fois où l’événement s’est produit par seconde sur l’intervalle entre les deux échantillons. Compte tenu de deux échantillons,s0
ets1
, la valeur mise en forme (fréquence de l’événement) serait calculée comme(s1.EventCount - s0.EventCount)/(s1.TimestampInSeconds - s0.TimestampInSeconds)
.
Les fournisseurs sont censés se comporter comme s’ils étaient sans état, c’est-à-dire que la collecte de données à partir d’un ensemble de compteurs ne doit pas affecter visiblement l’état du fournisseur. Par exemple, un fournisseur ne doit pas réinitialiser les valeurs de compteur sur 0 lorsqu’un ensemble de compteurs est collecté et il ne doit pas utiliser l’horodatage d’une collecte précédente pour ajuster les valeurs de la collecte active. Au lieu de cela, il doit fournir des valeurs de compteur brutes simples avec des types précis afin que le consommateur puisse calculer des statistiques utiles en fonction des valeurs brutes et de leurs horodatages.
Architecture de l’API de performances
Les consommateurs de compteurs de performances sont les suivants :
- Applications fournies par Microsoft, telles que le Gestionnaire des tâches, le Moniteur de ressource, l’Analyseur de performances et typeperf.exe.
- Surfaces d’API de haut niveau fournies par Microsoft qui exposent des données de compteur de performances telles que les classes de performance WMI.
- Vos propres applications ou scripts qui utilisent des API de consommateur de compteur de performances.
La plupart des consommateurs de compteurs de performances utilisent des API à partir de PDH.dll pour collecter des données de performances. PDH gère de nombreux aspects complexes de la collecte de compteurs de performances tels que l’analyse des requêtes, la mise en correspondance d’instances sur plusieurs échantillons et le calcul des valeurs mises en forme à partir des données de compteur brutes. L’implémentation PDH utilise les API de Registre lors de la consommation de données issues d’un fournisseur V1 et utilise les API de consommateur V2 lors de l’utilisation de données provenant d’un fournisseur V2.
Certains consommateurs de compteurs de performances plus anciens utilisent les API de Registre pour collecter des données de performances à partir de la clé de Registre HKEY_PERFORMANCE_DATA
spéciale. Cela n’est pas recommandé pour le nouveau code, car le traitement des données à partir du Registre est complexe et sujette aux erreurs. L’implémentation de l’API de Registre prend directement en charge la collecte de données à partir de fournisseurs V1. Elle prend indirectement en charge la collecte de données à partir de fournisseurs V2 via une couche de traduction qui utilise les API de consommateur V2.
Certains consommateurs de compteurs de performances utilisent les fonctions de consommateur PerfLib V2 pour accéder directement aux données des fournisseurs V2. Cela est plus complexe que la consommation de données à l’aide des API PDH, mais cette approche peut être utile si les API PDH ne peuvent pas être utilisées en raison de problèmes de performances ou de dépendances. L’implémentation de PerfLib V2 prend directement en charge la collecte de données à partir de fournisseurs V2. Elle ne prend pas en charge la collecte de données auprès de fournisseurs V1.
Remarque
Windows OneCore n’inclut pas PDH.dll ni la prise en charge de la consommation des données de compteur de performances via les API de Registre. Les consommateurs s’exécutant sur OneCore doivent utiliser les fonctions Consommateur PerfLib V2.
Les fournisseurs V1 sont implémentés en tant que DLL de fournisseur chargée dans le processus consommateur. L’implémentation de l’API de Registre gère le chargement de la DLL du fournisseur, l’appel dans la DLL pour collecter les données de performances et décharger la DLL selon les besoins. La DLL du fournisseur est chargée de collecter les données de performances selon les besoins, par exemple à l’aide d’API Windows normales, de RPC, de canaux nommés, de mémoire partagée ou d’autres mécanismes de communication interprocessus.
Les fournisseurs V2 sont implémentés en tant que programme en mode utilisateur (souvent un service Windows) ou un pilote en mode noyau. En règle générale, le code du fournisseur de données de performances est intégré directement à un composant existant (c’est-à-dire que le pilote ou le service fournit des statistiques sur lui-même). L’implémentation de PerfLib V2 gère les demandes et les réponses via l’extension de noyau PCW.sys. Le fournisseur n’a généralement pas besoin d’implémenter de communication interprocessus pour fournir les données de performances.
Remarque
Les API et outils du compteur de performances Windows incluent une prise en charge limitée de l’accès aux compteurs de performances à partir d’autres ordinateurs via le Registre à distance (pour les fournisseurs V1) et RPC (pour les fournisseurs V2). Cette prise en charge est souvent difficile à utiliser en termes de contrôles d’authentification (les outils et les API peuvent uniquement s’authentifier en tant qu’utilisateur actuel) ainsi qu’en termes de configuration du système (les points de terminaison et services nécessaires sont désactivés par défaut). Dans de nombreux cas, il est préférable d’accéder aux compteurs de performances des systèmes distants via WMI plutôt que via la prise en charge intégrée de l’accès à distance.
Public de développeurs
Les compteurs de performances sont souvent utilisés par les administrateurs pour identifier les problèmes de performances ou le comportement anormal des systèmes, par les développeurs pour étudier l’utilisation des ressources des composants logiciels et par des utilisateurs individuels pour comprendre comment les programmes se comportent sur leur système. L’utilisation peut se produire via des outils GUI tels que le Gestionnaire des tâches ou l’Analyseur de performances, des outils en ligne de commande tels que typeperf.exe ou logman.exe, à l’aide de scripts via WMI et PowerShell, ou via des API C/C++ et .NET.
Les fournisseurs de compteurs de performances sont généralement implémentés en tant que pilotes en mode noyau ou services en mode utilisateur. Les fournisseurs de compteurs de performances sont généralement écrits en C ou C++.
Exigences d'exécution
Pour plus d’informations sur les exigences d’exécution pour un élément de programmation particulier, consultez la section Conditions requises de la page de référence de cet élément.
Pour obtenir l’historique des versions, consultez Nouveautés.