Le serveur est lent : par où commencer

Une procédure de diagnostic en cinq minutes : CPU, mémoire, disque, réseau — comment identifier avec quelques commandes ce qui bloque exactement et que faire ensuite.

Mis à jour le 23 août 2026

« Tout est lent » n’est pas un diagnostic. Il n’existe que quatre goulots d’étranglement : le CPU, la mémoire, le disque et le réseau. Voici un ordre de vérification qui permet d’en identifier un en cinq minutes.

Étape 1 : vue d’ensemble

uptime
free -h
df -h

Trois commandes éliminent immédiatement la moitié des pistes. Si la charge moyenne est nettement supérieure au nombre de cœurs de votre grade, il y a une file d’attente — voir Charge moyenne. Un available proche de zéro indique la mémoire. Si la partition est pleine à 100 %, inutile de chercher plus loin — lisez Espace disque saturé.

Étape 2 : quel est précisément le goulot d’étranglement

vmstat 2 5

Observez les colonnes de moyennes, toutes sauf la première ligne :

us et sy élevés, r important — limité par le CPU ;
wa élevé, b important — limité par le disque ;
si et so non nuls — un swap est en cours, ce qui signifie que la mémoire s’épuise ;
st élevé — temps consommé par l’hyperviseur, la cause est externe, contactez le support.

Étape 3 : trouver le coupable

ps aux --sort=-%cpu | head -10
ps aux --sort=-%mem | head -10
iotop -boPan 3 | head -20        # apt install iotop
ss -tn state established | wc -l

La vue en direct est plus facile à lire dans htop ou btop. Surveillez les processus à l’état D — ils attendent le disque et font grimper la charge.

Si le coupable est votre application, la question suivante la concerne : requêtes de base de données lentes, index manquant, trop de workers, boucle infinie après un déploiement. Corrélez le moment où le ralentissement a commencé avec le journal :

journalctl --since "1 hour ago" -p warning

Étape 4 : consulter l’historique

Ouvrez « Vue d’ensemble » dans le panneau /hosting/vds/m/<id> et examinez les graphiques du dernier jour et de la dernière semaine. Trois profils typiques :

un palier franchi à un moment précis — quelque chose a changé : un déploiement, une mise à jour, une nouvelle tâche cron ;
un pic régulier selon un planning — une tâche d’arrière-plan ; déplacez-la vers la nuit ou limitez-la avec nice et ionice ;
un plateau stable depuis des semaines — vous avez simplement dépassé votre grade.

Que faire du résultat

Goulot d’étranglement	Action rapide	Solution à long terme
CPU	trouver et arrêter le processus superflu	un grade avec plus de cœurs
Mémoire	limiter les workers et les tampons de la base de données, ajouter du swap	un grade avec plus de mémoire
Disque	limiter les sauvegardes avec `ionice`, réduire les journaux	un grade supérieur : le plateau augmente avec le nombre de cœurs
Réseau	limiter les téléchargements en arrière-plan avec `--bwlimit`	identifier la source du trafic

Le plateau du disque se calcule ainsi : 60 Mo/s d’écritures par cœur, pas moins de 60 et pas plus de 400, avec des lectures deux fois plus élevées. Si vous êtes constamment au plateau, le disque n’ira pas plus vite sans changer de grade — voir Benchmark.

Erreurs courantes

Redémarrer la machine immédiatement. Un redémarrage efface la situation, et tout se reproduira dans une heure. Relevez d’abord les chiffres.
Se fier à une seule mesure instantanée. Un pic au moment où vous lancez htop ne signifie rien — observez pendant une minute.
Considérer une mémoire pleine comme un problème. Regardez available et le swap, pas free.
Changer de grade sans avoir compris. Une fuite de mémoire ou un script en boucle vous suivra sur le nouveau grade. Le retour à un grade inférieur n’est pas pris en charge.

Si le CPU, la mémoire et le disque sont calmes mais que l’application est lente, le goulot d’étranglement se situe en dehors de la machine : une API externe lente, le DNS ou le réseau du client. Vérifiez avec curl -w '%{time_total}\n' -o /dev/null -s vers l’adresse souhaitée.