21 - Performance et diagnostic

Ce que tu vas apprendre

• Lire et interpréter le load average
• Comprendre la mémoire avec free et la swap
• Regler le swappiness
• Analyser les I/O disque avec iostat
• Tracer les appels système avec strace
• Utiliser vmstat et dmesg pour le diagnostic

Prerequisites

Connaitre les processus et les bases du stockage.

Mon application etait lente. Le CPU n'etait qu'a 20%. La mémoire, 60%. Le disque, a peine utilise. Et pourtant, les requêtes mettaient 5 secondes au lieu de 200 millisecondes. J'ai passe des heures a chercher dans le code avant de découvrir avec iostat que le disque avait un temps de latence énorme. Un disque réseau qui faisait des siennes. Le code n'avait rien. Le problème etait sous le code, au niveau du système. C'est pour ca que savoir diagnostiquer les performances Linux est une competence qui te fera gagner des heures.

Load average : la charge système

Le load average est le premier indicateur a regarder :

bash# Trois facons de le voir
uptime
# 14:32:01 up 45 days, load average: 1.25, 0.98, 0.76

cat /proc/loadavg
# 1.25 0.98 0.76 2/487 12345

top
# En haut a droite

Les trois nombres representent la charge moyenne sur 1, 5 et 15 minutes. Mais que signifie "charge" ?

Le load average compte les processus qui sont soit en train de s'exécuter, soit en attente de CPU, soit en attente d'I/O disque. Sur un système avec 4 coeurs :

• Load 1.0 : un coeur est occupe a 100%, les trois autres sont libres
• Load 4.0 : les 4 coeurs sont occupes a 100%, aucune file d'attente
• Load 8.0 : les 4 coeurs sont a 100% et 4 processus attendent leur tour

bash# Connaitre le nombre de coeurs
nproc

# Regle simple : si le load depasse le nombre de coeurs, le systeme est sature

Si le load 1 minute est haut mais le load 15 minutes est bas, c'est un pic temporaire. Si les trois valeurs sont hautes, c'est un problème chronique.

free : la mémoire en détail

bashfree -h
#               total        used        free      shared  buff/cache   available
# Mem:          7.7Gi       3.2Gi       512Mi       256Mi       4.0Gi       4.0Gi
# Swap:         2.0Gi       128Mi       1.9Gi

La colonne qui compte, c'est available, pas free. Linux utilise la mémoire "libre" comme cache disque (buff/cache). Ce cache est libéré instantanement si une application en a besoin. Donc un système avec peu de free mais beaucoup de available se porte tres bien.

bash# Surveiller la memoire en continu (toutes les 2 secondes)
watch -n 2 free -h

Si available est proche de zero et que Swap used augmente, la tu as un vrai problème de mémoire.

Swap et swappiness

La swap est un espace disque utilise quand la RAM est pleine. C'est beaucoup plus lent que la RAM :

bash# Voir la swap
swapon --show

# Voir l'utilisation
free -h

# Creer un fichier de swap (2 Go)
sudo fallocate -l 2G /swapfile
sudo chmod 600 /swapfile
sudo mkswap /swapfile
sudo swapon /swapfile

# Rendre permanent dans /etc/fstab
echo '/swapfile none swap sw 0 0' | sudo tee -a /etc/fstab

Le swappiness contrôle l'empressement du kernel a utiliser la swap :

bash# Voir la valeur actuelle (defaut: 60)
cat /proc/sys/vm/swappiness

# Reduire temporairement (prefere garder les choses en RAM)
sudo sysctl vm.swappiness=10

# Rendre permanent
echo 'vm.swappiness=10' | sudo tee -a /etc/sysctl.d/99-swappiness.conf

Sur paltemps.fr, je mets le swappiness a 10 sur les serveurs d'application. Je préféré que le système garde les processus en RAM le plus longtemps possible. La swap, c'est un filet de sécurité, pas un mode de fonctionnement normal.

iostat : les I/O disque

Quand le load average est haut mais le CPU est bas, c'est souvent les I/O disque :

bash# Installer
sudo apt install sysstat

# Voir les statistiques disque
iostat -x 2 5
# Affiche les stats toutes les 2 secondes, 5 fois

# Colonnes importantes :
# %util   - Pourcentage de temps ou le disque travaille (100% = sature)
# await   - Temps moyen d'attente par requete (en ms)
# r/s     - Lectures par seconde
# w/s     - Ecritures par seconde

Un %util proche de 100% signifie que le disque est le goulot d'etranglement. Un await eleve (>20ms sur un SSD) indique un problème de latence.

bash# Voir quel processus fait des I/O
sudo iotop

# Version non-interactive
sudo iotop -b -n 1 | head -20

vmstat : vue d'ensemble en temps réel

vmstat donne un aperçu synthetique du système :

bashvmstat 2 10
# Affiche toutes les 2 secondes, 10 fois

# procs -----------memory---------- ---swap-- -----io---- -system-- ------cpu-----
#  r  b   swpd   free   buff  cache   si   so    bi    bo   in   cs  us sy id wa st
#  1  0  12800 524288  65536 4194304    0    0     5    20  150  300  15  3 80  2  0

Les colonnes clés :

• r : processus en attente de CPU (si > nombre de coeurs, le CPU est sature)
• b : processus bloques sur I/O
• si/so : swap in/out (si > 0 régulièrement, la RAM est insuffisante)
• wa : pourcentage de temps CPU passe a attendre les I/O
• us : temps CPU en espace utilisateur
• sy : temps CPU en espace kernel

strace : tracer les appels système

Quand tu ne comprends pas ce que fait un processus, strace te montre chaque appel système :

bash# Tracer un programme
strace ls /tmp

# Tracer un processus en cours
sudo strace -p 12345

# Filtrer par type d'appel
strace -e trace=network curl https://example.com
strace -e trace=file cat /etc/passwd
strace -e trace=write echo "hello"

# Avec un resume statistique
strace -c ls /tmp
# % time     seconds  usecs/call     calls    errors syscall
# ------ ----------- ----------- --------- --------- ----------------
#  45.00    0.000090           3        30           read
#  25.00    0.000050           2        25         3 openat

strace -c est mon favori. En une commande, tu vois ou le temps est passe : est-ce que c'est les lectures disque, les appels réseau, les ouvertures de fichier ? Ca oriente le diagnostic instantanement.

time : mesurer le temps d'exécution

bash# Mesurer le temps d'une commande
time find / -name "*.log" 2>/dev/null

# real    0m2.345s   <- temps "horloge" (ce que tu attends)
# user    0m0.456s   <- temps CPU en espace utilisateur
# sys     0m0.789s   <- temps CPU en espace kernel

Si real est beaucoup plus grand que user + sys, le processus attend quelque chose : I/O disque, réseau, ou un autre processus.

dmesg : les messages du kernel

dmesg montre les messages du kernel Linux. C'est la que tu trouves les erreurs materiel, les OOM kills et les problèmes de drivers :

bash# Voir les messages recents
dmesg --since "5 minutes ago"

# Suivre en temps reel
dmesg -w

# Filtrer par niveau
dmesg --level=err,warn

# Chercher les OOM kills (Out Of Memory)
dmesg | grep -i "oom"

# Chercher les erreurs disque
dmesg | grep -i "error"

Quand un processus disparaît mysterieusement, dmesg te dira si c'est l'OOM killer qui l'a tue :

bashdmesg | grep -A 5 "Out of memory"
# Out of memory: Killed process 12345 (mon-app) total-vm:2048000kB

Résumé

• Load average : comparer avec le nombre de coeurs (nproc)
• free -h : regarder available, pas free
• Swappiness a 10 sur les serveurs d'application
• iostat -x pour diagnostiquer les I/O disque, %util et await sont les clés
• vmstat pour une vue d'ensemble CPU/mémoire/swap/IO
• strace -c pour savoir ou un processus passe son temps
• dmesg pour les erreurs kernel, OOM kills et problèmes materiel

Article précédent : Securiser un serveur Linux Article suivant : tmux : le multiplexeur de terminal

Sources

• iostat(1) - Linux manual page
• strace(1) - Linux manual page
• Linux Performance - Brendan Gregg