Mon serveur est devenu lent : vérifier la RAM, le CPU et le disque

Si votre serveur est devenu lent, regardez trois choses : la RAM, le CPU et le disque. Connectez-vous et exécutez trois commandes : free -h pour la mémoire, top pour le processeur et df -h pour le disque. Celui qui est plein est le goulot d'étranglement. Si les trois semblent normaux, le problème se trouve généralement dans l'application elle-même.

Commencez par la charge

La charge moyenne (load average) est le nombre moyen de processus qui attendent le CPU ou le disque. Les trois premiers nombres de la sortie ci-dessous sont les moyennes des 1, 5 et 15 dernières minutes. Comparez-les à votre nombre de cœurs :

cat /proc/loadavg

nproc

Si la charge reste longtemps au-dessus du nombre de cœurs, le serveur n'arrive pas à suivre son travail.

RAM : free -h

free -h

La colonne la plus importante est available. Si elle est très petite et que la ligne Swap se remplit, vous n'avez plus de RAM. Quand la mémoire est épuisée, le noyau tue l'un des processus les plus gourmands en mémoire (l'OOM killer). Une base de données ou une application web qui se ferme toute seule en est souvent le signe. Vérifiez ainsi :

sudo dmesg -T | grep -i -E "out of memory|killed process"

CPU : top

top

Sur l'écran qui s'ouvre, la touche P trie les processus par utilisation du CPU et la touche M par utilisation de la mémoire. Appuyez sur q pour quitter. Dans la ligne CPU en haut, regardez ceci :

• us : la part des processus utilisateur. Si elle est élevée, une application dévore le CPU.
• wa : le temps passé à attendre les entrées et sorties du disque. Si elle est élevée, le problème n'est pas le CPU mais le disque.
• st : le temps « volé » au serveur virtuel, c'est-à-dire le temps que la couche de virtualisation a donné au CPU pour autre chose. Si elle reste élevée, le problème n'est peut-être pas dans votre serveur. Dans ce cas, contactez le support.

Disque : df -h

df -h

df -i

La première commande affiche l'espace utilisé et la seconde la limite du nombre de fichiers (inodes). Quand le disque est complètement plein, les bases de données et les applications ne peuvent plus écrire, et le serveur ralentit ou renvoie des erreurs. Cherchez ce qui prend la place :

sudo du -xh / --max-depth=1 2>/dev/null | sort -h | tail -n 8

Si les journaux système ont grossi, vous pouvez les réduire avec sudo journalctl --vacuum-size=200M. Si vous utilisez Docker, docker system df montre l'espace utilisé par les images et les conteneurs, et docker stats --no-stream montre le CPU et la mémoire utilisés par chaque conteneur.

Symptôme, cause probable et solution

Chez Seturack, la vitesse du disque de chaque serveur est limitée : 500 Mo/s en continu et 20 000 IOPS en lecture, et 200 Mo/s et 8 000 IOPS en écriture. Si vos valeurs dans la sortie de iostat -x 1 5 se situent à ces niveaux, c'est la charge disque qui vous ralentit. Réduisez le travail avec du cache ou étalez-le dans le temps. Si iostat est absent, installez-le avec sudo apt install -y sysstat.

Quand le swap aide-t-il ?

Le swap utilise le disque à la place de la RAM. Il permet au serveur de traverser de courts pics de mémoire sans l'OOM killer, mais il n'est pas aussi rapide que la RAM. Si si et so dans la sortie de vmstat 1 5 restent au-dessus de zéro, le serveur écrit en permanence dans le swap. La solution est la RAM, pas le swap. Si vous n'avez pas de swap (swapon --show n'affiche rien) et voulez lisser les pics, vous pouvez ajouter un fichier de swap de 2 Go. Ces commandes valent pour un système de fichiers ext4 :

sudo fallocate -l 2G /swapfile && sudo chmod 600 /swapfile

sudo mkswap /swapfile && sudo swapon /swapfile

echo '/swapfile none swap sw 0 0' | sudo tee -a /etc/fstab

Si les ressources semblent correctes

Si la RAM, le CPU et le disque semblent à l'aise, regardez le nom du processus en tête dans top :

• Si php-fpm, apache2 ou nginx est en tête, le problème vient généralement du site lui-même : un plugin lourd, l'absence de cache ou un pic soudain de visiteurs.
• Si mysqld ou mariadbd est en tête, il y a des requêtes lentes. Activez le journal des requêtes lentes de la base de données et voyez lesquelles prennent du temps.
• Si un processus que vous ne reconnaissez pas dévore sans cesse le CPU, le serveur a peut-être été compromis. Changez vos mots de passe, vérifiez les sessions ouvertes et la sortie de sudo ss -tulpn, et réinstallez le serveur avec un système vierge si nécessaire.

Quand augmenter la taille

L'ordre est le suivant : optimiser d'abord, ajouter du cache, couper le travail inutile. Si la charge reste élevée ensuite, augmentez la taille du serveur. Dans le panneau, ouvrez l'onglet Taille de votre serveur, déplacez les curseurs vers la nouvelle taille et confirmez. Après le paiement, le serveur redémarre une fois tout seul et revient à la nouvelle taille. Votre adresse IP et vos données restent les mêmes, et vous ne payez que la différence pour les jours restants. Vous pouvez augmenter séparément la RAM, les vCores et le disque, pour ne relever que ce qui manque. Augmenter la taille agrandit le disque, alors que la réduire ne le rétrécit pas. Pour le détail, consultez l'article sur le changement de taille.

Si le serveur ne répond plus du tout à cause de la charge, SSH peut ne pas se connecter. Dans ce cas, ouvrez la console VNC depuis le panneau, ou redémarrez le serveur depuis le panneau.