Ga naar de inhoud 
Met kernel-tracepoints krijg ik inzicht in prestatieproblemen in Linux tot in de kernel zelf en kan ik gericht meten waar tijd verloren gaat. Ik maak hier gebruik van Meetpunten, om processen in de scheduler, de I/O-stack en het netwerkpad te monitoren – met minimale extra inspanning en duidelijke gebeurtenisgegevens.
Centrale punten
De volgende kernpunten geven je een snel overzicht van waar ik op let bij het werken met tracepoints.
- Statisch Verankerde gebeurtenissen leveren betrouwbare gegevens op op opvallende punten in de code.
- Lage overhead maakt tracing ook bij hoge belasting haalbaar.
- Breed ecosysteem met ftrace, perf, LTTng en eBPF-tools.
- Gerichte activering en filteren voorkomt een overvloed aan gegevens.
- Combinatie met prestatiemeters worden de oorzakelijke verbanden weergegeven.
Ik houd de lijst beknopt en concentreer me op de Prioriteiten de analyse. Zo verspil ik geen tijd aan bijkomstigheden en houd ik de belangrijkste signalen in het oog. De genoemde punten vormen de leidraad voor mijn praktische werk, vanaf het eerste vermoeden tot aan de geverifieerde optimalisatie. Zo creëer ik Transparantie en reproduceerbaarheid. Ik blijf me baseren op gegevens en controleer elke stap.
Wat zijn kernel-tracepoints?
Een tracepoint is een statisch instrumentatiepunt in de kernelcode dat een gebeurtenis met gestructureerde velden activeert. Ik zie daar onder andere PID, tijdstempels, CPU, statuscodes of groottegegevens, afhankelijk van de gebeurtenis. Via macro’s zoals TRACE_EVENT bepaalt de kernel de locatie, het formaat en de geleverde gegevens. Deze gebeurtenissen vinden plaats op relevante raakvlakken zoals scheduling, blok-I/O, bestandssystemen of het netwerkpad. Ik kan ze op elk moment activeren zonder de kernel te patchen of productiesystemen in gevaar te brengen, wat mij Veiligheid plannen daar.
Waarom tracepoints gebruiken voor het meten van prestaties
Tracepoints kosten in inactieve toestand vrijwel niets en zorgen pas bij het inschakelen voor een geringe extra belasting. Zelfs bij geactiveerde events meet ik doorgaans slechts een extra latentie in het lage tweecijferige nanosecondenbereik – goed genoeg voor systemen met strenge latentiedoelstellingen. Omdat ze stevig in de kernel zijn verankerd, kan ik analyses consistent herhalen, ongeacht de kernelversie. De gestructureerde uitvoer ervan kan betrouwbaar worden geparseerd en verder verwerkt. Hierdoor krijg ik betrouwbare Metingen in plaats van onduidelijke logfragmenten.
Tijdstempels, klokken en volgorde
Om latenties correct te interpreteren, let ik op de gebruikte tijdbron. Monotone klokken (bijv. CLOCK_MONOTONIC) zijn voor metingen robuuster dan de wandtijd, omdat NTP-correcties niet met terugwerkende kracht worden toegepast. Op systemen met meerdere kernen leveren buffers per CPU gebeurtenissen waarvan de volgorde lokaal per CPU klopt, maar die tussen CPU's alleen via tijdstempels met elkaar kunnen worden vergeleken. Daarom kalibreer ik het perspectief: ofwel rangschik ik gebeurtenissen per CPU, ofwel gebruik ik tools die buffers synchroniseren en conflicten in de tijdlijn correct oplossen. Bij zeer krappe budgetten controleer ik of de TSC-basis stabiel is, zodat afwijkingen niet ten onrechte als jitter worden geïnterpreteerd. Zo voorkom ik verkeerde interpretaties wanneer bijvoorbeeld wake-ups plaatsvinden op CPU 3 en contextwisselingen op CPU 7.
Overzicht van het Linux-tracing-ecosysteem
Ik gebruik verschillende tools die allemaal op dezelfde tracepoint-gebeurtenissen zijn gebaseerd. ftrace kan snel worden geactiveerd via het tracing-bestandssysteem en is geschikt voor ad-hoccontroles met Livebeeld. Met perf koppel ik tracepoints, hardwaretellers en steekproeven aan elkaar om correlaties zichtbaar te maken. LTTng kan lange registraties bijhouden met een hoge gebeurtenisfrequentie en een lage extra belasting, wat essentieel is voor diepgaande analyses. eBPF-gebaseerde tools lezen tracepoints, voeren aggregaties uit in de kernel en verminderen zo Dataverkeer naar de gebruikersruimte.
Ringbuffer en verliescontrole
Achter elke actieve gebeurtenis werkt een ringbuffer per CPU. Ik dimensionneer deze buffers zo dat pieken in de belasting worden opgevangen zonder dat gebeurtenissen worden weggegooid. Belangrijk zijn verlies-tellers en waarschuwingen van de tools: Bij perf let ik op de teller voor verloren gebeurtenissen, bij ftrace controleer ik de „dropped“-statistieken in tracefs. LTTng geeft ook aan wanneer het consumentenpad niet bijblijft. Als er verlies optreedt, vergroot ik de buffers, filter ik strenger of aggregeer ik vroegtijdig. Voor ‘Flight Recorder’-scenario’s gebruik ik snapshots die een tijdsperiode rond een trigger vastleggen. Zo houd ik de gegevenskwaliteit hoog en voorkom ik foutieve hypothesen op basis van onvolledige traces.
Keuze van tools: ftrace, perf, LTTng, eBPF
Ik begin vaak met perf, omdat ik daar sampling, tellerstanden en tracepoints samen analyseer. Voor snelle inspecties van gebeurtenissen gebruik ik ftrace en schakel ik gericht Evenementen vrij. Complexe, langdurige sessies met veel CPU’s voer ik graag uit met LTTng, omdat het hoge waarden betrouwbaar vastlegt. Als ik in de kernel wil aggregeren, gebruik ik op eBPF gebaseerde tracers om alleen samengevatte statistieken te exporteren. Wie zich verder in perf wil verdiepen, vindt praktische tips in het artikel over de perf-tool, wat zowel beginners als gevorderden helpt.
Reproduceerbaarheid en automatisering van sessies
Ik leg de gegevens van succesvolle sessies vast: geactiveerde events, filters, buffergroottes, bemonsteringsfrequenties en looptijd. Daarnaast documenteer ik de kernelversie, toolversies, CPU-topologie en stroominstellingen, zodat latere metingen vergelijkbaar zijn. Zo kan ik een sessie indien nodig ongewijzigd herhalen, naar andere hosts overzetten of in CI-pijplijnen automatiseren. Bij langere analyses sla ik ruwe gegevens op en genereer ik direct na de meting samenvattingen (histogrammen, percentielen, heatmaps). Ik werk iteratief: korte, gerichte runs, evaluatie, de hypothese verfijnen – en opnieuw meten. Op deze manier raak ik niet verdwaald in de gegevens, maar doe ik betrouwbare uitspraken met een minimale doorlooptijd.
Toepassingsscenario's in de praktijk
Bij de scheduler houd ik contextwisselingen, wake-ups en interacties met de wachtrij in de gaten om overmatig schakelen of onjuiste prioriteiten aan het licht te brengen. In de blokstack breng ik het indienen en voltooien van verzoeken in verband met de diepte en omvang van de wachtrij, zodat ik Opslag-Knelpunten. In het netwerkpad volg ik de in- en uitgaande pakketten en de wachtrijen om de latentieketens per flow te begrijpen. Bij syscalls controleer ik de frequentie en latentie om afwijkingen in hotpaths te herkennen. Indien nodig combineer ik dit met hardwaretellers, zodat cache-misses, branch-mispredictions en I/O-events een oorzakenketen resultaat.
Concrete namen van gebeurtenissen en interpretatie van velden
Ik kies gebeurtenissen zo dat ik het traject met slechts enkele meetpunten volledig kan reconstrueren. Een basisset die zijn waarde heeft bewezen:
- Scheduler: sched:sched_switch (vorige/volgende_commando, vorige_toestand), sched:sched_wakeup en sched:sched_wakeup_new (wakeup-bron, doel-CPU)
- Block-I/O: block:block_rq_issue, block:block_rq_complete (sectoren, grootte, apparaat, latentie via delta)
- Netwerk: net:net_dev_queue, net:netif_receive_skb (wachtrijen en ontvangst), tcp:tcp_retransmit_skb (herverzendingen)
- Syscalls: syscalls:sys_enter_*, syscalls:sys_exit_* (duur per aanroep, foutcodes)
Ik controleer vooraf de betekenis van de velden, zodat ik de juiste correlaties kan leggen: uit prev_state haal ik slapende taken, uit CPU-velden herken ik verplaatsingen tussen sockets. Bij netwerkgebeurtenissen neem ik, indien beschikbaar, flow-metadata (bijv. poorten) mee om latenties per verbinding te groeperen. Zo krijg ik paden die daadwerkelijk overeenkomen met het waargenomen gedrag in de dienst.
Stap voor stap: van de vraag tot de trace-sessie
Ik begin altijd met een duidelijke vraag, bijvoorbeeld: „Waarom nemen de responstijden toe tijdens piekbelastingen?“ Deze stap dwingt me om het juiste Subsysteem kiezen: Scheduler, Netwerk, Blok, Bestandssysteem of Geheugenbeheer. Vervolgens maak ik een lijst van geschikte tracepunten met „perf list“ of in het tracing-bestandssysteem en noteer ik relevante velden. Ik configureer de sessie, stel filters in op PID-, CPU- of gebeurtenisvelden en leg buffers en de duur vast. Daarna voer ik het belastingsscenario uit en analyseer vervolgens latentieverdelingen, volgordes en correlaties, voordat ik een hypothese toets en de wijziging opnieuw meet om de Effect om te bevestigen.
Filteren en correlatie: PID’s, TID’s, cgroups en flows
Nauwkeurige filters besparen me tijd. Afhankelijk van het doel werk ik met PID-/TID-filters, CPU-selectie of cgroup-filters om binnen de grenzen van containers of services te blijven. Zodra ik netwerklatentie wil begrijpen, breng ik gebeurtenissen in verband via flow-attributen (bijv. bron-/doelpoort), zodat ik bulkverkeer en latentiegevoelige flows van elkaar kan scheiden. Bij bestanden wijs ik ze toe op basis van apparaat-/blokadres of groepeer ik ze op mountpunt, afhankelijk van de tool. Op het gebied van de scheduler meet ik de tijd vanaf het ontwaken tot de eerste sched_switch naar de doel-CPU; zo zie ik de wachttijd in de runqueues gescheiden van de daadwerkelijke CPU-tijd.
Overhead beheren: best practices
Ik activeer alleen de tracepoints die ik echt nodig heb, om de hoeveelheid gegevens en de extra belasting laag te houden. Filters op PID, CPU of velden zorgen ervoor dat er weinig ruis is en ontzien het systeem Buffer. Ik pas de buffergrootte aan de gebeurtenisfrequentie aan, zodat ik geen gebeurtenissen mis. Ik leg een duidelijke tijdslimiet op aan sessies en herhaal deze alleen als ik een hypothese wil toetsen. Bij extreem frequente gebeurtenissen maak ik gebruik van steekproeven of in-kernel-aggregatie via eBPF, zodat de analyse in de gebruikersruimte slank overblijfselen.
Vergelijking: tracepoints versus prestatie-events
Beide benaderingen vullen elkaar aan. Tracepoints geven uitleg over concrete gebeurtenissen in subsystemen en leveren zinvolle Velden. Prestatietests geven me een statistisch inzicht in cycli, cache-misses of vertakkingen. Door deze gegevens te combineren, zie ik hoeveel tijd er verloren gaat en bij welke stap het misgaat. De volgende tabel helpt bij de keuze van de juiste tools en richt zich op wat ik nodig heb voor de volgende meetronde. Ze dient voor mij als Verlanglijstje voor de planning van de sessie.
| Aspect | Tracepunten | Performance-evenementen (perf) |
|---|---|---|
| Stabiliteit | Statische gebeurtenissen op kernel-locaties, grotendeels versiegebonden | Afhankelijk van hardwaretellers en de kernelimplementatie |
| Overhead | Laag, gebeurtenisgestuurd | Zeer laag bij het bemonsteren |
| Focus | Concrete gebeurtenissen in subsystemen | Systeembrede kengetallen |
| Gegevensformaat | Gestructureerd, machinaal leesbaar | Meetwaarden, monsters, profielen |
| Typisch gebruik | „Het “wat„ en “wanneer” van een pad | „Hoeveel“ en „Hoe duur“ |
Ik begin graag met prestatie-events om een globale bottleneck op te sporen, en ga vervolgens met tracepoints in detail. Omgekeerd schakel ik eerst tracepoints in als ik een pad wil begrijpen, en voeg ik later tellers toe voor kwantisering. Deze volgorde bespaart tijd en zorgt ervoor dat de gegevensverzameling doelgericht verloopt. Het is belangrijk om de gebeurtenisfrequentie in de gaten te houden, zodat er geen gegevens verloren gaan. Zo blijf ik op de hoogte met Meetdiscipline op koers.
Grenzen, validatie en kruiscontroles
Niet elk driverpad is over de hele lijn geïnstrumenteerd, en sommige zeldzame fouttrajecten komen niet voor in de traces. Daarom vergelijk ik metingen met alternatieve bronnen: counters, logs, synthetische tests, maar ook eenvoudige tijdmetingen in de service zelf. Als traces en counters niet met elkaar overeenkomen, controleer ik eerst filters en gegevensverlies, en daarna de klokbasis. Ik let bovendien op interferenties: debug-builds, hoge logfrequenties of beveiligingshooks kunnen latenties verschuiven. Alleen door middel van kruiscontroles kan ik met zekerheid aantonen dat een gevonden oorzaak ook daadwerkelijk de hefboom voor de optimalisatie is.
Voorbeeld: opslaglatenties meten
Ik activeer in de blokstack tracepoints voor het indienen en afronden van I/O-verzoeken. Terwijl een belastingstest wordt uitgevoerd, registreer ik tijdstempels, de grootte van het verzoek, het apparaat en de PID om Latencies per proces zichtbaar te maken. Vervolgens sorteer ik op duur en laat ik histogrammen genereren die pieken en uitschieters weergeven. In een tweede ronde voeg ik daar ook CPU-tellers aan toe om te controleren of er een verband bestaat tussen de rekenbelasting en de I/O-latenties. Ten slotte pas ik de I/O-scheduler, de wachtrijdiepte of de opslag-backend aan en herhaal ik de meting totdat de Doelen betrouwbaar zijn bereikt.
Voorbeeld: de latentie van de scheduler en de wake-up-functie in kaart brengen
Als threads „spiky“ reageren, meet ik de tijd vanaf `sched:sched_wakeup` tot de eerste `sched:sched_switch` op de doel-CPU. Zo maak ik een onderscheid tussen de wachttijd in de runqueues en de daadwerkelijke uitvoeringstijd. Ik groepeer op CPU, prioriteit en beleid (CFS/RT) om afwijkingen te herkennen – bijvoorbeeld wanneer threads met een hoge CPU-behoefte op overbelaste cores terechtkomen, terwijl er vrije cores beschikbaar zijn. Als ik veel cross-CPU-wake-ups zie, controleer ik de affiniteiten en de NUMA-toewijzing. In combinatie met Perf-counters voor LLC-misses aantoon ik of een verkeerde plaatsing de cache-latenties opdrijft. Een kleine aanpassing aan de thread-affiniteit of de scheduling-parameters levert hier vaak direct meetbare verbeteringen op.
Tips voor een productieve werkomgeving
Ik schakel tracing buiten onderhoudsvensters alleen in met duidelijke filters en korte tijdsvensters. Vooraf controleer ik de gebeurtenisfrequenties aan de hand van een voorbeeld op een testsysteem, zodat ik de Buffer op de juiste manier instel. In productieomgevingen maak ik gebruik van in-kernel-aggregaties om de belasting in de gebruikersruimte te verminderen. Voor snelle ad-hocdiagnoses is het de moeite waard om eens te kijken naar bpftrace in de hostingomgeving, omdat ik daarmee binnen enkele minuten de eerste resultaten krijg. Ik documenteer elke meetrun meteen, zodat ik Herhaalbaarheid waar.
Veiligheid, rechten en isolatiegrenzen
Voor tracing op kernelniveau zijn de juiste machtigingen vereist. Ik zorg ervoor dat tracefs correct is gemount en controleer systeembrede schakelaars zoals perf_event_paranoid of kptr_restrict, die details kunnen verbergen. In gevoelige omgevingen beperk ik wie tracing mag activeren en leg ik procedures vast voor het verlenen van toestemming. Ik anonimiseer procesnamen of IP-adressen wanneer gegevens moeten worden gedeeld en definieer duidelijke bewaarregels voor traces. In containers geldt: root in de container is niet automatisch bevoegd om host-kernelgebeurtenissen te lezen. Ik traceer daarom bij voorkeur vanaf de host of werk met expliciete cgroup-filters om alleen de doel-workload vast te leggen.
Checklist en veelvoorkomende fouten
Ik definieer eerst de vraag, daarna de subsystemen en vervolgens de gebeurtenissen – in die volgorde. Ik controleer of ik echt alle benodigde velden heb opgenomen voordat ik de belasting start. Vergeet niet filters in te stellen; ongefilterde sessies zorgen al snel voor een stortvloed aan gegevens en overbelasten Geheugen. Ik zorg ervoor dat de kernelversie, de naam van de gebeurtenis en de toolopties overeenkomen, zodat er geen misverstanden ontstaan. Voor meer geavanceerde eBPF-workflows breid ik de opzet uit met de BCC-tools, om complexe meetwaarden in de kernel voor te verwerken en alleen samengevatte signalen te exporteren, wat Duidelijkheid creëert.
Tracing in containers en VM's
In containeropstellingen filter ik bij voorkeur op cgroup om precies die service te zien die mij interesseert. Zo kan ik in multi-tenant-omgevingen metingen uitvoeren zonder dat er vreemde workloads worden meegenomen. Bij VM’s geldt: ik zie alleen wat er in de gastkernel gebeurt. Virtio-/vhost-paden en de hypervisor-kant blijven zonder host-tracing onzichtbaar. Voor end-to-end-latenties breng ik daarom gast- en hostmetingen met elkaar in verband, als ik beide invloedssferen in het oog wil houden. Daarnaast let ik op de tijdsynchronisatie tussen host en gast, zodat ik logs, metrics en traces op een zinvolle manier over elkaar heen kan leggen. Met deze discipline blijven analyses ook in gevirtualiseerde omgevingen betrouwbaar.
Om mee te nemen: de belangrijkste lessen
Tracepoints bieden me stabiele ankerpunten in de kernel en leveren gestructureerde gebeurtenissen zonder veel ballast. Ik gebruik ze om exacte Processen om inzicht te krijgen, knelpunten te isoleren en veranderingen meetbaar te toetsen. Met ftrace, perf, LTTng en eBPF kies ik, afhankelijk van het doel, de juiste tool en combineer deze indien nodig. Een duidelijke vraagstelling, strenge filters en passende buffergroottes houden de belasting laag en de gegevens bruikbaar. Zo vind ik oorzaken sneller, toon ik het effect van mijn maatregelen aan en houd ik de Prestaties permanent onder controle.
