Cinq commandes. C’est tout ce qu’il m’a fallu pour transformer un diagnostic de « mon PC rame, je sais pas pourquoi » en « ah, c’est ce processus qui bouffe 80% de ma RAM depuis trois jours ». Linux te donne les outils pour disséquer ton système en temps réel, et la plupart des gens ne savent même pas qu’ils existent. Voilà ce que j’ai tapé, dans quel ordre, et surtout ce que j’ai compris à chaque étape.
À retenir
- Une ligne mystérieuse dans top révèle des saturation CPU invisibles à l’œil nu
- Un processus cloud silencieux dévoraient les performances disque depuis des semaines sans qu’on le sache
- Le noyau Linux murmurait des erreurs matérielles critiques que personne n’écoutait
La première claque : top et ce qu’il révèle vraiment
Tout le monde a entendu parler de top. Très peu de gens savent le lire correctement. Quand tu le lances, tu te retrouves face à un tableau qui se rafraîchit toutes les quelques secondes avec des colonnes de chiffres et de pourcentages. La première fois, c’est un peu le générique de Matrix.
Ce qui m’a sauté aux yeux, c’est la ligne load average tout en haut. Elle affiche trois chiffres : la charge moyenne du CPU sur la dernière minute, les cinq dernières minutes, et les quinze dernières minutes. Sur une machine avec 4 cœurs, un load average de 4.0 signifie que ton processeur est à 100% de ses capacités. Quand j’ai vu 6.8 sur ma machine, le verdict était sans appel. Quelque chose saturait mes cœurs depuis un moment.
Le vrai piège de top, c’est qu’on fixe le pourcentage CPU des processus sans regarder la colonne RES, qui indique la mémoire RAM réellement consommée. Un processus peut sembler sage côté CPU et dévorer ta mémoire en silence. J’ai une application qui faisait exactement ça depuis des semaines.
htop, iotop et l’art de suivre la bonne piste
Si top est la carte papier froissée au fond du sac, htop est le GPS. Tu l’installes via ton gestionnaire de paquets (sudo apt install htop sur les dérivés Debian, sudo dnf install htop sur Fedora), et tu obtiens une interface avec des barres de progression colorées pour chaque cœur de CPU et pour la RAM. Naviguer avec les touches fléchées, trier par colonne d’un appui, tuer un processus directement depuis l’interface : c’est infiniment plus agréable.
Mais voilà ce que htop ne peut pas te dire : si le problème vient du disque. Sur mon système, le CPU était raisonnable une fois le processus fautif arrêté, et pourtant la machine restait lente, avec ce bruit caractéristique d’un disque dur qui travaille trop. C’est là qu’entre en scène iotop.
sudo iotop — et là, bingo. Un processus de synchronisation cloud lisait et écrivait sur le disque en continu, des centaines de mégaoctets par seconde, en tâche de fond. Sans iotop, j’aurais pu reformater la machine en pensant que le disque était mort. Le problème n’était pas matériel : c’était une application mal configurée qui re-scannait l’intégralité de mes fichiers à chaque démarrage.
free -h et la vérité sur ta mémoire
Voici une commande que tu peux taper maintenant, ça prend deux secondes : free -h. Le -h passe en format « human-readable », avec des gigas et des mégas au lieu de kilooctets illisibles.
Ce que la plupart des gens ne comprennent pas en lisant cette sortie, c’est la ligne available. Linux utilise la mémoire « libre » pour du cache disque, ce qui accélère les lectures répétées de fichiers. Ce cache est immédiatement libéré si une application en a besoin. La mémoire vraiment disponible pour tes programmes, c’est la colonne available, pas free. Sur ma machine, j’avais 512 Mo de free et 3,2 Go de available. Pas de panique, donc, le système faisait son travail normalement.
Là où ça devient problématique, c’est quand la ligne Swap montre une utilisation significative. Le swap, c’est ton disque dur qui joue les doublures de la RAM quand celle-ci est pleine. C’est lent, ça use les SSD inutilement, et c’est un signal d’alarme clair. Sur mon PC « qui ramait », j’avais 1,4 Go de swap utilisé. La RAM était saturée depuis longtemps.
dmesg | tail : quand le noyau murmure des choses inquiétantes
La cinquième commande est celle que les débutants oublient systématiquement. dmesg affiche le journal du noyau Linux, les messages bas niveau que le système génère sur le matériel, les pilotes, les erreurs silencieuses. Combiné à tail pour n’afficher que les dernières lignes, dmesg | tail -n 30 te donne un aperçu de ce qui s’est passé récemment dans les entrailles du système.
Dans mon cas, j’ai trouvé des messages répétés indiquant des erreurs de lecture sur mon disque dur, du type ata1.00: exception Emask. Mon disque dur commençait à fatiguer. Le ralentissement n’était pas seulement logiciel : le noyau retentait les lectures plusieurs fois avant de réussir, multipliant les temps d’accès. Sans cette commande, j’aurais peut-être continué pendant des semaines jusqu’à la panne totale.
J’ai commandé un SSD le soir même.
La beauté de Linux, c’est justement cette transparence brutale : le système ne te cache rien si tu poses les bonnes questions. Ces cinq commandes-terminal-changent-tout-sous-linux/ »>commandes ne règlent pas tous les problèmes, mais elles posent le bon diagnostic, celui qui distingue un processus fou d’un disque qui agonise, ou une fuite mémoire d’un cache qui fait son boulot. Et quand on y réfléchit, c’est exactement ce qu’on voudrait pouvoir faire sur n’importe quel système d’exploitation. La vraie question, c’est pourquoi les autres OS font encore autant d’efforts pour que tu ne voies pas ce qui se passe sous le capot.