strace et perf pour le dépannage sous Linux

Lorsqu'un serveur Linux est lent, plante ou surcharge le processeur et que les journaux d'application n'expliquent pas pourquoi, deux outils comblent la plupart des lacunes. strace vous indique ce qu'un processus demande au noyau. perf vous indique où le processeur consacre son temps. Ensemble, ils répondent aux questions « pourquoi est-il bloqué » et « que fait-il », que rien d’autre ne traite aussi efficacement.

Cet article explique quand utiliser chaque outil, comment les installer, les commandes que vous devrez exécuter et comment limiter la charge sur un serveur en production.

Quand utiliser strace ou perf

La distinction est simple. Utilisez perf lorsque le processeur est occupé et que vous devez savoir quelle fonction est en cause. Utilisez strace lorsqu'un processus se bloque, plante, renvoie des erreurs étranges ou se comporte d'une manière que les journaux ne parviennent pas à expliquer.

perf échantillonne les compteurs matériels du noyau à une fréquence configurable, de sorte que la surcharge est généralement inférieure à 1 % et qu'il peut être exécuté en production en toute sécurité. strace intercepte chaque appel système via ptrace, ce qui peut ralentir le processus cible de 10 à 100 fois. Utilisez-le avec parcimonie sur les systèmes en production, et toujours avec des filtres.

Installation de strace et perf

Ces deux outils se trouvent dans les dépôts standard. strace s'appuie sur l' ptrace syscall, qui fait partie de tous les noyaux modernes depuis des années. perf utilise l' perf_events et nécessite un paquet adapté à votre noyau.

Sur Ubuntu ou Debian :

sudo apt install strace linux-tools-common linux-tools-$(uname -r)

Sur RHEL, AlmaLinux ou Fedora :

sudo dnf install strace perf

Le $(uname -r) bit est important. Un binaire perf compilé pour une version de noyau différente produit des résultats confus et peut omettre des événements sans le signaler. Vérifiez avec perf --version et strace -V après l'installation.

Pour que perf affiche les noms de fonctions au lieu des adresses hexadécimales, vous avez besoin des symboles de débogage. Installez le fichier -dbg ou -debuginfo (par exemple, libc6-dbg sur Debian), puis compilez vos propres binaires avec -g dans GCC.

À l'intérieur des conteneurs, strace nécessite --cap-add=SYS_PTRACE et perf est nécessaire --cap-add=SYS_ADMIN lors du lancement avec Docker. Sans ces restrictions, les outils échouent d'une manière qui ressemble à des bugs.

Suivi des appels système avec strace

L'exécution de strace command trace un processus dès son lancement. Pour s'attacher à un processus en cours d'exécution, utilisez strace -p PID. Pour tout ce qui est multithread ou qui se divise, ajoutez -f pour suivre les processus enfants, sinon vous passerez à côté de la majeure partie de l'activité.

Les lignes de sortie se terminent par une valeur de retour. -1 ENOENT signifie que le fichier demandé par le processus n'existe pas. -1 EACCES signifie des problèmes de permissions. À elles seules, ces deux erreurs représentent une part surprenante des bogues en production.

Le drapeau le plus utile est -e trace=GROUP, qui limite la sortie à une catégorie de syscalls nommée et permet de garder le bruit à un niveau raisonnable.

Sur un serveur très sollicité, commencez par strace -c -p PID pendant dix ou vingt secondes. Le -c drapeau affiche un résumé du nombre d'appels système, du temps total et des erreurs lorsque vous vous déconnectez. Cela vous indique quelle catégorie mérite un examen plus approfondi sans saturer le terminal. Reconnectez-vous ensuite avec un filtre plus précis.

Autres indicateurs utiles : -T enregistre le temps passé sur chaque appel, -Z n'affiche que les appels ayant échoué, et -o file écrit dans un fichier journal plutôt que sur le terminal, ce qui est beaucoup plus rapide pour un processus bruyant.

Profilage du CPU avec perf

perf dispose de quatre commandes que vous utiliserez la plupart du temps.

Commencez par perf stat -p PID pour un aperçu rapide. Les chiffres à surveiller :

• IPC (instructions par cycle) inférieur à 1,0 : le processeur est bloqué, généralement lors d'un accès à la mémoire.
• Nombre élevé de LLC-load-misses : le jeu de travail ne tient pas dans le cache, le processeur attend donc la RAM.
• Nombre élevé de changements de contexte : classique pour les charges de travail liées aux E/S où les threads restent bloqués sur le disque ou le réseau.

Si quelque chose semble anormal, poursuivez avec perf record -F 99 -g -p PID -- sleep 30. Les -F 99 échantillonne à 99 Hz, ce qui est suffisant pour trouver les fonctions actives et évite la synchronisation avec le temporisateur du noyau à des fréquences rondes comme 100 Hz. Le -g drapeau capture les graphes d'appel, ce qui perf report puisse vous montrer quels chemins d'accès à une fonction sont responsables.

Dans perf report, la colonne Overhead correspond à la part du total des échantillons. Un overhead élevé dans _int_malloc ou memcpy indique une allocation importante. Une charge élevée dans l’une de vos propres fonctions correspond au point chaud que vous recherchiez.

Si vous voyez des adresses hexadécimales à la place des noms de fonctions, cela signifie que le binaire a été dépouillé ou que les symboles de débogage sont manquants. Installez le -dbg ou recompilez le binaire avec -g.

Un workflow pratique sur un serveur en production

En cas d'incident réel sur un serveur très sollicité, la procédure est la suivante :

1. Vérifiez d'abord le symptôme à l'aide d'outils simples : top, vmstat, iostat. Si vous êtes sur une machine virtuelle, vérifiez la st colonne (steal). Tout chiffre supérieur à 5 % signifie que l'hyperviseur est le goulot d'étranglement, et non votre code.
2. Si l'utilisation du CPU est élevée, exécutez perf top pendant quelques secondes, puis perf record -F 99 -g -p PID -- sleep 30 pour le processus incriminé. Une capture de 30 secondes à 99 Hz produit environ 1,7 Mo de données.
3. Si le processus est bloqué, lent ou renvoie des erreurs, exécutez strace -c -p PID pendant dix secondes et lisez le résumé. Si une catégorie d'appels système domine, affinez la recherche avec strace -e trace=GROUP -T -p PID.
4. Une fois que vous avez identifié l'appel système ou la fonction suspecte, déconnectez-vous. Ne laissez aucun de ces outils tourner en production plus longtemps que nécessaire.

Deux mises en garde. strace La sortie peut inclure des variables d'environnement, des chemins d'accès aux fichiers et des octets lus à partir de sockets ; veillez donc à expurger les journaux avant de les partager en dehors de votre équipe. Et si vous comptez effectuer cette opération régulièrement, envisagez bpftrace et la suite d’outils eBPF comme prochaine étape : même type de visibilité, moins de 1 % de surcharge, conçue pour la production dès le départ.

Si vous exécutez des charges de travail pour lesquelles un accès diagnostique approfondi est essentiel et qu'une infrastructure partagée n'est pas envisageable, jetez un œil à nos serveurs dédiés.