Serveur Linux qui rame ? Cpu qui chauffe !
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 :
Et pour le lancer :
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 :
Puis nous allons l’utiliser très simplement :
Ce qui donne à l'écran :
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 :
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 :
Ce qui donne :
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 :
Puis je les décompresse tous :
Et j'effectue un petit comptage, afin de déterminer depuis quand nous avons ce message d’erreur :
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 :
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 :
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 :
1 |
apt-get install htop |
1 |
htop |
1 |
apt-get install stress |
1 |
stress --cpu 12 |
1 |
stress: info: [16984] dispatching hogs: 12 cpu, 0 io, 0 vm, 0 hdd |
1 |
Mpstat 1 |
1 2 |
cd /var/log/ tail -1000 syslog |
1 2 3 4 |
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) |
1 2 3 4 5 6 7 8 9 10 11 |
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 |
1 2 |
root@ns3027055:/var/log# cd ~/syslog_histo root@ns3027055:~/syslog_histo# gunzip *.gz |
1 |
grep -c "cpu clock throttled" * |
1 2 3 4 5 6 7 8 |
syslog:551 syslog.1:1052 syslog.2:922 syslog.3:542 syslog.4:0 syslog.5:0 syslog.6:0 syslog.7:0 |
1 |
apt-get install lm-sensors |
1 |
sensors |
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 |