CPU, charge et strace

Prérequis : cours 1.2-1.3 (load, nice, PSI).

Pourquoi

« Load à 40 » : qui, quoi, et est-ce grave ? CPU = le plus simple à diagnostiquer quand on lit les bons compteurs (user vs sys vs iowait vs steal !) — et strace révèle ce que le process fait vraiment.

Concepts

• Lire top : %us (applicatif), %sy (noyau — syscalls en masse ?), %wa (I/O wait — en fait du idle déguisé : le CPU attend le disque !), %st (steal : l'hyperviseur prend pour d'autres VM = voisin bruyant en cloud).
• Load vs CPU : load = file d'attente (CPU + I/O ininterruptible !). Load haute + CPU idle + wa haut = problème DISQUE, pas CPU.
• strace : tracer les appels système (strace -p PID -c : résumé par syscall, -e trace=network,file : filtrer). Révèle : boucles sur fichiers absents (ENOENT en masse), DNS qui timeout, locks.
• perf top (bonus) : fonctions chaudes du noyau/appli quand strace ne suffit plus.

Exemple : diagnostic en 3 temps

top (1 = par CPU)         # qui ? us/sys/wa/st ?
pidstat -d 1 / pidstat -u  # confirme disque vs cpu par process
sudo strace -p <pid> -c -e trace=file,network  # que fait-il vraiment ?

Cas réel

API à 100 % CPU : top montre %sy à 80 % (noyau !), strace : millions de stat() sur un fichier de conf absent (boucle de retry sans cache). ENOENT en masse = l'app cherche quelque chose qui n'existe pas. Fix applicatif en 1 ligne, CPU /10.

Pièges

• %wa traité comme charge CPU : c'est de l'attente I/O — scaler le CPU ne sert à rien, c'est le disque.
• %st élevé ignoré : voisin bruyant (cloud mutualisé) — migrer d'instance, pas optimiser.
• strace en prod sans filtre : verbeux + ralentit la cible (-c résumé d'abord, -p ciblé, jamais en aveugle large).

À retenir

us/sys/wa/st lus séparément, load = file (CPU+I/O), strace = vérité des syscalls, steal = voisin.