bcc tools i praktiken: Praktisk handbok för prestandautveckling i Linux med eBPF

Jag visar steg för steg hur jag bcc-verktyg använder eBPF för att snabbt identifiera och åtgärda flaskhalsar på Linux-servrar. Jag använder praktiska arbetsflöden, mäter faktiska fördröjningar i kärnan och kopplar samman händelser från CPU, I/O och nätverk till en klar Orsaksanalys.

Centrala punkter

• eBPF ger djup spårning med låg overhead.
• bcc-verktyg omfattar CPU, I/O, nätverk och processer.
• Nära produktionen Kan användas utan ändringar i appen.
• Checklista med tio verktyg att börja med.
• Säkerhet genom Verifier och tydliga riktlinjer.

Varför eBPF för prestandautveckling i Linux

Jag sträcker mig efter eBPF, eftersom jag vill mäta kärnhändelser på ett säkert och selektivt sätt och med mycket liten overhead. Traditionella verktyg visar sammanlagda värden, men de förklarar sällan varför trådar väntar, paket skickas om eller I/O fastnar; eBPF fyller denna lucka med konkreta Händelser. Programmen körs i kärnan, verifieraren kontrollerar dem i förväg och jag kan starta utan omstart. På så sätt kan jag koppla samman anrop från användarutrymmet med kärnans sökvägar och få en överblick som möjliggör omedelbara optimeringar. Den som vill fördjupa sig i ämnet hittar en översikt i min korta introduktion till eBPF-prestandaanalys, som beskriver samspelet mellan spårning och observabilitet.

Vad är BCC-verktyg och var hittar jag dem?

Die bcc tools är färdiga diagnostikprogram baserade på eBPF och finns vanligtvis i /usr/share/bcc/tools. Jag startar dem direkt i shellen, får tydliga standardutdata och behöver inte ändra mina applikationer. Samlingen täcker processer, systemanrop, filsystem, block-I/O, nätverk, schemaläggare och profilering och är därmed lämplig för produktiv Analyser. Eftersom jag aktiverar spårning på ett målinriktat sätt blir påverkan liten och mätfelen till följd av övervakningen blir obetydliga. För mer komplexa fall kompletterar jag verktygen med egen eBPF eller använder dessutom samplingsprofiler.

Installation och krav

Jag installerar den bcc Verktyg via pakethanteraren (bcc-tools respektive bpfcc-tools) på vanliga distributioner. Det krävs en kärna med eBPF-stöd (från 4.x, helst 4.9+), aktiverade BPF-funktioner och tillräckliga behörigheter för att ladda programmen. På produktionsservrar testar jag först kärnans och distributionens eBPF-funktioner i en testmiljö, så att senare mätningar pålitlig köras. Jag förhindrar säkerhetsprofiler som helt blockerar eBPF genom anpassade policyer. De kortfattade anvisningarna ger en praktisk översikt över installation och användning av eBPF-analysverktyg.

Innan start: System- och säkerhetskontroller

Innan jag utför mätningar i produktionen kontrollerar jag värdens grundläggande funktioner. På så sätt undviker jag felaktiga startförsök och får reproducerbara resultat.

• Kontrollera kärnfunktioner: uname -r och tillgängliga BPF-funktioner (t.ex. via Feature-Check). Viktiga är kprobes/tracepoints, BTF (för stabil typinformation) och perf-händelser.
• Rättigheter och policyer: Jag ser till att endast behöriga användare får ladda eBPF (CAP_BPF/CAP_SYS_ADMIN eller motsvarande policy) och att LSM-profiler inte blockerar inläsningen.
• Systemparametrar: kernel.unprivileged_bpf_disabled är oftast aktiv i produktiva miljöer. Därför arbetar jag medvetet från säkra sessioner och med tydlig granskning.
• Transparenta sökvägar: Jag använder kataloger som /sys/kernel/debug/tracing och /sys/fs/bpf i sikte för att rensa bort artefakter efter mätningarna.

Denna hygien säkerställer att jag kan utföra mätningarna på ett målinriktat och reproducerbart sätt – utan biverkningar.

Praktisk handbok: De tio första verktygen

För en snabb prestandakontroll följer jag en fast ordning. På så sätt kan jag tydligt avgränsa orsaker som beror på CPU, I/O eller nätverk och avgöra om jag behöver granska stackar eller tidsmätningar mer ingående. Tabellen visar verktygens huvudsakliga funktion och den fråga jag vill reda ut med dem. Jag håller först mätningstiden kort och upprepar mätningarna så snart jag har en misstanke bekräfta vill. På så sätt undviker jag blinda fläckar och slösar inte bort tid på akuta Incidenter.

Verktyg	Observerat	Typisk fråga
execsnoop	Nya processer	Vem skapar kortvariga jobb som medför en belastning?
opensnoop	Filöppningar	Vilka vägar öppnas eller loggas kontinuerligt?
ext4 är långsammare (xfs*, btrfs*, zfs*)	Långsamma FS-operationer	Vilka visningar uppvisar höga latenser per volym?
biolatency	Block-I/O-fördelning	Förekommer det sporadiska eller ihållande toppar i latensen?
biosnoop	Enskilda I/O-förfrågningar	Vilken process sätter vissa enheter ur spel?
cachestat	Sidcachens beteende	Lönar det sig med mer RAM, eller uppstår det problem med appen?
tcpconnect	Nya TCP-anslutningar	Vem använder vilken tjänst och hur ofta?
tcpaccept	Godkända anslutningar	Vilka serversocklar utsätts för hög belastning?
tcpretrans	Återutsändningar	Tyder paketförlust på instabila sökvägar?
runqlat	Fördröjningar i schemaläggaren	Väntar trådarna för länge på CPU-tid?

Jag använder också profiler för att identifiera flaskhalsar i användar- eller kärnutrymmet och sammanställa anropstackar. På så sätt upptäcker jag resurskrävande reguljära uttryck, ineffektiva drivrutiner eller spinlocks, som jag sedan åtgärdar i koden eller konfigurationen. Jag använder korta samplingsintervall och jämför flera körningar för att upptäcka avvikande värden synlig . Denna kombination av överblick och djupgående analys sparar mig mycket tid. Därefter testar jag optimeringen på nytt under samma belastning.

Utökning: Visa Off-CPU, låsningar och väntetider

Inte all hög latens beror på CPU:n. Ofta väntar trådar „off-CPU“ på I/O, lås eller väckningar. Här kan kompletterande bcc-verktyg och -profiler vara till hjälp:

• Off-CPU-analys: Jag mäter hur länge trådar inte befinner sig på CPU:n och vilka stackar som leder dit. Detta skiljer beräkningstid från väntetid och visar vad som orsakar blockeringar.
• Låskonflikter: Jag granskar specifikt kritiska lås i kärnan och användarutrymmet. Långa väntetider eller höga konflikter tyder på serialiseringspunkter som jag bryter upp (t.ex. genom sharding, finare granularitet eller andra datastrukturer).
• Wakeup-vägar: Fördröjningarna mellan „har väckts“ och „körs igen“ avslöjar schemaläggnings- och prioriteringsproblem eller alltför stora arbetspooler.

Jag korrelerar dessa signaler med runqlat och biolatency, för att skilja mellan orsaker som har att göra med minne, I/O och schemaläggaren.

Mätningens tillförlitlighet: Filter, varaktighet, tröskelvärden

För att eBPF-mätningarna ska förbli reproducerbara följer jag tre grundregler:

• Kort och koncist: Jag låter verktygen i början bara köras en kort stund (t.ex. 10–30 sekunder) och fokuserar på misstänkta PID:er, containrar eller socklar.
• Ställa in tröskelvärden: När jag använder „*slower“-verktyg filtrerar jag bort små fördröjningar för att minska bruset och endast se problematiska anrop.
• Begränsa händelsefrekvensen: Jag använder selektiva filter (t.ex. processnamn, TID:er, portar) för att hålla händelsefrekvensen låg. På så sätt blir överheaden minimal och jag undviker att händelser går förlorade.

Först när jag ser ett mönster förlänger jag löptiden eller utvidgar omfattningen. På så sätt får jag ren och tillförlitliga stickprov.

Praktiskt scenario 1: Oförklarligt hög CPU-belastning

Om CPU-indikatorn visar konstant höga värden börjar jag med execsnoop, för att upptäcka kortlivade processer. Därefter mäter jag med runqlat hur länge trådar väntar på CPU-tid och kontrollerar om körköerna är överfyllda eller om prioriteringarna är felaktigt inställda. Om väntetiderna blir påfallande minskar jag antalet arbetare, ändrar trådpooler eller jämnar ut cron-jobb så att schemaläggaren grabba kan. Med profile samlar jag in stackar och hittar de verkliga flaskhalsarna i bibliotek och i min egen kod. Först när jag sammanställer dessa uppgifter fattar jag beslut om gränsvärden, sopuppsamling, affiniteter eller kompileringsflaggor.

Praktiskt scenario 2: I/O-fördröjningar och tröga applikationer

Om användare klagar på att programmet hänger vid låg CPU-belastning, kontrollerar jag med ext4 är långsammare Långsamma filsystemanrop per process. Därefter använder jag biolatency för att granska fördelningen av block-I/O-tider per enhet, i syfte att upptäcka sporadiska toppar eller ihållande flaskhalsar. biosnoop visar mig om en enskild tjänst genererar en onormalt stor mängd små skrivoperationer och därmed orsakar köbildning som bromsar andra processer. Med cachestat ser jag om sidcachen träffar eller om det blir missar dominera och om mer RAM skulle hjälpa. I slutändan bestämmer jag om batch-skrivningar, större buffertar eller en övergång till snabbare lagringsutrymme lönar sig.

Praktiskt scenario 3: Nätverksvägar och mikrotjänster

I distribuerade miljöer börjar jag med tcpconnect, för att mäta uppkopplingen mellan tjänsterna. Sedan kontrollerar jag med tcpaccept vilka serversocklar som har särskilt många inkommande anslutningar och om gränserna på lyssnarsidan fungerar. tcpretrans upptäcker återupprepade sändningar och skiljer transportproblem från applikationsfel innan jag justerar timeouts och omförsök. Med dessa tre signaler kan jag se om det är nätverket, appen eller en uppströms-tjänst som Fördröjning driver. Därefter justerar jag backoff-strategier, keepalive-värden, inställningar för lastbalanserare och buffertstorlekar.

Driftsäkerhet och tillförlitlighet hos eBPF

Jag laddar bara pålitlig Jag testar först verktyg och egna eBPF-program på staging. Kernel-Verifier blockerar felaktiga program, men jag sätter dessutom gränser för maps och buffertar så att minnesanvändningen hålls inom rimliga gränser. Jag sparar loggdata för att hålla koll på beteenden och bieffekter och snabbt kunna ingripa vid behov. Policyer fastställer vem som får ladda eBPF, så att kontrollen förblir hos plattformsteamet och säkerhetskraven uppfylls. Dessa regler säkerställer att spårning i produktionsmiljöer Pålitlig förblir oförändrad och ger inga överraskningar.

Container- och Kubernetes-miljöer

I containrar skiljer jag systematiska problem från pod-specifika effekter. För detta filtrerar jag mätningarna efter cgroup, namnområde eller PID-intervall. Många bcc-verktyg tillåter filtrering efter processnamn eller -ID; alternativt mäter jag på värddatorn och tilldelar händelser till arbetsbelastningarna via cgroup. Viktigt:

• PID-namnrymd: PID:er skiljer sig åt mellan värd och container. Jag mappar ID:n eller filtrerar efter processnamn/portar.
• Resurskvoter: CPU-begränsning genom CFS-kvoter visar sig i form av långa väntetider utan full systemutnyttjande. Jag märker detta genom runqlat i kombination med kvotmått.
• Nätverksnamnrymder: Vid socket-analyser ser jag till att använda rätt namnrymd. Jag mäter vid värdgränssnittet och korrelerar med pod-IP-adresser och portar.

På så sätt förblir mätresultaten tillförlitliga, även om många arbetsbelastningar körs tätt intill varandra.

Integration i observabilitetsstackar

Jag ersätter inte min övervakning, utan kompletterar den med eBPF. bcc-verktygen ger mig djupet, medan metriksystem, loggar och APM visar bredden; tillsammans ger de en sammanhängande bild. Vid behov leder jag spår från bcc vidare till loggpipelines, utlöser ögonblicksbilder vid incidenter och dokumenterar resultaten i teamet. För punktvisa profiler använder jag sampling utöver tidslinjer från metriker, så att avvikelser påtaglig kommer att bli. Den som dessutom föredrar skriptspråk hittar i bpftrace i webbhotellet ett smidigt sätt att besvara ad hoc-frågor med miniskript.

Vanliga hinder – och hur jag hanterar dem

• Noisy Neighbor: Enskilda jobb genererar kortvarig men intensiv belastning. execsnoop plus profiler Dessa mönster avslöjas på ett tillförlitligt sätt; jag sätter tidsgränser för dem eller isolerar dem med hjälp av kvoter.
• NUMA och affiniteter: Höga latenser trots lediga kärnor tyder på åtkomst över NUMA-gränserna. Jag kontrollerar CPU-affiniteter, minnesbindning och IRQ-fördelning.
• IRQ/SoftIRQ-hotspots: Nätverksbelastningen kan överbelasta ksoftirqd-kärnor. Jag övervakar återutsändningar, fördelar IRQ:er via RSS/köer och justerar RPS/XPS.
• Effekter av sidcache: Kallstarter går långsammare. Jag tar hänsyn till uppvärmningsfaser och jämför cachestat-Värden före och efter belastning.
• Kärnuppdateringar: Kprobes kan ändras vid versionshopp. Jag föredrar stabila spårpunkter, testar i förväg och har en minimuppsättning redo.

Arbetsflöden som har visat sig fungera väl

• Översikt över händelsen: 60–120 sekunders kombinerad körning (execsnoop, runqlat, biolatency, tcpretrans, profile). Därefter fokuserar jag på det subsystem som sticker ut.
• Baslinjerutin: Korta mätningar varje vecka på nyckelvägar (t.ex. lagrings- och nätverksprofil). På så sätt upptäcker jag avvikelser i ett tidigt skede.
• Validering av förändringar: Före och efter konfigurationsändringar jämför jag samma mätpunkter för att kunna kvantifiera effekten.

Kontinuerlig prestandautveckling för Linux

Jag betraktar performance som en pågående process, inte som Engångsåtgärd. I CI/CD integrerar jag korta eBPF-baserade kontroller för att upptäcka regressioner i ett tidigt skede och stoppa dem innan de rullas ut. Under underhållsfönstren mäter jag typiska vägar under belastning, skapar baslinjer och dokumenterar acceptabla latensintervall. På så sätt upptäcker jag avvikelser snabbt och slipper gissa vid incidenter, eftersom jämförelsedata tillgänglig. Denna rutin bidrar direkt till tillgänglighet, kostnadskontroll och användarupplevelse.

Mini-fallstudie: Från symptom till orsak på 12 minuter

Ett API-kluster rapporterar ökande 99p-fördröjningar med oförändrad RPS. Jag startar en incident-snapshot: tcpconnect visar inga avvikelser vid uppkopplingen, tcpretrans förblir låg – nätverket är det i alla fall inte. runqlat rapporterar korta men frekventa väntetider; profiler visar hotspots i en JSON-serialisering. Samtidigt övervakar jag med cachestat en nedgång i cache-träfffrekvensen under toppbelastningar. Korrelationen tyder på: Många små datapaket som serialiseras synkront och skrivs omedelbart.

Jag verifierar med ext4 är långsammare, som visar fsync-operationer som varar flera millisekunder på samma volym för API-processen; biolatency bekräftar sporadiska kötoppar på den berörda enheten. Åtgärd: Batchbehandling av skrivningar, större buffert och asynkron tömning vid mindre känsliga punkter. Efter implementeringen minskar 99p-latenserna med 35 %, cache-träfffrekvensen återhämtar sig, och runqlat visar återigen smala fördelningar.

Sammanfattning för praktiken

Med bcc Med hjälp av verktyg och eBPF får jag snabbt en överblick över CPU, I/O och nätverk utan att behöva ändra i applikationerna. Checklistan med execsnoop, opensnoop, ext4slower, biolatency, biosnoop, cachestat, tcpconnect, tcpaccept, tcpretrans och runqlat utgör en bra utgångspunkt. Som komplement använder jag profilering för att synliggöra flaskhalsar och optimera kodflöden. Tack vare tydliga policyer, loggning och begränsningar förblir användningen i kärnan säker och överskådlig. Den som tillämpar denna metod konsekvent löser prestandaproblem snabbare, planerar kapaciteten bättre och sänker kostnaderna per förfrågan.