Trouver les scripts gourmands en CPU et RAM sur un serveur Linux avec la commande "htop"

Sur un serveur Linux, la commande htop est l’un des outils de monitoring les plus pratiques pour repérer en temps réel les scripts qui consomment excessivement le processeur (CPU) ou la mémoire vive (RAM). En analysant les colonnes CPU%, MEM%, PID, USER, TIME+ et COMMAND dans l’interface htop, on peut rapidement identifier quel processus PHP, Python, Node.js, cron, base de données ou système met à rude épreuve les ressources du serveur. Ensuite, il est possible de superviser le propriétaire du processus, le chemin du fichier et le but de l’exécution afin d’intervenir en toute sécurité.

Que vous soyez sur un hébergement mutualisé, VPS, serveur dédié ou cloud, la plupart des ralentissements soudains sont dus à des scripts non maîtrisés. Un plugin WordPress défectueux, un script PHP en boucle infinie, une tâche cron surchargée, une requête SQL non optimisée ou un fichier web compromis peuvent faire grimper la charge CPU à près de 100% en quelques minutes. Si la consommation RAM augmente, les services peuvent devenir instables, les connexions MySQL tomber, les sites afficher des erreurs 503 ou le noyau Linux activer l’OOM Killer pour stopper certains processus.

Ce guide va vous expliquer étape par étape comment installer htop, interpréter son affichage, distinguer les scripts qui exploitent excessivement CPU et RAM, retrouver le chemin du script via le PID et intervenir sans risque. Vous trouverez aussi des conseils liés à la sécurité, au contrôle des tâches cron, à l’analyse des logs et aux optimisations à mettre en place pour éviter que le problème ne se reproduise. Si vous rencontrez régulièrement des limites de ressources, pensez à consulter Paquets de serveurs VPS et Hébergement web haute performance pour comparer les solutions d’hébergement adaptées à vos besoins.

Qu’est-ce que htop et pourquoi est-il préférable à la commande top ?

htop est un utilitaire interactif pour surveiller les processus sur un système Linux via le terminal. Il ressemble à la commande top traditionnelle, mais propose une interface colorée et bien plus lisible, des indicateurs visuels pour les ressources, des fonctions de tri, de recherche, de filtrage et de gestion des processus. Pour le diagnostic rapide sur un serveur en production, htop est souvent le premier réflexe des administrateurs.

Avec htop, vous pouvez visualiser en temps réel :

• La part de CPU consommée par chaque processus
• La part de RAM utilisée et la quantité de mémoire
• Le numéro PID du processus
• L’utilisateur qui exécute le processus
• La ligne de commande ou le nom du script
• La durée d’exécution et la priorité
• La charge (load average), la RAM totale, le swap et l’utilisation des cœurs CPU

Sur un serveur d’hébergement où plusieurs sites, utilisateurs ou services tournent simultanément, il ne suffit pas de surveiller la consommation globale. Il faut identifier précisément quel utilisateur, site, tâche cron ou script pose problème. La commande htop fournit un diagnostic initial rapide pour ce cas.

Installer htop : commandes selon la distribution

Sur de nombreux systèmes Linux modernes, htop n’est pas préinstallé. Si vous disposez des droits root ou sudo, l’installation se fait en quelques secondes. Il est conseillé de mettre à jour la liste des paquets avant l’installation, surtout sur un serveur fraîchement configuré.

Installation de htop sur Ubuntu et Debian

Sur Ubuntu ou Debian, utilisez :

sudo apt update

sudo apt install htop -y

Après l’installation, lancez htop en tapant simplement htop dans le terminal. Si vous n’avez pas les droits sudo, contactez votre hébergeur pour obtenir de l’aide. Sur un VPS administré, l’accès root vous appartient généralement.

Installation sur AlmaLinux, Rocky Linux, CentOS et RHEL

Sur les distributions RHEL, le gestionnaire de paquets est dnf ou yum selon la version :

sudo dnf install htop -y

Sur les anciennes versions CentOS, il faut d’abord activer le dépôt EPEL :

sudo yum install epel-release -y

sudo yum install htop -y

Une fois installé, tapez htop pour afficher l’interface colorée de monitoring. Si vous débutez la gestion de serveur, le guide guide des commandes Linux est une bonne entrée en matière pour les bases des commandes Linux.

Lire l’écran htop : signification des colonnes

Quand htop est lancé, le haut de l’écran affiche les cœurs CPU, la mémoire RAM, le swap, le nombre de tâches, de threads, la charge moyenne et le temps d’activité. En dessous, la liste détaillée des processus actifs. Les zones les plus utilisées pour diagnostiquer un problème sont :

Attention : un pic temporaire de CPU n’est pas forcément une anomalie. Par exemple, lors d’une sauvegarde, d’une optimisation d’images, d’un nettoyage de cache ou pendant un pic de trafic, la CPU peut grimper brièvement. Le vrai problème, c’est quand le même processus consomme fortement CPU/RAM pendant plusieurs minutes, que la charge moyenne dépasse largement le nombre de cœurs, et que les services web deviennent inaccessibles.

Identifier les scripts gourmands en CPU avec htop

Pour repérer les scripts qui exploitent excessivement le processeur, utilisez la fonction de tri sur la colonne CPU% dans htop (F6 ou clic si la souris est prise en charge). Les processus affichés en haut sont ceux qui utilisent le plus de CPU à l'instant T.

Étape 1 : Triez par colonne CPU%

Classez les processus par consommation CPU. Si un processus comme php-fpm, php, python3, node, java, mysqld ou bash reste constamment en tête, notez-le. Sur un serveur mono-cœur, 100% est la limite normale ; sur un multi-cœurs, un processus peut afficher 200% ou 400% s’il exploite plusieurs cœurs.

Étape 2 : Notez le PID et l’utilisateur (USER)

Consignez le numéro PID et l’utilisateur du processus suspect. Par exemple, PID 24819, USER siteuser et COMMAND php /home/siteuser/public_html/wp-cron.php indiquent que le problème est probablement lié au cron WordPress de ce site. Si le champ COMMAND est tronqué, activez l’affichage complet dans htop ou utilisez la commande ps pour plus de détails.

Étape 3 : Affichez la commande exacte du processus

Pour voir la ligne de commande complète à partir du PID :

ps -fp PID

Exemple :

ps -fp 24819

La sortie indique généralement le fichier exécuté. Si vous voyez php /home/utilisateur/public_html/index.php, il s'agit d'une requête web. Si c’est php /home/utilisateur/public_html/wp-content/plugins/plugin-inconnu/task.php, il peut s’agir d’un plugin problématique.

Étape 4 : Vérifiez le chemin du fichier et les fichiers ouverts

Pour savoir quels fichiers sont utilisés par un processus, l’utilitaire lsof est très utile :

lsof -p PID

Cette commande révèle les fichiers ouverts, bibliothèques, logs et connexions réseau du processus. Sur un hébergement web, cela permet de déterminer le dossier du site concerné. Si vous repérez un fichier PHP au nom étrange dans /home/example/public_html/wp-content/uploads, cela peut indiquer une compromission. Dans ce cas, il faut non seulement tuer le processus, mais aussi nettoyer les fichiers, changer les mots de passe, mettre à jour les plugins, effectuer un scan sécurité. Pour toute configuration SSL et sécurisation, consultez aussi solutions de certificats SSL.

Repérer les scripts gourmands en RAM avec htop

Les problèmes de mémoire RAM sont parfois plus insidieux que ceux du CPU. Quand la CPU monte, le ralentissement est immédiat ; quand la RAM sature, les services peuvent tomber, le swap s’active et tout le serveur ralentit. Utilisez le tri sur la colonne MEM% dans htop pour voir les processus qui consomment le plus de mémoire.

Comprendre MEM%, RES et le swap

htop affiche MEM% par défaut. Certaines configurations montrent aussi VIRT, RES et SHR. Pour analyser la RAM, la valeur RES est essentielle car elle indique la mémoire physique réellement utilisée. VIRT ne signifie pas nécessairement une consommation réelle et peut être trompeur.

Par exemple, sur un VPS avec 4 Go de RAM, un processus PHP utilisant 900 Mo de RES n’est pas normal. De même, si une appli Node.js passe de 200 Mo à 1,5 Go, il faut suspecter une fuite de mémoire. Pour MySQL/MariaDB, une haute consommation RAM peut être normale selon le cache ; il faut tenir compte des paramètres de buffer et de la RAM système.

Causes typiques des scripts consommateurs de RAM

• Scripts PHP, Python ou Node.js en boucle infinie
• Import massif de fichiers CSV, XML ou JSON en mémoire
• Plugins WordPress non optimisés ou thèmes mal conçus
• Traitement d’images, génération de PDF, conversion vidéo
• Manque de cache, entraînant des requêtes répétitives lourdes
• Trafic de bots ou attaques lancent plusieurs instances du même script
• Services de fond avec fuite mémoire (memory leak) sur le long terme

Un simple kill ne règle que temporairement le problème. Pour une solution durable, il faut analyser le comportement du script, les entrées qui le déclenchent et pourquoi il ne libère pas la mémoire.

Recherche, filtrage et affichage en arborescence dans htop

Avec des centaines de processus sur le serveur, chercher manuellement devient difficile. htop propose des raccourcis efficaces : F3 pour rechercher, F4 pour filtrer, F5 pour afficher en arbre. L’arborescence est utile pour visualiser les relations parent-enfant : par exemple, les workers php-fpm sous nginx ou Apache, les scripts lancés par cron, ou les services Node.js supervisés par Supervisor.

Exemples de filtres pratiques

• Filtrez par "php" pour n’afficher que les processus PHP
• Par "python" pour les scripts Python
• Par "wp-cron" pour vérifier le comportement du cron WordPress
• Par "node" pour les applications Node.js
• Par nom d’utilisateur pour isoler les processus d’un compte hébergement spécifique

Ces filtres font gagner du temps, surtout sur les serveurs multi-sites. Si vous hébergez 30 sites, en croisant USER et le chemin du script, vous identifiez rapidement le compte à l’origine du problème. Pour simplifier la gestion des domaines, consultez Vérification de domaine et enregistrement.

Plan d’intervention sécurisé sur un PID suspect

La tentation de tuer immédiatement un processus avec kill -9 est forte, mais ce réflexe peut causer des pertes de données, fichiers partiellement écrits ou incohérences de service. Il faut suivre une méthode plus sûre.

1. Documentez le processus

Notez PID, USER, COMMAND, CPU%, MEM% et la durée. Prenez une capture d’écran htop si possible. Ces informations servent de base pour les analyses futures ou les explications techniques à vos clients (agences, e-commerce, entreprises).

2. Vérifiez le chemin du processus

Avec ps -fp PID et lsof -p PID, confirmez le chemin du fichier. S’il s’agit d’un script web, analysez les logs correspondants : wp-content/debug.log pour WordPress, access/error log pour le serveur web, slow log pour PHP-FPM.

3. Tentez d’abord une terminaison douce

Pour mettre fin à un processus, envoyez d’abord un signal standard :

kill PID

Patientez quelques secondes et vérifiez dans htop. Si le processus persiste et impacte fortement le serveur, utilisez alors :

kill -9 PID

Attention, kill -9 stoppe le processus sans nettoyage. À éviter pour les tâches de base de données, écriture de fichiers ou sauvegarde.

4. Si le processus redémarre, cherchez le déclencheur

Si le processus revient immédiatement, il est probablement relancé par une tâche cron, un service systemd, Supervisor, une requête web ou du trafic bot. Analysez les cron avec crontab -l, les services avec systemctl status nomduservice, et le trafic web avec les logs d’accès. Pour WordPress, vérifiez la configuration du cron et la politique de cache.

Croiser les résultats htop avec les logs

htop indique qui consomme, les logs révèlent pourquoi. Les deux sont complémentaires pour un diagnostic complet. Par exemple, htop peut montrer un processus php-fpm à 180% CPU, mais sans log d’accès, impossible de savoir quelle URL ou quel bot a déclenché ce processus.

Quelques logs à vérifier :

• Access log du serveur web : montre les URLs les plus sollicitées
• Error log : erreurs PHP, permissions de fichiers, erreurs 500
• PHP-FPM slow log : scripts PHP lents
• Slow query log MySQL : requêtes SQL lourdes
• Auth log : tentatives de connexion suspectes
• Cron log : horaires et exécution des tâches planifiées

Par exemple, si le PID gourmand en CPU correspond à des milliers de requêtes sur /wp-admin/admin-ajax.php dans les logs, le problème vient d’un plugin, d’un bot ou d’un mauvais usage d’AJAX. Il faudra envisager firewall, rate limiting, cache et optimisation de plugin. Pour une vision globale de la vitesse du site, consultez Optimisation de la vitesse de site Web.

Différencier une charge normale d’une surcharge problématique

Une utilisation élevée des ressources n’est pas forcément une crise. Il faut prendre en compte le matériel, le trafic, le type d’applications et les opérations de maintenance. Sur un VPS 2 cœurs, une charge moyenne de 6-8 sur la durée indique un vrai goulet d’étranglement ; sur un serveur dédié 16 cœurs, ce chiffre peut être normal. Toujours interpréter la charge (load average) en fonction du nombre de cœurs.

Ce comparatif vous aide à distinguer une surcharge passagère d’une vraie crise. Par exemple, une boutique e-commerce peut connaître un pic lors d’une campagne, mais si les performances chutent, il faut optimiser l’application et/ou augmenter la capacité du serveur.

Sécurité : un script consommateur peut-il être malveillant ?

Un script gourmand en CPU/RAM n’est pas toujours innocent. Sur un site compromis, des pirates peuvent lancer des scripts d’envoi de spam, de minage crypto, de proxy, de bot DDoS ou d’installation de portes dérobées. Sur htop, soyez attentif aux processus sous des utilisateurs inattendus, aux commandes étranges, aux fichiers exécutés depuis /tmp ou uploads, ou à des fichiers PHP inhabituels dans public_html/uploads.

Signes suspects

• COMMAND contient des noms de fichiers incohérents ou aléatoires
• Exécution depuis /tmp, /dev/shm ou le dossier uploads
• Processus perl, python ou bash inattendus
• Processus générant beaucoup de connexions externes
• Un utilisateur lance de multiples processus en peu de temps
• Modifications récentes non autorisées dans les fichiers web

Avant de tuer un processus suspect, enregistrez les sorties de commande comme preuve. Vérifiez ensuite les permissions, isolez les fichiers malveillants, changez tous les mots de passe panels/CMS, mettez à jour plugins/thèmes, lancez un scan sécurité. Pour réduire les risques, activez l’authentification à deux facteurs sur vos panels et limitez les permissions d’écriture inutiles.

Bonnes pratiques pour prévenir les problèmes de performances

Repérer un problème avec htop est utile, mais la vraie valeur est d’empêcher qu’il ne se reproduise. Voici les mesures pour limiter les interruptions liées au CPU ou à la RAM sur un serveur Linux :

• Adaptez les valeurs PHP memory_limit, max_execution_time et pm.max_children à la capacité du serveur.
• Utilisez un système de cache sur WordPress, Joomla ou vos développements personnalisés.
• Supprimez les plugins, thèmes ou modules inutiles.
• Optimisez les requêtes lourdes via le slow query log MySQL.
• Évitez de faire tourner toutes les tâches cron au même moment ; répartissez-les.
• Pour le trafic bot, appliquez rate limiting, robots.txt et règles de firewall.
• Tournez régulièrement les logs pour éviter qu’ils ne saturent le disque/RAM.
• Surveillez les métriques serveur pas seulement lors des crises, mais en routine.

Si malgré les optimisations, la consommation de ressources reste élevée, le problème peut venir de la croissance du trafic, de l’application ou du forfait d’hébergement. Dans ce cas, un VPS évolutif, plus de RAM, un disque NVMe rapide ou un serveur dédié isolé sont à envisager. Pour comparer les options, consultez Packs d'hébergement et solutions de serveur professionnel.

Exemple pratique : explosion CPU sur un site WordPress

Supposons un VPS 4 cœurs et 8 Go RAM hébergeant plusieurs sites WordPress. Les utilisateurs signalent des lenteurs et des erreurs 502. En ouvrant htop, la charge moyenne est à 12, tous les cœurs saturés, et de nombreux processus php-fpm sous le même utilisateur sont en tête.

Avec F4, filtrez sur le nom d’utilisateur. Notez le PID d’un processus consommant le CPU. ps -fp PID révèle un worker php-fpm ; lsof -p PID montre un accès à /home/site/public_html/wp-content/plugins/example-importer/import.php. Dans les logs d’accès, on retrouve des requêtes fréquentes vers ce fichier via AJAX.

Solution : arrêter l’import, désactiver la tâche planifiée du plugin, segmenter l’import de données, ajuster max_execution_time PHP et remplacer wp-cron par un cron système. Résultat : la charge passe de 12 à 1,8, le CPU revient à la normale, les temps de réponse s’améliorent nettement. Cet exemple montre l’efficacité de croiser htop, ps, lsof et l’analyse des logs.

Erreurs fréquentes lors de l’utilisation de htop

• Se contenter de tuer le processus en tête sans chercher la cause
• Prendre VIRT pour la consommation réelle de RAM
• Considérer la RAM utilisée par MySQL pour le cache comme un problème
• Utiliser le kill -9 systématiquement
• Accuser l’application ou l’utilisateur sans vérifier les logs
• Interpréter la charge sans tenir compte du nombre de cœurs CPU
• Oublier de vérifier l’intégrité des fichiers en cas de suspicion de faille

Éviter ces erreurs réduit les temps d’arrêt et le risque de perte de données liée à une intervention inappropriée. En gestion système, le bon diagnostic est souvent plus précieux qu’une réaction rapide.

FAQ – Questions fréquentes

À quoi sert la commande htop sur un serveur Linux ?

La commande htop affiche en temps réel les processus, leur consommation CPU/RAM, utilisateur, PID et la commande lancée. Elle permet de repérer facilement les scripts qui consomment trop de ressources.

Comment trouver un script consommateur de CPU avec htop ?

Trier les processus par CPU%, noter le PID et l’utilisateur du processus qui reste en haut, puis utiliser ps -fp PID et lsof -p PID pour identifier le chemin du script et ce qu’il exécute.

Pour la RAM, faut-il se fier à MEM% ou VIRT ?

MEM% et surtout RES sont les indicateurs pertinents pour la RAM. VIRT indique la mémoire virtuelle allouée, qui n’est pas toujours utilisée physiquement.

Est-il correct de tuer un processus gourmand directement avec kill -9 ?

Pas en général. Il vaut mieux documenter le processus, vérifier le chemin, tenter kill PID puis kill -9 en dernier recours si le processus ne se termine pas et menace la stabilité du serveur.

Une forte consommation CPU dans htop est-elle toujours un signe d’attaque ?

Non. Sauvegarde, import de données, création de cache ou trafic intense peuvent aussi expliquer une hausse CPU. Mais des noms de fichiers étranges, des scripts exécutés depuis /tmp ou uploads, ou des processus inattendus sont des signes à surveiller.

En résumé, htop sur Linux est un point de départ rapide, pratique et efficace pour identifier les scripts qui exploitent excessivement CPU ou RAM. Pour un diagnostic complet, il faut croiser les données htop avec l’analyse PID, lsof, cron et les logs. Si les problèmes de ressources sont récurrents, évaluez à la fois l’optimisation logicielle et la capacité de l’infrastructure ; comparez sans pression les solutions d’hébergement, VPS et SSL de Hostragons pour sélectionner la configuration la plus adaptée à votre projet.