Superviser son VPS avec htop

htop est une version interactive de top : plus lisible, plus rapide à trier, et suffisante pour comprendre ce qui se passe sur un VPS au moment où vous regardez. Il ne remplace pas une supervision dans la durée, mais il répond en quelques secondes à la question « qu'est-ce qui consomme ? ».

Installer et se repérer

sudo apt install htop
htop

Les touches essentielles : F3 cherche, F4 filtre, F5 affiche l'arborescence des processus, F6 choisit le tri, F9 envoie un signal, F2 ouvre les réglages. u filtre par utilisateur, H affiche ou masque les threads. Utilisez F5 dès qu'un service lance des workers : PHP-FPM, Node.js en cluster ou Gunicorn deviennent lisibles.

Lire l'en-tête sans se tromper

La charge moyenne (load average) se lit par rapport au nombre de cœurs : nproc vous donne ce nombre. Une charge de 4 sur 4 vCPU est une saturation, pas une catastrophe ; une charge de 4 sur 1 vCPU l'est.

Dans un conteneur système, htop peut afficher les cœurs physiques alors que votre quota est plus faible. Fiez-vous au quota plutôt qu'au nombre de barres :

cat /sys/fs/cgroup/cpu.max

Pour la mémoire, les barres distinguent l'utilisé, les tampons et le cache. Le cache n'est pas de la mémoire perdue : le noyau le réutilise. Surveillez surtout la barre de swap et la colonne RES des processus.

Identifier le bon processus

Triez par %CPU ou par RES avec F6. RES correspond à la mémoire réellement occupée ; VIRT inclut des réservations qui ne disent rien de la consommation réelle. Avec F5, vous voyez quel processus parent a lancé les consommateurs : un pool PHP-FPM qui grossit, un worker Node.js qui fuit ou une commande lancée à la main.

F4 filtre par nom, ce qui est plus sûr que de tuer un PID au hasard dans une longue liste.

Agir proprement

F9 envoie un signal. Commencez par SIGTERM (15), qui laisse au processus le temps de fermer ses fichiers et ses connexions. SIGKILL (9) ne doit servir qu'en dernier recours : il ne laisse aucune chance de nettoyage.

N'envoyez jamais SIGKILL à PID 1, à sshd ou à systemd-journald sans comprendre les conséquences : vous pouvez perdre l'accès ou la journalisation. Pour réduire l'impact d'un processus sans le tuer :

sudo renice 10 -p PID
sudo ionice -c3 -p PID

Corrigez ensuite la cause : une limite de workers trop haute, une requête non indexée, une fuite mémoire. Tuer le processus toutes les heures n'est pas une supervision.

Connaître les limites

htop ne montre qu'un instantané et uniquement les processus de votre conteneur. Pour une tendance, journalisez top -b -n 1 via cron ou utilisez un outil de supervision. Et rappelez-vous que dans un conteneur système, les chiffres de CPU et de mémoire peuvent refléter la plateforme : comparez-les à free -h et aux fichiers cgroup avant de conclure.