Ce billet va détailler de façon précise quels compteurs de l’analyseur de performances doivent être monitorés afin de diagnostiquer un serveur d’un point de vue stockage, processeur, mémoire, etc… pour déceler un problème ou un éventuel goulot d’étranglement, par exemple.

Analyser les performances du stockage

• % d’inactivité => désigne la charge de travail => une valeur en-dessous de 20 % indique une surcharge probable.
• E/S partagées/s => désigne le taux de requête disque physique découpée en plusieurs requêtes pendant une intervalle. Il convient d’appliquer la formule suivante:
  • ( E/S partagées/s) / Transfert disques/s) * 100 => une valeur au-delà de 20 % indique une fragmentation  importante
• Lecture disque/s et Ecriture disque/s => désigne le nombre IOPS
• Longueur moyenne de file d’attente du disque => désigne le nombre de requête I/O => la valeur doit être inférieure à 2 sinon il existe un goulot d’étranglement => rajouter des disques à la pile RAID (si la valeur est supérieure au nombre de piles plus deux, cela signifie que le disque lui-même peut constituer le goulot d’étranglement)
• Moyenne disque s/écriture et Moyenne disque s/lecture et Moyenne disque s/transfert => Ce compteur mesure, en secondes, le temps moyen nécessaire pour lire les données du disque (temps d’accès) => la valeur doit être comprise entre 0 et 25 ms, maximum 10ms pour un serveur SQL. Si le chiffre est supérieur à 25 millisecondes (ms), cela signifie que le système de disque a des problèmes de latence lorsqu’il lit du disque.
• Octet disque/s => désigne le débit
• Mémoire\Octets du cache => Ce compteur indique la quantité de mémoire utilisée pour le cache du système de fichiers. Il peut y avoir un goulot d’étranglement de disque si cette valeur est supérieure à 200 Mo
• Pourcentage du temps de lecture/écriture du disque => désigne le Pattern I/O
• Transfert disque/s => désigne la charge IOPS

Analyser les performances de la mémoire

• % temps processeur => désigne la charge du processeur => une valeur au-delà de 80 % nécessite une surveillance accrue => un CPU peut être sollicité (dans la cadre d’une virtualisation par exemple) à hauteur de 75 à 90 % mais en surveillant bien entendu l’évolution
• Longueur de la file du processeur => désigne la file d’attente des threads du processeur => une valeur entre 5 et 10 indique une charge importante et au-delà une surcharge/saturation des performances processeur
• Pages/s => désigne la mémoire paginée transférée de la mémoire vive vers le système disque. Il convient d’appliquer la formule suivante:
  • Pages/s / Transfert disque/s => une valeur au-delà de 50% nécessite l’ajout de mémoire dans le système car le système consomme de la « puissance » disque uniquement pour la pagination (mesure la vitesse à laquelle les pages sont lues du disque ou écrites sur disque pour corriger les défauts des pages matérielles. Si la valeur est supérieure à 1 000, suite à une pagination excessive, il peut y avoir une fuite de mémoire)
• Mégaoctets disponibles => désigne la mémoire vive disponible immédiatement (si cette valeur est inférieure à 5 % de la mémoire RAM physique totale, cela signifie qu’il y a une insuffisance de mémoire, ce qui risque d’accroître l’activité de pagination)
• Entrées libres en table des pages système => ce compteur indique le nombre d’entrées de la table de pagination qui ne sont pas actuellement utilisées par le système. Si ce nombre est inférieur à 5 000, il est fort possible que vous ayez une fuite de mémoire
• Octets validés => désigne le volume mémoire alloué réservé. Il convient d’appliquer la formule suivante:
  • Octets validés / Mémoire installée => un ratio supérieur à 1.5 nécessitera un ajout de mémoire vive et une valeur de 1 indique qu’il convient de surveiller le système car le montant de la mémoire virtuelle « équivaut » à la mémoire vive installée (Ce compteur mesure le rapport octets validés/limite de mémoire dédiée soit la quantité de mémoire virtuelle utilisée. Il indique une mémoire insuffisante si le chiffre est supérieur à 80 %)

Analyser les performances du processeur

• % temps processeur => mesure le pourcentage de temps que le processeur passe à exécuter un thread actif. Si le pourcentage est supérieur à 85 %, cela signifie que le processeur est surchargé et que le serveur peut nécessiter un processeur plus rapide
• % temps utilisateur => mesure le pourcentage de temps que le processeur passe en mode utilisateur. Si cette valeur est élevée, cela signifie que le serveur est occupé par l’application. Une solution possible consiste à optimiser l’application qui utilise trop les ressources du processeur
• % temps d’interruption => mesure le temps que le processeur passe à recevoir et à traiter des interruptions matérielles durant des intervalles d’échantillonnage spécifiques. Ce compteur indique la possibilité d’un problème de matériel si la valeur est supérieure à 15 %
• Longueur de la file d’attente du processeur => indique le nombre de threads existant dans la file d’attente du processeur. Le serveur ne reçoit pas suffisamment de puissance processeur si la valeur est plus de deux fois supérieure au nombre de processeurs pendant un certain temps

Analyser les performances du réseau

• Total des octets/s => mesure la vitesse à laquelle les octets sont envoyés et reçus via chaque carte réseau, y compris les caractères de trame. Le réseau est saturé si vous découvrez que plus de 70 % de l’interface sont en utilisation. Pour une carte de 100 Mbits/s, l’interface utilisée est 8,7 Mo/s (100 Mbits/s = 100 000 Kbits/s = 12,5 Mo/s* 70 %). Dans une telle situation, vous devriez ajouter une carte réseau plus rapide ou segmenter le réseau
• Longueur de la file d’attente de sortie => mesure la longueur de la file d’attente de sortie, en paquets. Il y a saturation du réseau si la valeur est supérieure à 2. Vous pouvez résoudre ce problème en ajoutant une carte réseau plus rapide ou en segmentant le réseau

Analyser les performances processus

• Nombre de handles => mesure le nombre total de handles qui sont actuellement ouverts par un processus. Ce compteur indique la possibilité d’une fuite de handles si le nombre est supérieur à 10 000
• Nombre de threads => mesure le nombre de threads actuellement actifs dans un processus. Il peut y avoir une fuite de thread si ce nombre est supérieur à 500 entre le nombre minimum et maximum de threads
• Octets privés => indique la quantité de mémoire allouée au processus qui ne peut pas être partagée avec d’autres processus. Si la valeur est supérieure à 250 entre le nombre minimum et maximum de threads, il est possible qu’il y ait une fuite de mémoire

Je me suis basé, en plus de mon expérience 😉 , sur cet article pour rédiger ce billet.

Cédric GEORGEOT [MVP]

Je travaille actuellement en tant qu’Enterprise Architect pour le groupe CAPGEMINI. Acteur et expert communautaire reconnu depuis de nombreuses années, j’anime cette communauté autour des technologies Microsoft, modère les forums officiels Microsoft Technet et participe régulièrement aux  évènements  tels  que  les  Microsoft  Techdays/Expériences  ou  les  Microsoft  Days  en  tant  qu’Ask  The  Expert ou speaker. Je suis à l’origine de nombreuses publications dans la presse IT.
Mon implication communautaire m’a valu la reconnaissance de mes pairs et de Microsoft Corp au titre de Most Valuble Professionnal depuis plus de 9 années et suis également Microsoft P-Seller.

• TERRAFORMER: du reverse engineering IaC de vos environnements Cloud
• FinOps et Azure Graph
• Intégration SSO de Panorama avec Azure AD & AAD Application Proxy

Set your Author Custom HTML Tab Content on your Profile page