Dans les systèmes Linux, l'analyse de l'utilisation des ressources (processeur, mémoire, espace disque, Entrées/Sorties disque) constitue une compétence fondamentale pour les administrateurs système et les développeurs. Ci-dessous, vous trouverez une méthodologie détaillée pour ces quatre dimensions, ainsi que les commandes essentielles et des exemples concrets.

Analyse de l'utilisation Processeur

Lorsque le système devient lent ou que les temps de réponse des services augmentent, la première étape consiste à examiner le processeur.

1. Commandes principales : top / htop

• top : outil natif du système, actualisation en temps réel.
• htop : version améliorée de top, avec support des couleurs, interaction souris et vue arborescente (installation requise : yum install htop ou apt install htop).

Procédure d'utilisation :

1. Exécuter top et valider.
2. Tri : le tri par défaut s'effectue sur le processeur. Si ce n'est pas le cas, appuyez sur la touche P (majuscule) pour forcer le tri par taux d'utilisation CPU.
3. Visualisation des threads : après avoir identifié le processus problématique (PID), appuyez sur H (majuscule) pour afficher les threads et identifier celui qui consomme le plus de ressources.
4. Analyse du code : notez le PID et l'identifiant du thread (TID), puis utilisez jstack (Java) ou gdb (C++) pour analyser la pile d'exécution.

Interprétation de la sortie :

PID USER      PR  NI    VIRT    RES    SHR S  %CPU  %MEM     TIME+ COMMAND
1024 www-data  20   0  500000 200000  10000 R  99.0   5.0   10:00.00 php-fpm

• %CPU : 99.0 indique une pleine utilisation d'un cœur.
• COMMAND : nom du processus.

2. Commande avancée : pidstat (paquet sysstat)

Permet de visualiser l'historique ou les détails d'utilisation CPU d'un processus spécifique.

# Échantillonnage toutes les secondes, 5 itérations, détails CPU de tous les processus
pidstat -u 1 5

# Afficher l'utilisation CPU par thread pour un PID spécifique (ex: 2048)
pidstat -t -p 2048 1

• -u : taux d'utilisation CPU.
• -t : données au niveau thread.
• %usr : espace utilisateur.
• %system : espace noyau (valeurs élevées peuvent indiquer des appels système fréquents ou des problèmes de pilotes).

3. Flame Graph - Méthode ultime

Si top révèle un CPU élevé sans identifier la cause, utilisez perf pour générer un flame graph.

# Enregistrer 10 secondes de données
perf record -F 99 -p <PID> -g -- sleep 10
# Générer le flame graph (installation préalable des scripts flamegraph requise)
perf script | stackcollapse-perf.pl | flamegraph.pl > cpu.svg

L'ouverture de cpu.svg permet de visualiser直观ement la fonction la plus chronophage.

Analyse de la mémoire (RAM)

Des fuites mémoire ou un cache saturé peuvent déclencher le mécanisme OOM (Out Of Memory) qui termine les processus.

1. Commandes principales : free & top

• free -h : visualiser la distribution globale de la mémoire.

free -h
# Surveiller la colonne available, et non free. Linux utilise la mémoire libre pour le cache/buffer.

• top : appuyez sur M (majuscule) pour trier par utilisation mémoire.
• RES : mémoire résidente (occupation physique réelle, indicateur le plus important).
• VIRT : mémoire virtuelle (inclaunt la mémoire non allouée, utilité limitée).

2. Localisation précise : commande ps

Pour un instantané unique avec tri :

# Trier par utilisation mémoire, afficher les 10 premiers processus
ps aux --sort=-%mem | head -n 11

• RSS : correspond à RES dans top, en Ko.

3. Analyse approfondie : smem ou /proc

Visualiser l'utilisation réelle de la mémoire partagée (RSS dans top inclut la mémoire partagée, ce qui peut fausser le total).

# Installer smem (pip install smem ou apt install smem)
smem -r -k  # Tri après répartition proportionnelle de la mémoire partagée

Ou consulter directement le mapping mémoire détaillé du processus :

cat /proc/<PID>/status | grep -i vm
# Surveiller VmRSS (mémoire physique réelle) et VmData (mémoire du heap)

4. Journaux du tueur OOM

Si un processus disparaît brutalement, vérifier s'il a été terminé par le système :

dmesg -T | grep -i "out of memory"
# ou
grep -i "killed process" /var/log/syslog

Analyse de l'espace disque

Un disque saturé empêche l'écriture des journaux ou provoque l'effondrement des bases de données.

1. Commande principale : df

Visualiser le taux d'utilisation par point de montage.

df -hT

• -h : format lisible (Go/Mo).
• -T : afficher le type de système de fichiers.
• Point focal : surveiller les partitions avec Use% proche de 100%.

2. Localiser les fichiers/répertoires volumineux : du

Une fois le point de montage identifié, déterminer quel répertoire est responsable.

# Depuis la racine, calculer la taille des sous-répertoires de premier niveau, trier, afficher les 10 premiers
du -h --max-depth=1 / | sort -hr | head -n 10

# Recherche récursive des fichiers de plus de 1 Go
find / -type f -size +1G -exec ls -lh {} \;

• Astuce : si du est trop lent, utilisez ncdu (NCurses Disk Usage), outil interactif, extremely rapide et intuitif.

ncdu /

3. Cas particulier : fichier supprimé mais espace non libéré

Après avoir supprimé un gros fichier journal, df peut still indiquer un espace utilisé. Cela signifie qu'un processus conserve encore un descripteur sur ce fichier.

# Rechercher les fichiers supprimés mais toujours ouverts par des processus
lsof +L1

• Solution : redémarrer le processus concerné, ou vider le descripteur dans /proc/<PID>/fd/ (non recommandé, le redémarrage est preferrable).

Analyse des Entrées/Sorties disque

Un CPU en attente d'E/S (iowait) élevé signale généralement un goulot d'étranglement sur les opérations de lecture/écriture.

1. Commande principale : iostat (paquet sysstat)

Visualiser la charge globale des disques.

iostat -x 1

• -x : afficher les statistiques extendues.
• 1 : rafraîchissement chaque seconde.
• Indicateurs clés :
• %util : taux d'utilisation du disque. Proche de 100% = saturation.
• await : temps d'attente moyen par opération E/S (ms). Élevé (>20ms) = disque lent.
• r/s, w/s : lectures/écritures par seconde.

2. Localiser les processus E/S intensives : iotop

Similaire à top, mais orienté E/S disque.

# Nécessite les droits root
sudo iotop -oPa

• -o : afficher uniquement les processus effectuant des E/S.
• -P : afficher les processus seulement, pas les threads.
• -a : afficher accumulativement les volumes E/S.
• Surveiller : les colonnes DISK WRITE ou DISK READ les plus élevées.

3. Détails E/S par processus : pidstat

# Statistiques E/S par processus, actualisation chaque seconde
pidstat -d 1

• kB_rd/s : Ko lus par seconde.
• kB_wr/s : Ko écrits par seconde.
• iodelay : temps de blocage E/S.

4. Surveillance temps réel des accès fichiers : fatrace (File Access Trace)

Pour identifier précisément quel fichier est fréquemment lu/écrit (plutôt que quel processus) :

sudo fatrace
# Exemple de sortie :
# bash(1234): /var/log/syslog OPEN
# mysql(5678): /var/lib/mysql/ibdata1 WRITE

(Note : certaines anciennes distributions peuvent nécessiter l'activation du système audit ou l'utilisation de auditctl)

Synthèse de la méthodologie d'analyse (Aide-mémoire)

Symptôme	Étape 1 (Aperçu)	Étape 2 (Localisation processus)	Étape 3 (Analyse approfondie)
Système lent	top (load average, %CPU, %wa)	top (tri par P)	pidstat -u, perf
Mémoire insuffisante	free -h (available)	top (tri par M)	smem, dmesg (OOM)
Disque saturé	df -h	du -h --max-depth=1	ncdu, lsof +L1
Attente E/S élevée	iostat -x 1 (%util, await)	iotop -oPa	pidstat -d, fatrace

Étude de cas pratique

Contexte : Serveur extrémement lent, connexion SSH avec délai.

1. Diagnostic initial : Exécuter top.

• Load average élevé (ex: 20.00).
• %id (idle) faible, mais %wa (iowait) à 80%.
• Conclusion : Pas une surcharge CPU, mais les E/S disque sont bloquantes.

2. Identifier le responsable : Quitter top, exécuter sudo iotop -oPa.

• Le processus java (PID 5432) montre un DISK WRITE continu de 50 Mo/s.

3. Analyser la cause : Exécuter pidstat -d -p 5432 2 pour confirmer le volume d'écriture. En examinant les journaux métier, l'application Java génère simultanément des logs DEBUG vers le disque.
4. Résolution :

• Temporaire : Ajuster le niveau de logs ou mettre le service en pause.
• Définitif : Modifier logback.xml pour désactiver les logs DEBUG, optimiser la logique applicative.

L组合 de ces commandes permet, tel un médecin, de localiser rapidement la "pathologie" du système Linux à partir des "symptômes" observés.