Htop sous Linux : lire la charge d’un serveur sans paniquer devant les couleurs

Quand un serveur ralentit, htop donne vite l’impression de tout expliquer. Des barres CPU, de la mémoire, des couleurs, une liste de processus qui bouge dans tous les sens… et parfois une envie assez dangereuse : tuer le premier processus qui semble consommer trop.

Je vous conseille plutôt de lire htop comme un tableau de bord de départ. Il permet de repérer une piste, pas de conclure à lui seul. Dans cet article, on va voir quoi regarder en premier : CPU, mémoire, load average, tri des processus, et surtout les vérifications à faire avant de couper un service en production.

Installer et lancer htop sous Linux

Sur beaucoup de distributions, htop n’est pas installé par défaut. Sur Debian ou Ubuntu, vous pouvez l’ajouter avec APT :

sudo apt update
sudo apt install htop

Sur Fedora :

sudo dnf install htop

Sur Arch Linux :

sudo pacman -S htop

Ensuite, lancez simplement :

htop

Si vous êtes connecté en SSH sur un serveur distant, ouvrez htop dans une session propre. Évitez de lancer des actions destructrices depuis une session instable ou depuis un terminal que vous risquez de fermer par erreur.

Lire les barres CPU sans paniquer

En haut de l’écran, htop affiche une barre par cœur ou thread CPU. C’est pratique pour voir si la charge est répartie ou si un seul cœur travaille à fond.

Un pic CPU court n’est pas forcément un problème. Une sauvegarde, une compilation, un scan antivirus ou une compression peuvent monter très haut pendant quelques secondes. Ce qui m’intéresse surtout, c’est la durée du pic et le processus concerné.

Avant de toucher à quoi que ce soit, regardez aussi le nombre de processeurs logiques disponibles :

nproc

Un load average à 4 sur une machine avec 8 threads n’a pas la même signification que sur un petit VPS avec 1 vCPU. C’est une nuance simple, mais elle évite pas mal de mauvaises décisions.

uptime

La commande uptime affiche les trois valeurs de load average sur 1, 5 et 15 minutes. Si les trois montent depuis un moment, vous avez un signal plus solide qu’un simple pic aperçu dans htop.

Si vous voulez creuser ce point, l’article sur le load average sous Linux complète bien cette lecture.

Mémoire utilisée : ne confondez pas cache et saturation

La barre mémoire est souvent celle qui fait peur. Sur Linux, une partie importante de la RAM peut être utilisée en cache disque. Ce n’est pas forcément mauvais. Le noyau libère ce cache si les applications en ont besoin.

Pour vérifier en dehors de htop, lancez :

free -h

Regardez surtout la colonne available. Si elle reste confortable, la mémoire n’est peut-être pas votre problème principal, même si la barre htop paraît très remplie.

En revanche, si la mémoire disponible chute, que la swap grimpe et que le serveur devient lent, là il faut identifier le processus qui grossit. Dans htop, vous pouvez trier par mémoire avec F6, puis choisir la colonne MEM%.

ps -eo pid,ppid,cmd,%mem,%cpu --sort=-%mem | head

Cette commande donne une lecture rapide hors interface interactive. Elle peut dépanner si htop n’est pas installé ou si vous voulez copier le résultat dans un ticket.

Trier les processus pour trouver le vrai coupable

Dans htop, la liste du bas affiche les processus. Les colonnes les plus utiles au début sont PID, USER, CPU%, MEM%, TIME+ et Command.

Quelques touches à connaître :

• F6 pour choisir la colonne de tri ;
• F4 pour filtrer la liste ;
• F5 pour afficher l’arborescence des processus ;
• F9 pour envoyer un signal à un processus ;
• q pour quitter htop proprement.

L’arborescence est très utile. Elle permet de voir si un processus gourmand est lancé par un service, par un script, par un utilisateur SSH, ou par un enfant d’un serveur web.

Si vous voyez un processus Java, PHP, Python ou Node qui consomme beaucoup, ne le tuez pas au hasard. Vérifiez d’abord à quel service il appartient :

systemctl status nginx --no-pager
systemctl status php8.4-fpm --no-pager
systemctl status mariadb --no-pager

Adaptez évidemment les noms de services à votre serveur. Si vous ne savez pas quels services tournent, l’article sur les commandes systemctl pour lister les services Linux est plus adapté avant d’aller plus loin.

Avant de tuer un processus, vérifiez les logs

Le bouton le plus tentant dans htop, c’est F9. Il sert à envoyer un signal à un processus. Techniquement, vous pouvez tuer un PID depuis htop. Dans la vraie vie, c’est souvent le dernier geste, pas le premier.

Avant de couper un service, vérifiez ses logs récents :

sudo journalctl -u nginx -n 80 --no-pager

Si le service écrit dans un fichier dédié, suivez-le pendant quelques secondes :

sudo tail -f /var/log/nginx/error.log

Pour cette partie, vous pouvez aussi relire l’article sur tail et le suivi de logs en direct. Il évite de rester bloqué devant htop sans contexte.

Si le processus appartient à un service systemd, préférez un redémarrage propre :

sudo systemctl restart nginx
sudo systemctl status nginx --no-pager

Si vous devez vraiment envoyer un signal à un PID, commencez par TERM. Gardez KILL pour les cas où le processus ne répond plus du tout.

sudo kill -TERM 1234
sudo kill -KILL 1234

Remplacez 1234 par le PID réel. Et si vous êtes sur une base de données, un stockage, un serveur de production ou une session client active, prenez trente secondes de plus avant de frapper. C’est souvent là que l’on évite la vraie panne.

Quand htop ne suffit pas

Htop montre très bien les processus, mais il ne raconte pas toute l’histoire. Une charge élevée peut venir du CPU, de la mémoire, des entrées-sorties disque, du réseau, d’un service bloqué ou d’un pic applicatif normal.

Pour prendre un peu de recul :

vmstat 1 5
systemctl --failed
journalctl -p warning..alert -b --no-pager

vmstat donne une vue rapide sur CPU, mémoire, swap et attente I/O. systemctl --failed liste les unités en échec. journalctl permet de repérer les avertissements du démarrage courant.

Si le sujet touche les ports réseau ou un service qui n’écoute plus, vérifiez aussi ce qui est réellement ouvert avec ss ou netstat sous Linux.

Ma méthode courte devant un serveur lent

Quand j’ouvre htop sur un serveur qui rame, je garde cette séquence :

• regarder le load average avec uptime et le comparer au nombre de threads CPU ;
• vérifier la mémoire disponible avec free -h ;
• trier htop par CPU puis par mémoire ;
• identifier le service ou l’utilisateur derrière le processus ;
• lire les logs avant de redémarrer ou tuer quoi que ce soit ;
• faire un redémarrage propre avec systemctl si le processus dépend d’un service.

Htop est excellent pour voir ce qui se passe maintenant. Mais la bonne décision vient rarement d’une seule couleur ou d’une seule colonne. Prenez le PID, le service, les logs, puis seulement ensuite choisissez l’action.

Pour la documentation de référence, vous pouvez consulter le site officiel de htop, son dépôt GitHub, et la page man de top pour les notions proches autour de la charge et des processus.

sudo apt update && sudo apt upgrade