Passer au contenu 
Les tracepoints du noyau me permettent de comprendre les problèmes de performances sous Linux jusqu’au niveau du noyau et de mesurer précisément où le temps est perdu. Je les utilise pour Points de mesure, afin de surveiller les processus au sein du planificateur, de la pile d'E/S et du chemin réseau – avec un effort supplémentaire minime et des données d'événements claires.
Points centraux
Les points clés suivants te donnent un aperçu rapide de ce à quoi je fais attention lorsque je travaille avec des tracepoints.
- Statique Les événements ancrés fournissent des données fiables à des endroits clés du code.
- Faible surcoût rend le traçage réalisable même en cas de charge élevée.
- Un vaste écosystème avec ftrace, perf, LTTng et les outils eBPF.
- Activation ciblée et le filtrage permet d'éviter les flux de données excessifs.
- Combinaison à l'aide de compteurs de performances, il met en évidence les chaînes de causes.
Je garde la liste concise et je me concentre sur les Priorités de l'analyse. Ainsi, je ne perds pas de temps dans des détails secondaires et je garde un œil sur les signaux les plus importants. Les points mentionnés guident mon travail pratique, depuis le premier soupçon jusqu'à l'optimisation vérifiée. Cela me permet de créer Transparence et la reproductibilité. Je m'appuie toujours sur les données et je contrôle chaque étape.
Que sont les points de trace du noyau ?
Un point de trace est un point d'instrumentation statique dans le code du noyau qui déclenche un événement comportant des champs structurés. J'y vois notamment PID, horodatage, CPU, codes d'état ou informations de taille, selon l'événement. À l'aide de macros telles que TRACE_EVENT, le noyau définit l'emplacement, le format et les données fournies. Ces événements se situent au niveau d'interfaces pertinentes telles que la planification, les E/S en bloc, les systèmes de fichiers ou le chemin réseau. Je peux les activer à tout moment sans avoir à modifier le noyau ni à mettre en danger les systèmes de production, ce qui me Sécurité de la planification là.
Pourquoi utiliser des points de trace pour mesurer les performances ?
Les points de trace ne génèrent pratiquement aucun coût lorsqu'ils sont inactifs et n'ajoutent qu'une faible charge supplémentaire lorsqu'ils sont activés. Même lorsque les événements sont activés, je ne mesure généralement qu'une latence supplémentaire de l'ordre de quelques dizaines de nanosecondes, ce qui est suffisant pour les systèmes soumis à des exigences strictes Objectifs de latence. Comme elles sont solidement ancrées dans le noyau, je peux répéter mes analyses de manière cohérente d'une version du noyau à l'autre. Leur sortie structurée peut être analysée et traitée de manière fiable. Cela me permet de gagner fiable Des mesures plutôt que des fragments de journal obscurs.
Horodatage, horloges et ordre chronologique
Pour interpréter correctement les latences, je tiens compte de la source de temps utilisée. Les horloges monotones (par exemple CLOCK_MONOTONIC) sont plus fiables pour les mesures que le temps réel, car les corrections NTP n’ont pas d’effet rétroactif. Sur les systèmes multicœurs, les tampons par CPU fournissent des événements dont l'ordre est correct au niveau local du CPU, mais qui ne sont comparables entre les différents CPU qu'à l'aide d'horodatages. Je calibre donc la vue : soit je trie les événements par processeur, soit j’utilise des outils qui synchronisent les tampons et résolvent correctement les conflits de chronologie. Lorsque les budgets sont très serrés, je vérifie si la base TSC est stable, afin que les écarts ne soient pas interprétés à tort comme de la gigue. J’évite ainsi les interprétations erronées lorsque, par exemple, des réveils se produisent sur le processeur 3 et des changements de contexte sur le processeur 7.
Aperçu de l'écosystème de traçage sous Linux
J'utilise plusieurs outils qui s'appuient tous sur les mêmes événements Tracepoint. ftrace permet une activation rapide via le système de fichiers de traçage et convient aux vérifications ponctuelles avec Vue en direct. Avec perf, j'associe des points de trace, des compteurs matériels et l'échantillonnage afin de mettre en évidence les corrélations. LTTng permet d'enregistrer des données sur de longues durées avec un taux d'événements élevé et une faible charge supplémentaire, ce qui est essentiel pour des analyses approfondies. Les outils basés sur eBPF lisent les points de trace, effectuent des agrégations au niveau du noyau et réduisent ainsi trafic de données dans l'espace utilisateur.
Tampon circulaire et contrôle des pertes
Derrière chaque événement actif se trouve un tampon circulaire par processeur. Je dimensionne ces tampons de manière à amortir les pics de charge sans que les événements ne soient rejetés. Les compteurs de pertes et les avertissements des outils sont importants : Avec perf, je surveille les compteurs d’événements perdus ; avec ftrace, je vérifie les statistiques de perte dans tracefs. LTTng signale également lorsque le chemin du consommateur ne suit pas. En cas de perte, j’augmente la taille des tampons, j’affine le filtrage ou j’agrège plus tôt. Pour les scénarios de type „ enregistreur de vol “, j’utilise des instantanés qui conservent une période autour d’un déclencheur. Je maintiens ainsi une qualité élevée des données et j’évite les hypothèses erronées basées sur des traces incomplètes.
Choix des outils : ftrace, perf, LTTng, eBPF
Je commence souvent par « perf », car cela me permet d'analyser simultanément l'échantillonnage, les valeurs de comptage et les points de trace. Pour des inspections rapides des événements, j'utilise « ftrace » et j'active de manière ciblée Événements libre. J'utilise volontiers LTTng pour les sessions complexes et de longue durée impliquant de nombreux processeurs, car il enregistre de manière fiable des débits élevés. Si je souhaite effectuer un pré-agrégat au niveau du noyau, j'utilise des traceurs basés sur eBPF afin d'exporter uniquement des indicateurs agrégés. Ceux qui souhaitent approfondir leurs connaissances sur perf trouveront des conseils pratiques dans l’article consacré à outil perf, ce qui aide aussi bien les débutants que les utilisateurs confirmés.
Reproductibilité et automatisation des sessions
Je consigne les paramètres des sessions réussies : événements activés, filtres, tailles de tampon, taux d’échantillonnage et durée d’exécution. Je note également la version du noyau, les versions des outils, la topologie du processeur et les paramètres d’alimentation, afin de pouvoir comparer les mesures ultérieures. Je peux ainsi, si nécessaire, répéter une session à l’identique, la transférer vers d’autres hôtes ou l’automatiser dans des pipelines d’intégration continue (CI). Pour les analyses plus longues, je sauvegarde les données brutes et génère des résumés (histogrammes, centiles, cartes thermiques) immédiatement après la mesure. Je travaille de manière itérative : exécutions courtes et ciblées, évaluation, affinement de l'hypothèse, puis nouvelle mesure. De cette manière, je ne me perds pas dans les données, mais j'aboutis à des conclusions fiables avec un temps de boucle minimal.
Scénarios d'utilisation concrets
Au niveau du planificateur, j'observe les changements de contexte, les réveils et les interactions avec les files d'attente afin de mettre en évidence les changements excessifs ou les priorités inappropriées. Dans la pile de blocs, je mets en corrélation la soumission et l'achèvement des requêtes avec la profondeur et la taille des files d'attente, ce qui me permet de détecter Stockage- les goulots d'étranglement. Sur le chemin réseau, je surveille l'entrée et la sortie des paquets ainsi que les files d'attente afin de comprendre les chaînes de latence par flux. Pour les appels système, j’examine leur fréquence et leur latence afin d’identifier les anomalies dans les chemins critiques. Si nécessaire, je combine ces données avec les compteurs matériels afin que les échecs de cache, les erreurs de prédiction de branche et les événements d’E/S puissent être chaîne de causes se produisent.
Noms concrets d'événements et interprétation des champs
Je choisis les événements de manière à pouvoir reconstituer entièrement le parcours à partir d'un petit nombre de points de repère. Voici un ensemble de base qui a fait ses preuves :
- Planificateur : sched:sched_switch (commande précédente/suivante, état précédent), sched:sched_wakeup et sched:sched_wakeup_new (source de réveil, CPU cible)
- E/S par blocs : block:block_rq_issue, block:block_rq_complete (secteurs, taille, périphérique, latence via Delta)
- Réseau : net:net_dev_queue, net:netif_receive_skb (mise en file d'attente et réception), tcp:tcp_retransmit_skb (retransmissions)
- Appels système : syscalls:sys_enter_*, syscalls:sys_exit_* (durée par appel, codes d'erreur)
Je vérifie au préalable la signification des champs afin d'établir des corrélations correctes : dans « prev_state », je repère les tâches en veille ; dans les champs CPU, j'identifie les migrations d'un socket à l'autre. Pour les événements réseau, j'intègre, lorsqu'elles sont disponibles, les métadonnées de flux (par exemple les ports) afin de regrouper les latences par connexion. J'obtiens ainsi des chemins qui correspondent effectivement au comportement observé au niveau du service.
Étape par étape : de la question à la session Traces
Je commence toujours par poser une question précise, par exemple : „ Pourquoi les temps de réponse augmentent-ils pendant les pics de charge ? “ Cette étape m'oblige à trouver la bonne Sous-système à choisir : planificateur, réseau, bloc, système de fichiers ou gestion de la mémoire. Je répertorie ensuite les points de trace appropriés à l’aide de la commande „ perf list “ ou dans le système de fichiers de traçage, puis je note les champs pertinents. Je configure la session, j’applique des filtres sur les champs PID, CPU ou événement, et je définis la taille du tampon ainsi que la durée. Ensuite, j’exécute le scénario de charge, puis j’analyse les distributions de latence, les séquences et les corrélations avant de vérifier une hypothèse et de mesurer à nouveau la modification afin de déterminer le Effet à confirmer.
Filtrage et corrélation : PID, TID, cgroups et flux
Des filtres précis me font gagner du temps. En fonction de l'objectif visé, j'utilise des filtres PID/TID, la sélection par CPU ou des filtres cgroup afin de respecter les limites des conteneurs ou des services. Dès que je souhaite comprendre la latence réseau, je corrèle les événements via les attributs de flux (par exemple, le port source/destination) afin de distinguer le trafic en masse des flux sensibles à la latence. Pour les fichiers, j’effectue un mappage par périphérique/adresse de bloc ou je regroupe par point de montage, selon l’outil utilisé. Dans le domaine de la planification, je mesure le temps écoulé entre le réveil et le premier sched_switch sur le processeur cible ; cela me permet de distinguer le temps d’attente dans les files d’attente d’exécution du temps CPU proprement dit.
Gérer les frais généraux : bonnes pratiques
Je n'active que les points de trace dont j'ai réellement besoin, afin de limiter le volume de données et la charge supplémentaire. Les filtres par PID, CPU ou champs permettent de réduire le bruit et de préserver les ressources. Tampon. J'adapte la taille du tampon au débit d'événements afin de ne perdre aucun événement. Je limite clairement la durée des sessions et ne les répète que si je souhaite tester une hypothèse. En cas d’événements extrêmement fréquents, j’ai recours à l’échantillonnage ou à l’agrégation au niveau du noyau via eBPF, afin que l’analyse dans l’espace utilisateur mince reste.
Comparaison : points de trace et événements de performance
Ces deux approches se complètent. Les points de trace expliquent des événements concrets au sein des sous-systèmes et fournissent des informations pertinentes Champs. Les événements de performance me donnent un aperçu statistique des cycles, des échecs de cache ou des branchements. En combinant ces éléments, je peux identifier le temps perdu et l'étape qui pose problème. Le tableau suivant m'aide à choisir les outils et met l'accent sur ce dont j'ai besoin pour la prochaine série de mesures. Il me sert de Liste de favoris pour l'organisation de la session.
| Aspect | Points de trace | Événements de performance (perf) |
|---|---|---|
| Stabilité | Événements statiques au niveau du noyau, largement indépendants de la version | Dépend des compteurs matériels et de l'implémentation du noyau |
| Overhead | Faible, axé sur les événements | Très faible lors de l'échantillonnage |
| Focus sur | Événements concrets au niveau des sous-systèmes | Indicateurs à l'échelle du système |
| Format des données | Structuré, lisible par machine | Valeurs de comptage, échantillons, profils |
| Utilisation typique | „Le “ quoi „ et le “ quand » d’un parcours | „ Quelle quantité ? “ et „ Combien ça coûte ? “ |
J'aime commencer par des événements de performance pour localiser un goulot d'étranglement général, puis j'affine mon analyse à l'aide de points de trace. À l'inverse, j'active d'abord les points de trace lorsque je souhaite comprendre un chemin d'exécution, puis j'ajoute ensuite des compteurs pour Quantification. Cet ordre permet de gagner du temps et garantit une collecte de données ciblée. Il est important de surveiller le taux d'événements afin d'éviter toute perte de données. C'est ainsi que je reste à jour avec discipline de mesure en bonne voie.
Limites, validation et recoupements
Tous les chemins d'accès aux pilotes ne sont pas systématiquement instrumentés, et certaines erreurs rares n'apparaissent pas dans les traces. C'est pourquoi je recoupe les mesures avec d'autres sources d'information : compteurs, journaux, tests synthétiques, mais aussi de simples mesures de temps au sein même du service. Lorsque les traces et les compteurs ne concordent pas, je vérifie d’abord les filtres et les pertes de données, puis la base d’horloge. Je prête également attention aux interférences : les versions de débogage, les taux de journalisation élevés ou les hooks de sécurité peuvent décaler les latences. Ce n’est qu’à l’aide de recoupements que je m’assure qu’une cause identifiée constitue bel et bien le levier d’optimisation.
Exemple : mesurer les latences de stockage
J'active des points de trace dans la pile de blocs pour l'envoi et la finalisation des requêtes d'E/S. Pendant l'exécution d'un test de charge, j'enregistre l'horodatage, la taille de la requête, le périphérique et le PID afin de Latence pour chaque processus. Ensuite, je trie les résultats par durée et je génère des histogrammes qui mettent en évidence les pics et les valeurs aberrantes. Lors d’un deuxième passage, j’ajoute les compteurs CPU afin de vérifier s’il existe un lien entre la charge de calcul et les latences d’E/S. Enfin, j’ajuste le planificateur d’E/S, la profondeur de la file d’attente ou le backend de stockage, puis je répète la mesure jusqu’à ce que la Objectifs ont été atteints de manière fiable.
Exemple : comprendre les latences du planificateur et du réveil
Lorsque les threads présentent un comportement „ spiky “, je mesure le temps écoulé entre `sched:sched_wakeup` et le premier `sched:sched_switch` sur le processeur cible. Cela me permet de distinguer le temps d'attente dans les files d'attente d'exécution du temps d'exécution réel. Je regroupe les données par CPU, priorité et politique (CFS/RT) afin de détecter les incohérences – par exemple, lorsque des threads très gourmands en ressources CPU se retrouvent sur des cœurs surchargés alors que des cœurs libres sont disponibles. Si j’observe de nombreux réveils inter-processeurs, je vérifie les affinités et l’allocation NUMA. En combinaison avec les compteurs Perf pour les échecs LLC, je détermine si un mauvais placement augmente les latences du cache. Un léger ajustement de l’affinité des threads ou des paramètres de planification apporte souvent des améliorations immédiatement mesurables.
Conseils pour créer des environnements propices à la productivité
En dehors des fenêtres de maintenance, je n'active le traçage qu'avec des filtres précis et pour de courtes périodes. Au préalable, je vérifie les taux d'événements à titre d'exemple sur un système de test, afin de pouvoir Tampon que je règle en conséquence. Dans les environnements de production, j'utilise les agrégations intégrées au noyau afin de réduire la charge dans l'espace utilisateur. Pour des diagnostics ad hoc rapides, il peut être utile de jeter un œil à bpftrace dans l'hébergement, car cela me permet d'obtenir des premières réponses en quelques minutes. Je consigne immédiatement chaque série de mesures afin de pouvoir Répétabilité vrai.
Sécurité, droits et limites d'isolation
Le traçage au niveau du noyau nécessite des droits d'accès appropriés. Je m'assure que tracefs est correctement monté et je vérifie les paramètres système tels que perf_event_paranoid ou kptr_restrict, qui peuvent masquer certains détails. Dans les environnements sensibles, je limite les personnes autorisées à activer le traçage et je mets en place des procédures d’autorisation. J’anonymise les noms de processus ou les adresses IP lorsque les données doivent être partagées, et je définis des règles claires de conservation des traces. Dans les conteneurs, l’utilisateur root n’est pas automatiquement autorisé à lire les événements du noyau de l’hôte. Je préfère donc effectuer le traçage depuis l’hôte ou utiliser des filtres cgroup explicites afin de ne capturer que la charge de travail cible.
Liste de contrôle et erreurs courantes
Je définis d'abord la requête, puis les sous-systèmes, puis les événements – dans cet ordre. Je vérifie que j'ai bien enregistré tous les champs nécessaires avant de lancer la charge. N'oublie pas de définir des filtres ; les sessions non filtrées génèrent rapidement des flux de données massifs et surchargent le système. Mémoire. Je vérifie la version du noyau, les noms des événements et les options des outils afin d'éviter tout malentendu. Pour les workflows eBPF plus complexes, j'étends la configuration avec les Outils BCC, afin de prétraiter les métriques complexes au niveau du noyau et de n'exporter que des signaux agrégés, ce qui Clarté crée.
Tracing dans les conteneurs et les machines virtuelles
Dans les configurations de conteneurs, je filtre idéalement par cgroup afin de voir précisément le service qui m'intéresse. Cela me permet d'effectuer des mesures dans des environnements multi-locataires sans prendre en compte les charges de travail d'autres utilisateurs. Sur les machines virtuelles, je ne vois que ce qui se passe dans le noyau invité. Sans traçage de l’hôte, les chemins Virtio/vhost et le côté hyperviseur restent invisibles. Pour les latences de bout en bout, je corrèle donc les mesures de l’invité et de l’hôte lorsque je souhaite avoir une vue d’ensemble des deux domaines d’influence. De plus, je veille à la synchronisation temporelle entre l’hôte et l’invité afin de pouvoir superposer de manière pertinente les journaux, les métriques et les traces. Grâce à cette rigueur, les analyses restent fiables, même dans les environnements virtualisés.
À retenir : les principaux enseignements
Les tracepoints me fournissent des points d'ancrage stables dans le noyau et génèrent des événements structurés sans trop de surcharge. Je les utilise pour obtenir des Déroulements comprendre, isoler les goulots d'étranglement et évaluer les changements de manière quantifiable. Avec ftrace, perf, LTTng et eBPF, je choisis l'outil le plus adapté en fonction de l'objectif et je les combine si nécessaire. Une formulation claire des questions, des filtres rigoureux et des tailles de tampon adaptées permettent de maintenir la charge à un niveau faible et de garantir la pertinence des données. Je peux ainsi identifier plus rapidement les causes, démontrer l'efficacité de mes mesures et maintenir la Performance sous contrôle permanent.
