Résumer le temps passé dans les appels système avec strace -c, son surcoût et perf trace comme alternative

Objectif

Obtenir un résumé classé des appels système dans lesquels un processus passe son temps, plutôt qu'une trace en direct qui défile, et savoir quand le traçage devient lui-même le goulot d'étranglement.

Prérequis

Le paquet strace. Tracer une commande que l'on lance soi-même (strace -c <command>) ne demande aucun privilège particulier ; s'attacher à un processus en cours avec -p exige root ou CAP_SYS_PTRACE, sauf si le paramètre Yama kernel.yama.ptrace_scope l'autorise (avec la valeur courante 1, un utilisateur non privilégié ne peut s'attacher qu'à ses propres descendants). perf si l'alternative de l'étape 4 est nécessaire.

Étapes

1. S'attacher pour une durée limitée, puis se détacher, par exemple avec timeout 20 strace -c -f -p <pid> ; sans -f, -p ne s'attache qu'au seul thread dont l'identifiant est <pid> et ignore les threads de travail d'un serveur multithread. Le manuel de strace décrit -c/--summary-only comme l'option qui comptabilise le temps, les appels et les erreurs pour chaque appel système et affiche un résumé à la sortie, en supprimant la sortie habituelle appel par appel. C'est la vue agrégée dont a besoin la question « quel appel système domine ? ». Le manuel précise aussi que ce temps est le temps système (temps CPU du noyau), indépendant du temps réel (wall-clock).
2. Lire d'abord le résumé trié par pourcentage de temps. Comme la mesure par défaut est le temps CPU du noyau, les appels qui bloquent surtout (futex, epoll_wait, un read sur socket) y paraissent peu coûteux ; ajouter -w/--summary-wall-clock pour classer les appels selon le temps réel écoulé entre l'entrée et la sortie lorsque la question est de savoir où le processus attend. Un temps élevé dans futex ou epoll_wait indique alors de la contention ou de l'attente inactive, et dans read/write des entrées-sorties.
3. Connaître le coût avant de se fier aux chiffres : le manuel de strace indique clairement qu'un processus tracé s'exécute plus lentement qu'un processus non tracé, et que l'impact sur les performances peut être atténué avec l'option --seccomp-bpf. Cette option n'a d'effet qu'avec -f, ne s'applique pas aux processus attachés avec -p, et n'économise des arrêts que si seul un sous-ensemble d'appels est tracé (-e trace=...) ; elle n'aide donc pas dans le cas ci-dessus (attachement puis comptage). Pour un processus sensible à la latence, ce surcoût peut lui-même modifier le comportement observé.
4. Lorsque ce surcoût pose problème, utiliser perf trace à la place. Son manuel le présente comme un outil inspiré de strace, qui rapporte le même type d'activité (appels système et événements système), en direct ou à partir d'une session perf record enregistrée au préalable, et qui repose sur l'infrastructure de tracepoints et perf_events du noyau plutôt que sur ptrace. Essayer perf trace -p <pid> pour une vue en direct, ou perf trace -s -p <pid> pour un résumé par thread avec les temps minimum, moyen et maximum ; il nécessite normalement root.
5. Ne pas supposer un écart de pourcentage fixe entre les deux outils sans mesurer sur la charge de travail réelle ; aucun des deux manuels n'indique de chiffre de surcoût, et le coût relatif dépend de l'intensité des appels système de la charge.

Résultat attendu

Une liste triée des appels système qui ont consommé le plus de temps et de leur fréquence d'appel, obtenue sans trace complète ligne par ligne, ainsi qu'un choix éclairé entre la simplicité de strace -c et le profil de surcoût différent de perf trace.

Limites et base de vérification

Les deux outils ne voient l'activité qu'à partir de l'attachement ; un pic antérieur leur échappe. -f/--follow-forks est nécessaire pour comptabiliser aussi les appels des processus enfants et, avec -p, ceux des autres threads. Il faut se détacher rapidement une fois le résumé obtenu, car le surcoût s'applique pendant toute la durée de l'attachement, et pas seulement pendant la lecture de la sortie.