Optimisation des Performances d'un Serveur Linux

Dans le monde des serveurs, la performance est reine. Un serveur Linux efficace et bien entretenu est un atout essentiel pour toute entreprise ou projet. Cependant, avec la complexité croissante des systèmes et applications, il est inévitable que des problèmes de performance surviennent. La surveillance et l’optimisation des performances deviennent donc des compétences indispensables pour les administrateurs de systèmes.

Que vous gériez un petit serveur web ou une infrastructure de cloud complexe, comprendre et optimiser les performances de vos serveurs Linux est un élément clé pour assurer un service fiable et efficace.

Dans ce chapitre, nous verrons les fondamentaux de la surveillance des performances d’un serveur Linux. Nous explorerons les différentes formes de contentions qui peuvent survenir — mémoire, CPU, réseau et IO. Vous apprendrez quelques commandes pour détecter ces problèmes. Plus important encore, nous discuterons des stratégies pour corriger ces problèmes afin de maintenir vos serveurs en bonne santé.

Fondamentaux de la Surveillance de l’état de santé des serveurs Linux

La surveillance des performances des serveurs Linux doit être un processus continu ce qui implique de garder un œil sur les différentes ressources du système pour comprendre comment elles sont utilisées. Cela inclut la mémoire, le processeur (CPU), le réseau et les opérations d’entrée/sortie (IO). Une surveillance efficace permet non seulement de détecter les problèmes de performance dès qu’ils apparaissent, mais aussi de planifier des mises à niveau de manière proactive pour éviter les goulots d’étranglement.

Décryptage des métriques d’Utilisation du CPU : Idle, System, IOWait, User et Steal

Bien sûr, lorsque vous allez utiliser des commandes telles que vmstat, iostat, mpstat ou top sur un système Linux, vous rencontrerez différents termes qui décrivent l’utilisation du CPU. Comprendre ces termes est important pour interpréter correctement l’état du système. Voici une explication des types d’informations à maîtriser :

1. CPU idle (%idle) : Cette valeur représente le pourcentage de temps durant lequel le processeur est inactif et n’exécute aucune tâche.

2. CPU système (%sys) : Le temps CPU système représente le pourcentage de temps durant lequel le CPU était occupé à exécuter des tâches du noyau (kernel). Cela inclut le temps passé pour des choses comme la gestion des processus, la manipulation du système de fichiers et la gestion du réseau.

3. CPU utilisateur (%usr) : Ce pourcentage montre le temps passé par le CPU à exécuter des processus en mode utilisateur, c’est-à-dire le code des applications et des tâches initiées par l’utilisateur.

4. Attente d’IO (%iowait) : Ce pourcentage montre la répartition de temps pendant lequel le CPU attendait que les opérations d’entrée/sortie (comme la lecture ou l’écriture sur un disque dur) se terminent.

5. CPU volé (%steal) : Ce terme est souvent vu dans les environnements virtualisés. Il représente le pourcentage de temps que le CPU a été alloué à une autre machine virtuelle par l’hyperviseur.

Chacune de ces métriques donne un aperçu de la façon dont le CPU est utilisé et peut aider à diagnostiquer différents types de problèmes de performance. Par exemple, un %iowait élevé peut indiquer un problème d’IO, tandis qu’un %idle élevé pourrait signifier que le système dispose de ressources CPU suffisantes voir trop.

Qu’est-ce que load average ?

Le “load average” est un indicateur important pour mesurer la charge de travail d’un système d’exploitation Unix, comme Linux. Il fournit une moyenne du nombre de processus qui sont soit activement en cours d’exécution, soit en attente d’exécution par le processeur (CPU).

Une des commandes à utiliser pour afficher cette information est uptime :

uptime
 11:05:07 up 15 days,  5:57,  1 user,  load average: 2,70, 2,40, 2,07

Composantes du Load Average

Le load average est généralement présenté sous trois valeurs numériques, par exemple, 0.75, 0.50, 0.25, qui représentent la charge moyenne du système sur trois périodes de temps différentes :

1. La première valeur montre la charge moyenne du système au cours de la dernière minute. Elle donne une idée de la charge actuelle du système.
2. La seconde valeur reflète la charge moyenne sur les 5 dernières minutes. Elle lisse les fluctuations de charge à court terme.
3. La troisième valeur indique la charge moyenne sur les 15 dernières minutes. Elle offre une vision plus longue et peut indiquer une tendance générale.

Interprétation du Load Average

Il est important de considérer le nombre de cœurs CPU lors de l’interprétation du load average. Par exemple, un load average de 2.0 est surchargé pour un système mono-cœur, mais normal pour un système quadricœur. Il faut diviser les valeurs par le nombre de coeurs pour évaluer les informations :

• Valeurs Inférieures à 1.0 : Une valeur inférieure à 1.0 suggère que le CPU n’est pas entièrement sollicité et qu’il y a des cycles CPU inutilisés.
• Valeurs Égales à 1.0 : Cela signifie que le CPU est entièrement utilisé, mais sans surcharge.
• Valeurs Supérieures à 1.0 : Cela signifie que les processus doivent attendre pour accéder au CPU.

Les différents types de contention

• Contention Mémoire

  • La mémoire est un composant essentiel de tout système informatique.
  • La contention mémoire se produit lorsque les demandes de mémoire dépassent la quantité disponible.
  • Conséquences : ralentissements et problèmes de performance.

• Contention CPU

  • La contention CPU survient lorsque les demandes de traitement dépassent les capacités du processeur.
  • Causes : nombre élevé de processus, applications gourmandes, mauvaise répartition de la charge.
  • Conséquences : ralentissements, performances médiocres.

• Contention Réseau

  • La contention réseau apparaît lorsque la bande passante est saturée ou mal utilisée.
  • Causes : trafic excessif, mauvaise configuration, problèmes matériels.
  • Conséquences : ralentissements, retards dans la communication des données.

• Contention IO

  • La contention IO concerne les problèmes de performance dus à une sollicitation excessive des systèmes de stockage (disques durs, SSD).
  • Manifestations : ralentissements dans l’accès aux fichiers, délais de lecture/écriture, dégradation générale des performances du serveur.

Méthode USE : une approche systématique du diagnostic

Dans le cadre de la surveillance des performances d’un serveur Linux, la méthode USE (Utilization, Saturation, Errors) ↗, développée par Brendan Gregg, propose une approche structurée et pragmatique pour diagnostiquer les problèmes. Elle est particulièrement utile pour éviter les analyses incomplètes ou biaisées, en s’assurant que toutes les ressources critiques sont examinées selon trois critères fondamentaux.

Les trois piliers de la méthode USE

Pour chaque ressource matérielle ou logicielle, il faut évaluer :

• Utilization (Utilisation) : Quelle est la part de la ressource actuellement utilisée ?
• Saturation : Y a-t-il une file d’attente ou une surcharge en attente d’accès à cette ressource ?
• Errors (Erreurs) : Y a-t-il des incidents ou dysfonctionnements signalés sur cette ressource ?

Cette approche s’applique à toutes les ressources du système : CPU, mémoire, disques, interfaces réseau, bus PCI, etc.

Application pratique de la méthode USE sur un serveur Linux

La méthode USE est une approche d’audit systématique pour identifier les goulots d’étranglement dans un système Linux. Pour chaque ressource — CPU, mémoire, IO, réseau — on analyse trois axes : Utilisation, Saturation, Erreurs.

Contention Mémoire

Utilisation

Commande :

free -m

Sortie typique :

              total        used        free      shared  buff/cache   available
Mem:          16038       15200         423         145         414         382
Swap:          2048         512        1536

Interprétation : La mémoire RAM est quasiment pleine (15 Go sur 16). Le système utilise le swap (512 Mo), ce qui peut entraîner un ralentissement.

Saturation

Commande :

vmstat 1 5

Extrait :

procs -----------memory---------- ---swap-- -----io---- -system-- ------cpu-----
 r  b  swpd   free  buff  cache   si   so    bi    bo   in   cs us sy id wa st
 3  0 524288  10432  5120 10240   10   35    80    95  210  314  6  3 85  6  0

Interprétation :

• si (swap-in) et so (swap-out) actifs → la mémoire est insuffisante.
• %wa = 6 → le CPU attend des IO causés par le swapping.

Erreurs

Commandes :

dmesg | grep -i oom
journalctl -k | grep -i oom

Sortie possible :

Out of memory: Kill process 1234 (java) score 987 or sacrifice child
Killed process 1234 (java) total-vm:20480000kB, anon-rss:16384000kB

Interprétation : L’OOM-Killer a tué un processus Java qui consommait trop de mémoire. Ce symptôme indique une grave contention mémoire.

Stratégies de correction

• Ajouter de la RAM si la charge dépasse régulièrement la capacité.

• Limiter les caches applicatifs (MySQL, Java).

• Augmenter le swap sur un SSD :

  swapon --show
  dd if=/dev/zero of=/swapfile bs=1G count=4
  mkswap /swapfile && swapon /swapfile

• Profiler les applications avec valgrind, smem, pmap.

Contention CPU

Utilisation

Commande :

mpstat -P ALL 1

Extrait :

CPU  %usr  %sys  %iowait  %idle
  0   80     10       5      5
  1   70     12       6     12

Interprétation : La majorité du temps est passée en mode utilisateur (%usr) et système (%sys) → CPU très sollicité.

Saturation

Commandes :

uptime

22:34:41 up 10 days,  2:33,  1 user,  load average: 6.24, 5.89, 5.74

Avec nproc renvoyant 4 cœurs logiques, un load average de >4 signifie que plus de tâches attendent le CPU.

Commande complémentaire :

vmstat 1 5

Colonne r montre le nombre de processus en exécution ou en attente CPU :

r  b  swpd  ...  us  sy  id  wa
7  0   0          75 10  5  10

Erreurs

Commande :

dmesg | grep -i "cpu error"

Exemple rare mais possible sur du matériel défectueux :

Hardware Error: CPU0 machine check error

Stratégies de correction

• Prioriser les processus critiques :

  nice -n -5 my_critical_process

• Limiter les CPU disponibles à une application :

  taskset -c 0,1 my_program

• Analyser les surconsommateurs :

  perf top

Contention IO (Disque)

Utilisation

Commande :

iostat -dx 2 3

Sortie :

Device    rrqm/s wrqm/s r/s w/s rkB/s wkB/s %util
sda         0.00   5.00 100 80 4000 2048 95.00

Interprétation : Le disque est sollicité à 95 % → saturation.

Saturation

Commande :

iotop

Sortie :

Total DISK READ: 12.00 M/s | Total DISK WRITE: 3.00 M/s
PID  USER  DISK READ  DISK WRITE  COMMAND
2345 mysql  8.00 M/s   1.00 M/s   mysqld

Interprétation : mysqld monopolise les IO. À surveiller ou optimiser.

Erreurs

Commande :

smartctl -a /dev/sda | grep -i error

Sortie :

Reallocated_Sector_Ct: 12
Reported_Uncorrect: 3

Interprétation : Disque en début de défaillance.

Stratégies de correction

• Migrer vers un SSD/NVMe.

• Mettre en cache les accès disque (Redis, Varnish).

• Activer l’I/O scheduler noop ou deadline :

  echo deadline > /sys/block/sda/queue/scheduler

Contention Réseau

Utilisation

Commande :

iftop -i eth0

Affiche les connexions avec leur débit en temps réel.

Saturation

Commande :

ss -s

Sortie :

TCP: 145 established, 5 timewait, 10 connections in receive queue, 7 in send queue.

Interprétation : Files d’attente TCP actives = saturation réseau.

Erreurs

Commande :

ip -s link

Sortie :

RX:  errors:123  dropped:10
TX:  errors:0    dropped:2

Interprétation : Paquets réseau perdus ou corrompus.

Stratégies de correction

• Limiter les connexions via iptables ou firewalld.

• Activer le tcp_tw_reuse et tcp_fin_timeout :

  sysctl -w net.ipv4.tcp_tw_reuse=1
  sysctl -w net.ipv4.tcp_fin_timeout=15

• Utiliser des CDN ou cache local pour réduire les flux.

Avantages de la méthode USE

• Complémentaire aux outils traditionnels : Elle ne remplace pas top, iotop, vmstat, mais fournit une grille d’analyse systématique.
• Adaptée à la production : Permet de rapidement cerner une panne, même en situation de stress.
• Réutilisable : Appliquable sur tout type de système (Linux, BSD, Windows, appliances réseau, etc.)

Bonnes pratiques

Surveillance Proactive

La surveillance proactive consiste à surveiller régulièrement et systématiquement le système pour détecter les anomalies avant qu’elles ne deviennent critiques. Elle implique :

• Configuration des Alertes : Utiliser des outils comme Nagios, Prometheus, ou Zabbix pour configurer des alertes basées sur des seuils spécifiques de l’utilisation des ressources.

• Analyse des Tendances : Garder des historiques des performances pour identifier les tendances, comme une augmentation progressive de l’utilisation du CPU ou de la mémoire, ce qui peut indiquer un besoin imminent de mise à niveau ou d’optimisation.

• Maintenance Régulière : Effectuer des vérifications régulières et des maintenances, comme les mises à jour du système et des applications, pour garantir que le serveur fonctionne avec les dernières optimisations de sécurité et de performance.

Conclusion

Dans ce chapitre, nous avons exploré en détail les aspects importants de la surveillance et de l’optimisation des performances d’un serveur Linux. Nous avons discuté des outils et techniques pour identifier et résoudre les problèmes liés à la mémoire, au CPU, au réseau et aux opérations d’entrée/sortie (IO), fournissant des exemples concrets d’utilisation des commandes pour une meilleure compréhension pratique.