Rebondissement dans l’affaire du serveur plus lent qu’un changement dans la législation !
Si vous suivez mes publications, vous avez sans doute vu passer
mon article concernant une trop grand consommation CPU par le processus Mysqld ? Après investigations, nous pensions avoir résolu notre problème de performance en incriminant, à tort, les développeurs.
Mais cette affaire était loin d’être résolu.
Malgré moult corrections et optimisations, les performances des serveurs étaient toujours catastrophiques, et cela devenait même de pire en pire ; avec l’impression d’un serveur fonctionnant sur 3 pattes…
L’analyse de la courbe de la consommation CPU sur le mois permet de se dire qu’il y a un souci depuis quelques jours. Le problème semble être arrivé de façon soudaine et brutale :
Pour le coup, je reprends la place de l’administrateur et me lance dans des investigations plus poussées. D’abords, jetons à nouveau un coup d’œil au processus en cours.
Sous Linux, il est possible d’avoir un aperçu sur l’état des différents processus en cours grâce à la commande «
top » mais il existe l’utilitaire
htop permettant de rechercher, tuer les processus et mêmes les trier selon un critère et tout plein d’autres choses.
Pour accéder à cete outil, il faut l’installer et, comme toujours, installer un programme sous Linux est un jeu d’enfant :
apt-get install htop
Et pour le lancer :
htop
Mon serveur dispose de 12 cpu, htop permet de voir la consommation cpu de chaque CPU et la mémoire globale :
Dans mon cas, je constate immédiatement que mes CPU… ne font rien !
Pourquoi, dans ce cas, le serveur est-il si lent ?
Pour avoir une réponse, pourquoi ne pas lui faire subir un petit benchmark ? Cela permettra d’avoir les idées claires et d’avoir une idée de la source du problème… Je vais utiliser l’outil stress afin de m’assurer que mes 12 processeurs répondent à l’appel !
Première étape, installer l’outil :
apt-get install stress
Puis nous allons l’utiliser très simplement :
stress --cpu 12
Ce qui donne à l'écran :
stress: info: [16984] dispatching hogs: 12 cpu, 0 io, 0 vm, 0 hdd
On laisse tourner, et dans une nouvelle session, on fait un petit coup de htop pour voir ce qu’il se passe.
Pas de jaloux, chaque CPU se prend sa petite charge :
On kill le process stress et regardons un peu la tendance de l’occupation CPU :
Mpstat 1
Bon, à ce stade c'est l'incompréhension. La moindre commande est lente, la moindre requête SQL prend une éternité et même lorsque apache ouvre une page l'occupation d'un cpu monte à 100% !
Allons voir les logs systèmes :
cd /var/log/
tail -1000 syslog
Ce qui donne :
May 18 19:48:19 ns3027055 kernel: [32864.330732] CPU0: Package temperature above threshold, cpu clock throttled (total events = 3798294)
May 18 19:48:19 ns3027055 kernel: [32864.330742] CPU11: Package temperature above threshold, cpu clock throttled (total events = 3798297)
May 18 19:48:19 ns3027055 kernel: [32864.330745] CPU5: Package temperature above threshold, cpu clock throttled (total events = 3798296)
May 18 19:48:19 ns3027055 kernel: [32864.330839] CPU2: Package temperature above threshold, cpu clock throttled (total events = 3798301)
Ok... J'aurai du commencer par là, regarder les logs au lieu de faire le malin avec mes recherches et tests "stress".
Bref... Pour en revenir au message d'erreur dans syslog, vous êtes d’accord avec moi que ce genre de message ne fait pas plaisir ?
Regardons depuis quand nous avons ce problème de chaleur :
Je vais d’abord copier mes fichiers syslog dans un répertoire temporaire :
ls -lrt syslog*
-rw-r----- 1 root adm 16896 mai 12 06:25 syslog.7.gz
-rw-r----- 1 root adm 16454 mai 13 06:25 syslog.6.gz
-rw-r----- 1 root adm 216763 mai 14 06:25 syslog.5
-rw-r----- 1 root adm 18033 mai 15 06:25 syslog.4.gz
-rw-r----- 1 root adm 27989 mai 16 06:25 syslog.3.gz
-rw-r----- 1 root adm 32908 mai 17 06:26 syslog.2.gz
-rw-r----- 1 root adm 693433 mai 18 06:25 syslog.1
-rw-r----- 1 root adm 530230 mai 18 20:09 syslog
mkdir ~/syslog_histo
cp syslog* ~/syslog_histo
Puis je les décompresse tous :
root@ns3027055:/var/log# cd ~/syslog_histo
root@ns3027055:~/syslog_histo# gunzip *.gz
Et j'effectue un petit comptage, afin de déterminer depuis quand nous avons ce message d’erreur :
grep -c "cpu clock throttled" *
syslog:551
syslog.1:1052
syslog.2:922
syslog.3:542
syslog.4:0
syslog.5:0
syslog.6:0
syslog.7:0
Donc, le problème apparaît dans le fichier syslog.3 en date du 16 mai.
Ce qui est cohérent avec ma courbe de consommation CPU !
Dernière vérification, nous allons en avoir le cœur net en utilisant l’outil sensors :
apt-get install lm-sensors
Lm-sensors est un paquet de surveillance de l'état du matériel, un super outil pour lire les capteurs de température, tension et ventilateur :
sensors
Ce qui donne :
Pas besoin de vous faire un dessin... C'est chaud sur la carte-mère !
Il y aurait-il un incendie dans le data center ?
Il ne reste plus qu'un chose à faire maintenant... Ouvrir un ticket incident auprès d'OVH, leur indiquer les conclusions de mes recherches et attendre la confirmation de l'incident.
Et effectivement, mon diagnostic fut le bon. Le système de refroidissement était HS sur mon serveur.
Pas de chance.
Il a été changé rapidement et tout est rentré dans l'ordre !
Rappel des outils vue dans cet article :
| Nom de l'outil |
Description |
Installation |
| htop |
Moniteur système pour Linux similaire à top. |
apt-get install htop |
| stress |
Application permettant de générer des processus et entraînant une consommation de la CPU grâce à l’exécution de la commande sqrt |
apt-get install stress |
| mpstat |
Outils ressemblant à mesurant la consommation CPU |
apt-get install sysstat |
| sensors |
Surveillance de l’état du matériel |
apt-get install lm-sensors |
