Administration Linux : comment surveiller les performances système

Administration Linux : comment surveiller les performances système

Image by: AMORIE SAM

Comprendre les goulots d’étranglement Linux

Saviez-vous que 70% des ralentissements serveur proviennent de quatre ressources critiques seulement ? Les goulots d’étranglement sur un serveur Linux paralysent régulièrement les performances lorsqu’une ressource atteint ses limites. Ces points de congestion – CPU, mémoire RAM, disque ou réseau – créent des effets domino sur l’ensemble du système. Identifier rapidement la ressource défaillante est la première étape vers la résolution. Voici un tableau comparatif des symptômes typiques :

Ressource Symptômes Impact moyen
CPU Load average > nombre de cores, processus en état D Ralentissements généralisés
RAM Swap utilisé > 20%, oom_killer activé Bloquages intermittents
Disque iowait > 30%, files d’attente E/S saturées Latence élevée des requêtes
Réseau Paquets dropés, saturation de la bande passante Connexions interrompues

L’étude Linux Foundation révèle que les administrateurs passent en moyenne 45 minutes à localiser un goulot sans méthodologie adaptée. Pourtant, avec les bons outils, ce diagnostic peut prendre moins de 5 minutes. Les commandes htop, iotop et df forment votre trousse de premiers soins pour ces urgences système.

Diagnostiquer l’utilisation du CPU avec htop

Lorsque votre serveur devient lent, htop est votre premier réflexe. Plus puissant que top, cet outil interactif offre une visualisation en temps réel :

  1. Installez-le via sudo apt install htop (Debian/Ubuntu) ou sudo yum install htop (RHEL/CentOS)
  2. Lancez htop pour voir immédiatement :
    • Les barres de charge CPU par core
    • La mémoire et swap utilisés
    • Le load average (1m, 5m, 15m)

Un load average dépassant le nombre de cores CPU indique un goulot d’étranglement. Exemple : sur un serveur 4 cores, un load à 6.0 signifie que des processus sont en attente. Triez les processus avec F6 :

  1. Par %CPU pour identifier les processus gourmands
  2. Par STATE pour repérer les processus en D (uninterruptible sleep)

Si un processus Apache consomme 150% CPU, il monopolise 1.5 core. Utilisez F9 pour envoyer un signal SIGTERM ou SIGKILL en dernier recours. Pour une optimisation durable, consultez notre guide d’optimisation CPU.

Cas pratique : attaque de bots

Un client hébergeant un site WordPress voyait son load average atteindre 23 sur 4 cores. Htop a révélé 50 processus php-fpm consommant chacun 30-40% CPU. Solution : installation d’un rate limiter sur Nginx et blocage des IPs abusives via fail2ban.

Analyser la consommation mémoire

La RAM est souvent le deuxième point de blocage. Commencez par free -h pour un aperçu global :

              total    used    free   shared  buff/cache   available
Mem:           7.7G    4.2G    1.1G     456M        2.4G        2.6G
Swap:          2.0G    1.5G    512M

Un swap utilisé à plus de 20% est un signal d’alarme. Dans htop, la colonne RES montre la mémoire physique utilisée par chaque processus. Attention aux fuites mémoire : si un processus voit sa RES augmenter continuellement sans se stabiliser, il faut investiguer.

Outils complémentaires :

  • vmstat 2 : montre les swaps in/out (si si > 0 régulièrement)
  • smem -s swap -r : trie les processus par utilisation swap

Une solution courante est d’ajuster les paramètres swappiness avec sysctl vm.swappiness=10 pour réduire l’usage du swap. Pour les applications Java, vérifiez les paramètres Xmx/Xms. Consultez la documentation du kernel Linux pour le tuning mémoire avancé.

Surveiller les E/S disque avec iotop

Lorsque le CPU et la RAM semblent normaux mais que le serveur reste lent, le disque est souvent le coupable. Iotop révèle les processus responsables des opérations d’entrée/sortie :

  1. Installez-le via sudo apt install iotop ou sudo yum install iotop
  2. Lancez sudo iotop -o pour voir uniquement les processus actifs

Les colonnes clés :

  • DISK READ et DISK WRITE : débit en temps réel
  • SWAPIN : % de temps passé à swapper
  • IO : priorité I/O du processus

Une valeur iowait élevée dans top (> 30%) confirme le goulot disque. Solutions immédiates :

  • Pour MySQL : optimisez les requêtes lentes avec slow query log
  • Pour les logs : activez la rotation avec logrotate
  • Pour les sauvegardes : planifiez-les hors heures de pointe

Selon une étude de Percona, 60% des problèmes I/O proviennent de requêtes DB non optimisées.

Vérifier l’espace disque avec df

Un système de fichiers plein est le goulot le plus simple à diagnostiquer mais souvent négligé. df -h donne l’état des partitions :

Filesystem      Size  Used Avail Use% Mounted on
/dev/vda1        50G   48G  0.8G  99% /
/dev/vdb1       100G   24G   76G  24% /data

Un Use% à 95%+ dégrade sévèrement les performances. Complétez avec sudo du -sh /* | sort -h pour identifier les répertoires les plus volumineux. Attention aux fichiers supprimés mais toujours ouverts : sudo lsof +L1 liste les fichiers avec link count=0.

Gestion des inodes :

df -i / # Vérifiez l'utilisation des inodes

Un système de fichiers peut être « plein » avec 20% d’espace libre si les inodes sont épuisés – fréquent avec des millions de petits fichiers. Solution : find / -xdev -printf "%h\n" | cut -d/ -f-2 | sort | uniq -c | sort -n pour trouver les dossiers surchargés.

Frequently asked questions

Comment différencier un problème CPU d’un problème RAM ?

Observez le load average et l’iowait dans htop. Un load élevé avec faible iowait indique un goulot CPU. Si le swap est activement utilisé (si > 0 dans vmstat) avec des processus en état D, c’est un problème RAM. Le monitoring conjoint de ces métriques est essentiel.

Que faire si iotop montre un processus système (kernel) en tête ?

Cela indique généralement une activité disque intensive liée au cache ou au swapping. Vérifiez l’état de la RAM (free -h) et réduisez le swappiness. Utilisez pidstat pour associer l’activité I/O à un processus utilisateur spécifique : pidstat -d 2.

Pourquoi df et du montrent-ils des résultats différents ?

df compte les blocs alloués au système de fichiers, tandis que du calcule l’espace des fichiers visibles. Les différences proviennent souvent de fichiers supprimés mais encore ouverts (check avec lsof) ou de réservations d’espace (ex: fichiers sparce). Un reboot peut résoudre ce décalage temporaire.

Mon serveur a suffisamment de RAM libre mais utilise quand même le swap, pourquoi ?

Le kernel déplace vers le swap les pages mémoire inactives pour libérer de la RAM pour le cache disque. Ce comportement est normal mais excessif si vm.swappiness > 60. Ajustez-le temporairement avec sysctl vm.swappiness=10 et vérifiez l’impact sur les performances.

Conclusion

Diagnostiquer les goulots d’étranglement sur un serveur Linux exige une approche méthodique : commencez par le CPU (htop), puis la RAM (free), les E/S disque (iotop) et l’espace (df). Chaque outil apporte une pièce du puzzle pour identifier la ressource limitante. La clé est d’interpréter les métriques en contexte : un load average élevé avec iowait minimal pointe vers le CPU, tandis qu’un swap actif avec des processus bloqués signale une pénurie de RAM. En cas de crise, documentez vos observations avant d’agir – un sudo sysstat peut capturer l’état système pendant l’incident. Pour aller plus loin, explorez notre formation avancée d’administration Linux ou consultez nos services d’optimisation de serveurs. Partagez vos expériences de diagnostic en commentaires !