Les mystères du hardware (WPA à la rescousse)

Lorsque l'on est  confronté à des problèmes de performance, le premier reflexe est souvent d'incriminer les produits liés à la sécurité (antivirus,...) qui peuvent être très intrusifs. On ne pense pas troujours au hardware. Lui aussi contient du code et est donc sujet aux bugs. Malheureusement ceux-ci sont diffciles à diagnostiquer!

Dans ce post, nous allons l'illustrer avec un exemple et utiliser WPA (Windows Performance Analser) pour montrer que sur ce serveur tout ne tournait pas comme une horloge bien cadencée. Il va nous permettre d'illustrer et d'aborder avec un cas simple, l'utilisation de la vue CPU Usage (Precise) qui est très utile dans l'analyse de problème de performance..

Problème:

Aléatoirement , sur des  serveurs "Remote Desktop Server" Windows 2008 R2 de même type,  toutes les operations  devenaient plus lentes. Un redémarage du serveur était necessaire pour rétablir le bon niveau de services.

Les premières investigations ne montrent pas de problème mémoire ou d'Entrée/Sortie. Une enquête minitieuse auprès des utilisateurs connectés permet de constater que le problème est lié à Excel. Certains calculs en mode multi-threading entrainent par la suite une degradation des performances (ce problème se produit indépendemment de la charge sur le serveur) avec toutes les applications.

Comment Excel peut-il changer le comportement du système ? Comment peut-il modifier les politiques de "Scheduling" du système ? ...

L'application des "recettes" habituelles n'améliore pas la situation:

• • Changement des politiques d'économie d'énergie sur le serveur: Slow Performance on Windows Server 2008 R2 when using the “Balanced” Power Plan ( https://support.microsoft.com/kb/2207548/EN-US)
  • Désactivation de l'hyper-threading
  • Desactivation des C-States (via le BIOS ou via le registre : HKLM\System\CurrentControlSet\Control\Processor\Capabilities=0x0007e066
  • Changement des parmètres NUMA dans le BIOS

Finalement, nous décidons de prendre une trace WPA avant et après l'arrivée du problème avec le scenario le plus simple possible : un simple programme "mono-thread" de calcul de nombre premiers (sans Entrée/Sortie, sans accès mémoire).

Le graphe "CPU Precise" permet de voir avec precision l'éxécution des threads d'un processus (quand ils sont planifiés, s'ils se metttent dans des états d'attente, le thread qui les libèrent , le CPU sur lequel il est planifié, le temps CPU passé ,...)

Nous constatons :

• le thread est toujours planifié sur le même CPU (colonne CPU)
• que le thread ne perd pas de temps dans des états d'attente ( colonne Wait )
• que le thread est toujours planifié lorsqu'il le souhaite (colonne Ready)

mais :

• Le temps CPU consommé par le thread (NewSwitchInTime) passe de 4 secondes à 32 secondes pour le même traitement!

Il y a définitivement quelque chose d'anormal. et que le problème de depend pas de Windows (nous avions devalidé toutes les économies d'énergie possibles au niveau de  Windows  ) et que nous pouvons suspecter un problème materiel.

L'utilaire CPU-Z nous confirme ceci et montre que lors de l'éxécution de la feuille de calcul, la fréquence et le voltage du processeur ont brutalement chutés.

FInalement, une mise à jour du BIOS a permis de résoudre e problème.

Tips pour comprendre la vue "CPU Usage (Precise)" :

La terminologie utilisée dans les libellés des colonnes est la suivante :

- New : répresente le process,thread qui utilise le processeur  

- Reading : réprésente le process, thread qui  libère le thread  de son état d'attente:

- Wait : le temps passé à attendre un (exemple fin d'une I/O ou un évenement)

- Ready: le temps où le thread est prêt à s'exécuter. Il attend juste que le système lui "accorde" le CPU

- NewInSwitchTime: le temps CPU consommé par le thread