bcc tools in de praktijk: Praktische handleiding voor Linux Performance Engineering met eBPF

Ik leg stap voor stap uit hoe ik bcc-tools ik gebruik eBPF om knelpunten op Linux-servers snel te lokaliseren en op te lossen. Daarbij maak ik gebruik van praktische workflows, meet ik de werkelijke latentie in de kernel en koppel ik gebeurtenissen uit de CPU, I/O en het netwerk aan een duidelijk Oorzakenanalyse.

Centrale punten

• eBPF biedt diepgaande tracering met een lage overhead.
• bcc-tools hebben betrekking op de CPU, I/O, het netwerk en processen.
• Productiegerelateerd te gebruiken zonder aanpassingen aan de app.
• Checklist met tien gereedschappen om mee te beginnen.
• Beveiliging door middel van verificatie en duidelijke beleidsregels.

Waarom eBPF voor Linux Performance Engineering

Ik reik naar eBPF, omdat ik kernelgebeurtenissen op een veilige, selectieve manier en met zeer weinig overhead wil meten. Klassieke tools geven totalen weer, maar leggen zelden uit waarom threads wachten, pakketten opnieuw worden verzonden of I/O vastloopt; eBPF vult deze leemte met concrete Events. De programma’s draaien in de kernel, de verifier controleert ze vooraf en ik kan ze starten zonder opnieuw op te starten. Zo breng ik userland-aanroepen in verband met kernelpaden en krijg ik een beeld dat directe optimalisaties mogelijk maakt. Wie zich hier verder in wil verdiepen, vindt een overzicht in mijn korte inleiding over de eBPF-prestatieanalyse, waarin de wisselwerking tussen tracing en observability wordt geschetst.

Wat zijn BCC-tools en waar kan ik ze vinden?

De bcc tools zijn kant-en-klare diagnoseprogramma’s op basis van eBPF en bevinden zich doorgaans in /usr/share/bcc/tools. Ik start ze rechtstreeks vanuit de shell, krijg duidelijke standaarduitvoer en hoef mijn applicaties niet aan te passen. De verzameling omvat processen, systeemaanroepen, bestandssystemen, blok-I/O, netwerk, schedulers en profilering en is daarmee geschikt voor productief Analyses. Aangezien ik tracing doelgericht activeer, blijft de invloed beperkt en zijn meetfouten als gevolg van monitoring gering. Voor meer diepgaande gevallen vul ik de tools aan met eigen eBPF of maak ik bovendien gebruik van sampling-profielen.

Installatie en vereisten

Ik installeer de bcc tools via het pakketbeheer (bcc-tools of bpfcc-tools) op gangbare distributies. Vereist zijn een kernel met eBPF-ondersteuning (vanaf 4.x, bij voorkeur 4.9+), geactiveerde BPF-functies en voldoende rechten om de programma’s te laden. Op productieve servers controleer ik vooraf in een testomgeving of de kernel en de distributie eBPF ondersteunen, zodat latere metingen betrouwbare draaien. Beveiligingsprofielen die eBPF volledig blokkeren, voorkom ik door middel van afgestemde beleidsregels. De beknopte aanwijzingen over geven een praktisch overzicht van de installatie en bediening eBPF-analysetools.

Voor de start: systeem- en veiligheidscontroles

Voordat ik in de productie metingen uitvoer, controleer ik de basisvaardigheden van de host. Zo voorkom ik valse starts en krijg ik reproduceerbare resultaten.

• Kernelfuncties controleren: uname -r en beschikbare BPF-functies (bijvoorbeeld via Feature-Check). Belangrijk zijn kprobes/tracepoints, BTF (voor stabiele type-informatie) en perf-events.
• Rechten en beleidsregels: Ik zorg ervoor dat alleen bevoegde gebruikers eBPF mogen laden (CAP_BPF/CAP_SYS_ADMIN of een overeenkomstig beleid) en dat LSM-profielen het laden niet blokkeren.
• Systeemparameters: kernel.unprivileged_bpf_uitgeschakeld is meestal actief in productieve omgevingen. Daarom werk ik bewust vanuit beveiligde sessies en met duidelijke controle.
• Transparante paden: Ik gebruik mappen zoals /sys/kernel/debug/tracing en /sys/fs/bpf in het oog houden om artefacten na metingen te verwijderen.

Deze hygiëne zorgt ervoor dat ik metingen doelgericht en reproduceerbaar kan uitvoeren – zonder neveneffecten.

Praktische gids: De eerste tien hulpmiddelen

Voor een snelle prestatiecontrole volg ik een vaste volgorde. Zo kan ik oorzaken op het gebied van CPU, I/O of netwerk duidelijk afbakenen en beslissen of ik dieper in de stacks of timings moet duiken. De tabel toont de kerntaak van de tools en de vraag die ik daarmee wil beantwoorden. Ik houd de looptijd in eerste instantie kort en herhaal de metingen zodra ik een vermoeden heb bevestigen wil. Zo voorkom ik blinde vlekken en verspil ik geen tijd bij acute Incidenten.

Gereedschap	Waargenomen	Typische vraag
execsnoop	Nieuwe processen	Wie neemt tijdelijke banen aan die voor extra werk zorgen?
opensnoop	Bestanden openen	Welke paden worden voortdurend geopend of geregistreerd?
ext4 is langzamer (xfs*, btrfs*, zfs*)	Trage FS-bewerkingen	Welke verzoeken vertonen hoge latentie per volume?
biolatency	Block-I/O-verdeling	Zijn er sporadische of aanhoudende pieken in de latentie?
biosnoop	Afzonderlijke I/O-verzoeken	Welk proces brengt bepaalde apparaten tot stilstand?
cachestat	Gedrag van de paginacache	Is meer RAM de moeite waard of vertoont de app dan storingen?
tcpconnect	Nieuwe TCP-verbindingen	Wie maakt hoe vaak gebruik van welke dienst?
tcpaccept	Goedgekeurde verbindingen	Welke serversockets staan onder zware belasting?
tcpretrans	Heruitzendingen	Wijst het verlies van pakketten op onstabiele routes?
runqlat	Vertragingen in de scheduler	Wachten threads te lang op CPU-tijd?

Ik gebruik ook profielen om hotspots in de gebruikers- of kernelruimte te detecteren en call-stacks samen te voegen. Zo ontdek ik kostbare reguliere expressies, inefficiënte stuurprogramma’s of spinlocks, die ik vervolgens in de code of in de configuratie oplos. Ik gebruik korte bemonsteringsintervallen en vergelijk meerdere runs, zodat uitschieters zichtbaar wordt. Deze combinatie van overzicht en diepgang bespaart me veel analysetijd. Vervolgens test ik de optimalisatie opnieuw onder dezelfde belasting.

Uitbreiding: Off-CPU, vergrendelingen en wachttijden zichtbaar maken

Niet elke hoge latentie is CPU-gebonden. Vaak wachten threads „off-CPU“ op I/O, locks of wake-ups. Hier bieden aanvullende bcc-tools en -profielen uitkomst:

• Off-CPU-analyse: ik meet hoe lang threads niet op de CPU actief zijn en welke stacks daar naartoe leiden. Dit maakt een onderscheid tussen rekentijd en wachttijd en brengt blokkerende factoren aan het licht.
• Lock-contention: Ik richt mijn aandacht specifiek op kritieke locks in de kernel en de gebruikersruimte. Lange wachttijden of hoge contention wijzen op serialisatiepunten die ik doorbreek (bijvoorbeeld door sharding, fijnere granulariteit of andere gegevensstructuren).
• Wakeup-paden: vertragingen tussen „is geactiveerd“ en „draait weer“ wijzen op problemen met de planning en prioriteiten of op te grote worker-pools.

Ik breng deze signalen in verband met runqlat en biolatency, om onderscheid te maken tussen oorzaken die te maken hebben met het geheugen, I/O en de scheduler.

Meethygiëne: filters, duur, drempelwaarden

Om ervoor te zorgen dat eBPF-metingen reproduceerbaar blijven, hanteer ik drie basisregels:

• Kort en bondig: ik laat tools in eerste instantie slechts kort draaien (bijvoorbeeld 10–30 seconden) en richt me op verdachte PID’s, containers of sockets.
• Drempels instellen: Bij „*slower“-tools filter ik kleine latenties eruit om de ruis te verminderen en alleen problematische calls te zien.
• Het aantal gebeurtenissen beperken: Ik gebruik selectieve filters (bijv. procesnaam, TID's, poorten) om het aantal gebeurtenissen laag te houden. Zo blijft de overhead minimaal en voorkom ik dat gebeurtenissen verloren gaan.

Pas als ik een patroon zie, verleng ik de looptijd of breid ik de reikwijdte uit. Daardoor krijg ik schoon en betrouwbare steekproeven.

Praktijkscenario 1: Onverklaarbaar hoge CPU-belasting

Als de CPU-indicator voortdurend hoge waarden aangeeft, begin ik met execsnoop, om kortstondige processen te herkennen. Vervolgens meet ik met runqlat hoe lang threads op CPU-tijd moeten wachten, en controleer ik of de runqueues overvol zijn of dat de prioriteiten onjuist zijn ingesteld. Als er opvallende wachttijden optreden, verminder ik het aantal workers, pas ik de threadpools aan of spreid ik de cronjobs uit, zodat de scheduler grijper kan. Met profile verzamel ik stacks en vind ik de echte hotspots in bibliotheken en in mijn eigen code. Pas als ik deze aanwijzingen samenbreng, neem ik beslissingen over limieten, garbage collection, affiniteiten of compiler-flags.

Praktijkscenario 2: I/O-latenties en trage toepassingen

Als gebruikers klagen over vastlopers bij een lage CPU-belasting, controleer ik met ext4 is trager trage bestandssysteemoproepen per proces. Vervolgens bekijk ik met biolatency de verdeling van de blok-I/O-tijden per apparaat, om sporadische pieken of aanhoudende knelpunten op te sporen. biosnoop laat me zien of een enkele dienst een ongezond aantal kleine schrijfbewerkingen genereert en daarmee wachtrijen veroorzaakt die andere processen vertragen. Met cachestat zie ik of de paginacache raak is of dat er misses zijn domineren en meer RAM zou helpen. Uiteindelijk beslis ik of batch-writes, grotere buffers of een overstap naar snellere opslag de moeite waard zijn.

Praktijkscenario 3: Netwerkpaden en microservices

In gedistribueerde omgevingen begin ik met tcpconnect, om het tot stand brengen van verbindingen tussen diensten te meten. Vervolgens controleer ik met tcpaccept welke serversockets bijzonder veel inkomende verbindingen hebben en of de limieten aan de listener-zijde van kracht zijn. tcpretrans brengt herhalingsverzendingen aan het licht en maakt onderscheid tussen transportproblemen en applicatiefouten, voordat ik time-outs en herpogingen aanpas. Aan de hand van deze drie signalen kan ik zien of het netwerk, de app of een upstream-service de Latency stuur ik aan. Daarna pas ik de backoff-strategieën, keepalive-waarden, load balancer-instellingen en buffergroottes aan.

Bedrijfsveiligheid en betrouwbaarheid van eBPF

Ik upload alleen betrouwbaar Ik gebruik tools en test mijn eigen eBPF-programma’s eerst op de staging-omgeving. De kernel-verifier blokkeert foutieve programma’s, maar ik stel bovendien limieten in voor maps en buffers, zodat het geheugen netjes binnen de grenzen blijft. Ik bewaar de logbestanden om het gedrag en de neveneffecten in de gaten te houden en indien nodig snel in te grijpen. Beleidsregels bepalen wie eBPF mag laden, zodat de controle bij het platformteam blijft en aan de beveiligingseisen wordt voldaan. Deze regels zorgen ervoor dat tracing in productieomgevingen Betrouwbaar blijft zoals het is en zorgt niet voor verrassingen.

Container- en Kubernetes-omgevingen

In containers maak ik een onderscheid tussen systematische problemen en pod-specifieke effecten. Hiervoor filter ik metingen op cgroup, namespace of PID-bereik. Veel bcc-tools bieden de mogelijkheid om te filteren op procesnamen of -ID's; als alternatief voer ik metingen uit op de host en wijs ik gebeurtenissen via cgroup toe aan de workloads. Belangrijk:

• PID-naamruimte: PID’s verschillen tussen host en container. Ik koppel de ID’s aan elkaar of filter op basis van procesnamen/poorten.
• Quota’s voor systeembronnen: CPU-throttling als gevolg van CFS-quota’s uit zich in lange wachttijden zonder dat het systeem volledig wordt benut. Ik merk dit aan runqlat in combinatie met quota-statistieken.
• Netwerknaamruimten: Bij socketanalyses let ik op de juiste naamruimte. Ik voer metingen uit op de host-interface en breng deze in verband met pod-IP-adressen en poorten.

Zo blijven de meetresultaten betrouwbaar, zelfs als er veel workloads dicht bij elkaar draaien.

Integratie in observability-stacks

Ik vervang mijn monitoring niet, maar vul deze aan met eBPF. bcc-tools bieden mij de diepgang, terwijl metricsystemen, logs en APM de breedte laten zien; samen vormen ze een samenhangend beeld. Indien nodig leid ik traces uit bcc door naar log-pijplijnen, activeer ik snapshots bij incidenten en documenteer ik de bevindingen binnen het team. Voor gerichte profielen gebruik ik sampling naast tijdlijnen op basis van metrics, zodat afwijkingen tastbaar worden. Wie daarnaast de voorkeur geeft aan scripting, vindt in bpftrace in de hostingomgeving een eenvoudige manier om ad-hocvragen met miniscripts te beantwoorden.

Veelvoorkomende struikelblokken – en hoe ik ze omzeil

• Noisy Neighbor: afzonderlijke taken veroorzaken een kortstondige, maar intense belasting. execsnoop plus profielen Deze patronen worden hierdoor betrouwbaar aan het licht gebracht; ik werk er met timeboxes mee of isoleer ze aan de hand van quota.
• NUMA en affiniteiten: hoge latenties ondanks beschikbare cores duiden op Cross-NUMA-toegangen. Ik controleer de CPU-affiniteiten, het geheugengebruik en de IRQ-verdeling.
• IRQ/SoftIRQ-hotspots: de netwerkbelasting kan de ksoftirqd-kernels overbelasten. Ik houd heruitzendingen in de gaten, verdeel IRQ’s via RSS/wachtrijen en pas RPS/XPS aan.
• Effecten van de paginacache: koude starts verlopen trager. Ik houd rekening met opwarmfasen en vergelijk cachestat-Waarden vóór en na belasting.
• Kernel-updates: Kprobes kunnen bij versiesprongen veranderen. Ik geef de voorkeur aan stabiele tracepoints, test ze van tevoren en houd een minimale set bij de hand.

Werkprocessen die hun waarde hebben bewezen

• Incident-snapshot: 60–120 seconden gecombineerde run (execsnoop, runqlat, biolatency, tcpretrans, profile). Daarna richt ik me op het opvallende subsysteem.
• Baseline-routine: wekelijks korte metingen op kernpaden (bijv. opslag- en netwerkprofiel). Zo kan ik afwijkingen in een vroeg stadium opmerken.
• Validatie van wijzigingen: Voor en na configuratiewijzigingen vergelijk ik dezelfde meetpunten om het effect meetbaar te maken.

Continue Linux-prestatieoptimalisatie

Ik beschouw performance als een doorlopend proces, niet als Eenmalige actie. In CI/CD integreer ik korte, op eBPF gebaseerde controles om regressies in een vroeg stadium op te sporen en vóór de uitrol te stoppen. Tijdens onderhoudsvensters meet ik typische paden onder belasting, stel ik basislijnen vast en documenteer ik aanvaardbare latentiebereiken. Zo herken ik afwijkingen snel en hoef ik tijdens een incident niet te gissen, omdat er vergelijkingsgegevens zijn beschikbaar. Deze werkwijze draagt direct bij aan de beschikbaarheid, kostenbeheersing en gebruikerservaring.

Mini-casestudy: van symptoom naar oorzaak in 12 minuten

Een API-cluster meldt stijgende 99p-latenties bij een ongewijzigd RPS. Ik maak een incident-snapshot: tcpconnect vertoont geen afwijkingen bij het tot stand brengen van de verbinding, tcpretrans blijft laag – het netwerk is dat in ieder geval niet. runqlat meldt korte, maar frequente wachttijden; profielen toont hotspots in een JSON-serialisatie. Tegelijkertijd houd ik in de gaten met cachestat een daling van de cache-hitratio's tijdens pieken. De correlatie wijst erop dat er sprake is van veel kleine payloads die synchroon worden geserialiseerd en onmiddellijk worden weggeschreven.

Ik verifieer met ext4 is trager, dat fsyncs van meerdere milliseconden op hetzelfde volume voor het API-proces laat zien; biolatency bevestigt sporadische pieken in de wachtrij op het betreffende apparaat. Oplossing: het batchen van schrijfbewerkingen, een grotere buffer en asynchroon leegmaken op minder gevoelige punten. Na de uitrol dalen de 99p-latenties met 35 %, herstelt de cache-hitrate zich, en runqlat laat opnieuw smalle verdelingen zien.

Samenvatting voor de praktijk

Met bcc Met tools en eBPF krijg ik in korte tijd inzicht in de CPU, I/O en het netwerk, zonder applicaties te hoeven aanpassen. De checklist met execsnoop, opensnoop, ext4slower, biolatency, biosnoop, cachestat, tcpconnect, tcpaccept, tcpretrans en runqlat vormt een logisch startpunt. Daarnaast gebruik ik profile om hotspots zichtbaar te maken en codepaden te optimaliseren. Dankzij duidelijke beleidsregels, logboekregistratie en limieten blijft het gebruik in de kernel veilig en inzichtelijk. Wie deze methode consequent toepast, lost prestatieproblemen sneller op, plant capaciteiten beter en verlaagt de kosten per aanvraag.