perf top Linux: Identificering af CPU-hotspots i kernen

Med perf top Under Linux kan jeg på få sekunder finde ud af, hvilke kernefunktioner der i øjeblikket optager mest CPU-tid, og hvor der opstår flaskehalse. I denne vejledning viser jeg ved hjælp af klare trin, hvordan jeg identificerer live-hotspots, fortolker resultaterne korrekt og ud fra dem udleder hurtige optimeringer for scheduler, netværk og hukommelse.

Centrale punkter

Jeg synes, at live-visningen af perf Det er perfekt som udgangspunkt, fordi det straks viser de største tidsslugere. Procentdelene ved hvert symbol viser mig, om flaskehalsen ligger i Kernen eller ligger i brugerrummet. Ud fra tilbagevendende mønstre kan jeg se, om det er låse, IRQ’er, netværk eller hukommelse, der dominerer. Derefter indsnævrer jeg problemområdet med mere avancerede værktøjer og tester ændringerne direkte under belastning. På den måde forbedrer jeg trin for trin CPU-Udnyttelse og reducerer latenstiderne på lang sigt.

• Live-hotspots identificere og prioritere
• Procentandele fortolke korrekt for hver funktion
• Hovedfokus indstille: IRQ'er, låse, hukommelse
• Arbejdsgang: top → optegnelse → rapport
• Optimeringer målrettet verificere

Hvad er »perf top«, og hvad bruger jeg det til?

Jeg bruger perf top, så man under kørende belastning straks kan se, hvilke symboler der bruger den største andel af CPU-tiden. Værktøjet har adgang til hardware-performance-tællere og viser mig med korte intervaller en opdateret rangliste over de mest ressourcekrævende funktioner. Ifølge Linux-Magazin mestrer perf både profilering og sporing, hvilket Live-visning sammenhængende med mere dybdegående analyser. I den sædvanlige arbejdsgang supplerer jeg øjebliksbilledet med »perf record« og »perf report« for at undersøge callgraphs og præcise stier. På den måde besvarer jeg det centrale spørgsmål: Hvor bruger CPU netop nu – i netværksstakken, i lagringsundersystemet, i scheduleren eller i en driver?

Installer og start perf top

Efter installationen via distributionspakken kører jeg perf top kører som regel med udvidede rettigheder, så kernelsymboler og systemhændelser bliver synlige. En simpel opstart med „perf top“ er nok til at oprette en første live-visning og få overblik over de dominerende funktioner. Hvis jeg har brug for at fokusere på enkelte processer, hænger jeg PID med -p; til specifikke CPU'er bruger jeg -C med en liste eller et interval. Begivenheder definerer jeg med -e, f.eks. cpu-cycles, instructions eller branch-misses, afhængigt af hvilket spørgsmål jeg ønsker at afklare. For at opnå reproducerbare resultater starter jeg målingen under en reel belastning, så Hotspots skal fremstå tydeligt og ikke forsvinde i tomgangsstøjen.

Sådan læser jeg udgaven korrekt

På listen vurderer jeg først Procenttal pr. symbol, fordi de afspejler de relative tidsandele. Høje andele ved systemfunktioner tyder på en flaskehals i kernen, mens dominerende symbols i brugerrummet snarere peger på app-logik. Hvis jeg ser mange scheduler-rutiner, tænker jeg på for mange aktive tråde, ugunstige affiniteter eller uhensigtsmæssige prioriteter. Hvis hukommelsesfunktioner dukker op øverst, tjekker jeg allokeringsmønstre, sidefejl, NUMA-lokalitet og cacher. Ved netværksstier ser jeg på IRQ-fordeling, Gro/TSO-indstillinger og driveradfærd, fordi sådanne detaljer er Forsinkelse har stor indflydelse på.

Typiske årsager til kernel-hotspots

Mange hotspots opstår, fordi mange små udgifter tilsammen udgør en stor Belastning akkumuleres. Ofte øger hyppige kontekstskift, lock-konkurrence og ulige fordeling af IRQ’er CPU-tiden. Ligeledes binder fragmenterede hukommelsesstrukturer, ineffektiv brug af slab’er eller konstant paging unødvendige cyklusser. Hvis jeg bemærker en bestemt driver, sætter jeg den i sammenhæng med arbejdsbelastning, hardware og version for at indsnævre bivirkningerne. På multicore-systemer tjekker jeg desuden for false sharing, da delte cache-linjer ifølge kernel-dokumentationen hurtigt kan føre til dyr Overhead kan give anledning til bekymring.

Eksempel på en analyse af et hotspot

Hvis jeg ser, at der over en længere periode er en meget høj andel af netværksrelaterede funktioner, skelner jeg først mellem forskellige belastningstyper: små kontra store pakker, TLS kontra klartekst, mange forbindelser kontra få langvarige sessioner, for at Årsag at indsnævre problemet. Derefter går jeg mere i dybden med »perf record« og »perf report«, aktiverer callgraphs (-g) og sammenligner stierne over flere kørsler. Hvis det i stedet er hukommelsesstyringen, der dukker op, tjekker jeg allokatoren, Huge Pages, THP-indstillingerne og NUMA-affinitet, fordi der hurtigt opstår unødvendige veje her. Scheduler-hotspots tolker jeg ofte som et tegn på for mange kørbare tråde eller en uhensigtsmæssig CPU-binding. Jeg ændrer altid kun én Parametre pr. gennemløb, så jeg kan tilordne effekten korrekt.

Perf Top i hostingmiljøer

I hosting-scenarier ser jeg ofte, hvordan små kerneomkostninger påvirker Forsinkelse mange tjenester. Parallelt kørende containere, VM’er og databaseinstanser flytter profilen markant i retning af netværk, lagring og scheduler. Med »perf top« kan jeg se, om flaskehalse snarere ligger i IRQ-håndtering, SoftIRQ-behandling eller i låseveje. Derefter inddrager jeg kerneversion, NUMA-layout, IRQ-affiniteter og kødybder i analysen, da disse faktorer påvirker hinanden. Hvis du ønsker at gå mere i dybden, kan du finde yderligere information i denne vejledning til Analyse af flaskehalse i CPU’en andre praktiske tilgange, som jeg regelmæssigt anvender i praksis.

Praktisk vejledning til analyse

Jeg starter med et reproducerbart belastningsscenarie, så målingerne forbliver sammenlignelige, og Hotspots dukker stabilt op. Derefter starter jeg »perf top« og noterer de dominerende symboler over flere opdateringer. Dette øjebliksbillede sammenfatter jeg med »perf record/report« til et klart overblik over callgraphs, så jeg kan identificere stien til det ressourcekrævende sted. Derefter ændrer jeg målrettet kun én ting, for eksempel en IRQ-affinitet eller en kødybde, og måler igen. Først når effekten er tydelig, går jeg videre til det næste Trin gennemgå og dokumentere resultaterne med henblik på fremtidige vedligeholdelsesvinduer.

Hvornår andre værktøjer er en god idé

Når jeg har brug for et historisk overblik, mere detaljerede callgraphs eller specifikke hændelseskæder, benytter jeg mig af perf record/report, ftrace eller eBPF. Tracepoints hjælper mig med at belyse bestemte stier, mens jeg med BPF-programmer får fleksible målinger. Når jeg vil se nærmere på kernelstier, leverer eBPF-analyseværktøjer værdifulde signaler direkte på selve stedet. Til cache- og delingsproblemer er perf-c2c og pahole nyttige, så snart hotspottet er tydeligt identificeret. På den måde kan jeg gradvist gå fra live-visningen til årsagen uden at fordybe mig i irrelevante Detaljer at tabe.

Sampling-indstillinger og filtre i praksis

Jeg passer Prøveudtagning-strategi til det konkrete problem i stedet for at måle alt generelt. Ved sporadiske spidsbelastninger øger jeg samplingfrekvensen og forkorter visningsintervallerne for at fange flygtige spidsbelastninger. For at fokusere på processer sætter jeg -p til den relevante PID, og for at fokusere på CPU'en sætter jeg -C til de aktive kerner. Med -e styrer jeg begivenheden, f.eks. cpu-cycles til bred profilering eller cache-misses, hvis jeg har mistanke om hukommelsesadfærd. Jeg bruger callgraphs (-g), så snart jeg groft har lokaliseret et hotspot, og Årsag som jeg vil finde i stakken.

Den følgende tabel viser praktiske tastkombinationer, som jeg ofte bruger i hverdagen, samt typiske anvendelsesformål for hver enkelt mulighed:

Mulighed	Effekt	Brug
-p PID	Begrænser målingen til en proces	App-specifikke Hotspots indsnævre
-C CPU-liste	Fokus på udvalgte kerneområder	Kontroller NUMA/IRQ-fordelingen
-e Begivenhed	Vælg hardware- eller softwarehændelse	cyklusser, instruktioner, cache-fejl
-g	Aktiverer Callgraph-sampling	Dyre stier i Stak Genkende
–kernel/–user	Filtrerer efter kernel eller brugerrum	Adskille kilden til CPU-tiden
–sort	Sorteret efter symbol, DSO, dso:symbol	Læsbarheden af Rangliste øge

Jeg tester altid konfigurationerne kort, før jeg starter længerevarende målinger, så Vis forbliver stabil, og der ikke opstår bivirkninger. Især ved høje samplingsfrekvenser er jeg opmærksom på overhead for ikke at belaste systemet unødigt. Ved container-værter tjekker jeg desuden, om namespace- og cgroup-begrænsninger indskrænker overblikket. For at sikre reproducerbare benchmarks dokumenterer jeg alle indstillinger, herunder kerne- og driverversioner. Denne disciplin sparer mig for meget arbejde senere Tid ved klassificeringen af ændringer.

Fortolkning af delsystemer: Netværk, lager, planlægger

Når netværksstierne er angivet øverst, tjekker jeg først IRQ-affiniteter, RSS/Receive-Side-Scaling og offloads som GRO/TSO, fordi disse indstillingsmuligheder har indflydelse på Gennemstrømning-Ændre latenstidsbalancen. Ved påfaldende hukommelsesfunktioner ser jeg på allokeringsmønstre, Huge Pages, slab-statistikker og page-fault-rater. Scheduler-belastning forbinder jeg ofte med et for stort antal tråde, manglende CPU-affinitet eller uretfærdig prioritering. For målrettede kernel-begivenheder sætter jeg desuden tracepoints eller bruger bpftrace i hosting, for at bekræfte hypoteser. På den måde sammenholder jeg live-observationerne fra perf top med målinger fra dybere punkter og når hurtigere frem til selve Årsag.

Forudsætninger og symbolernes synlighed

Så det perf top Når jeg løser alle relevante kernelsymboler, er jeg opmærksom på to ting: de rette rettigheder og tilgængelige symboloplysninger. På produktive systemer er kernel.perf_event_paranoid ofte sat højt. For at få indblik dybt ned i kernen sænker jeg midlertidigt denne værdi eller arbejder som root med de nødvendige rettigheder (CAP_PERFMON/CAP_SYS_ADMIN). Hvis kerneadresserne er skjult (kptr_restrict), ser jeg som regel alligevel navne, men ingen råadresser – det er nok for mig til at prioritere. Til brugerrummet installerer jeg de tilhørende debuginfo-pakker, så perf top viser funktionsnavne i stedet for offset-værdier. Det mindsker gætteriet og gør det hurtigere at finde årsagen.

Procenttal og faldgruber ved stikprøveudtagning

Jeg fortolker procenttallene i listen som relative andele de målte prøver, ikke som den nøjagtige CPU-udnyttelse over tid. Hvis jeg vælger flere begivenheder, kan Multiplexing gribe ind: Perf fordeler kontraangrebene over tid og normaliseret visningen. For at få et klart billede måler jeg først bredt med CPU-cykler eller instruktioner og tilføjer først senere specielle begivenheder. Kortvarige spidsbelastninger fanger jeg med en højere frekvens (-F) og kortere intervaller; for systemer i rolig drift er standardfrekvensen tilstrækkelig. Jeg lægger desuden mærke til, at Inaktiv-faser og frekvensændringer (Turbo, Governor) kan forvride opfattelsen. Til sammenligningsmålinger standardiserer jeg derfor takt- og energiindstillingerne.

En dybdegående gennemgang af callgraphs

Når jeg har identificeret et hotspot, øger jeg indsigtsværdien ved hjælp af callgraphs. Med -g og med en passende unwinding-metode får jeg stien til det ressourcekrævende sted. Frame-pointer eller DWARF-unwinding giver mig stabile stakke; hvor det er muligt, bruger jeg hardwarebaserede returbuffere (LBR) for at opnå meget præcise kæder. Jeg øger mmap-bufferne kun så meget som nødvendigt for at holde overheadet på et lavt niveau. Hvis stakken viser mange hjælpefunktioner, er jeg opmærksom på inklusive vs. eksklusivt Omkostninger: Det afgørende er, om funktionen i sig selv er dyr, eller om den blot spiller en dominerende rolle som transitvej. Denne skelnen sparer mig ofte timer i fejlsøgningen.

Arbejde i containere og virtuelle maskiner

I container-miljøer tjekker jeg, om min visning af cgroups og at navneområderne er korrekte. Jeg fokuserer målingerne på de relevante PID’er og CPU’er, så støjende naboer ikke forvrænger billedet. For VM’er kontrollerer jeg, om den virtuelle PMU er aktiveret; ellers mangler jeg præcise hardwarebegivenheder og ser primært softwaresignaler. KVM-værter genkender jeg ofte på symboler omkring kvm_vcpu eller vmx/svm. I sådanne situationer adskiller jeg nøje analyser af værten og gæsten, så jeg ikke forveksler årsag og virkning.

Genkendelige mønstre og hurtige hypoteser

I hverdagen har visse mønstre vist sig at fungere, og dem tjekker jeg straks:

• Konkurrence om Lock: Dykning queued_spin_lock_slowpath eller mutex_spin_on_owner Ovenstående skyldes, at datastrukturerne er for groft opdelte, eller at arbejdskøerne er for smalle. Jeg reducerer konkurrencen ved hjælp af sharding, finere låsegranularitet eller ændrede batchstørrelser.
• Udskrivning fra planlægningsprogrammet: Der er en stigende tendens til schedule(), pick_next_task_fair eller wakeup-stier, justerer jeg antallet af tråde, affiniteter og prioriteter. Ofte er det nok at dæmpe “snakkesalige” tråde eller definere CPU-indstillingerne præcist.
• Netværks-Softirqs: Højdepunkter ved net_rx_action, napi_poll Eller checksum-offloads tyder på pakkestorme eller suboptimal fordeling af RSS og IRQ. Jeg tildeler IRQ’er til passende kerner og justerer GRO/TSO for at opnå den ønskede gennemstrømning/latensprofil.
• Lagringsstier: Masser af tid i do_page_fault, copy_user_* eller Slab-funktioner giver mig mulighed for at kontrollere allokeringsmønstre, THP/Huge Pages og NUMA-lokalitet. Forkert placering koster her ubemærket rigtig mange cyklusser.
• RCU og timere: At dominere rcu_core eller timer-callbacks, genovervejer jeg polling- og batch-strategierne for mine tjenester for at få systemet til at køre mere stabilt.

Uddybe målepræcision og reproducerbarhed

For at sikre, at testkørslerne kan sammenlignes på et ensartet grundlag, holder jeg miljøfaktorerne konstante: CPU-governor, turbo-tilstande, baggrundsopgaver og endda rumtemperaturen ved tætpakkede noder. Jeg tildeler testbelastninger til bestemte kerner og isolerer eventuelt overbelastede CPU’er, så schedulerens beslutninger forbliver stabile. Jeg dokumenterer ændringer sammen med versioner af kerne, drivere og firmware. Ved mere risikable justeringer planlægger jeg tilbageførselspunkter og foretager en ny måling umiddelbart efter indgrebet. På den måde får jeg et pålideligt Før/Efter-En historie, som jeg stadig kan forstå, selv flere måneder senere.

Praktiske tip: Kommandoer, jeg ofte bruger

Afhængigt af spørgsmålet bruger jeg kortfattede opskrifter:

• Omfattende scoping under belastning: perf top -e cpu-cycles –kernel –user
  Et hurtigt overblik over, om det er kernen eller brugerrummet, der bestemmer.
• Procesfokus med Callgraph: perf top -p PID -g –kernel –user
  Vis mig live-stier til den relevante applikation uden systemstøj.
• Fokus på CPU'en: perf top -C 2-5 -e cpu-cycles -g
  Hjælper ved NUMA- eller IRQ-hotspots, når kun få kerner “gløder”.
• Mistanke om lagring: perf top -e cache-misses -e cycles -g –kernel
  Viser hukommelsesstier i forhold til cyklusser.
• Fastgøre flygtige spidser: perf top -F 999 -I 1000 -e cykler
  Højere frekvens og kortere visningsintervaller registrerer korte spidser.

Fortolkningsvejledning til konkrete delsystemer

På Netværk Ud over NAPI og RX/TX-stier overvåger jeg også TLS/krypto-andele, som kan dominere ved høj håndtryksaktivitet. Jeg tjekker, om Zero-Copy eller coalescing fungerer hensigtsmæssigt, og om store segmenter (TSO/GSO) overskrider mine latenstidsbudgetter. I Hukommelse-området ser jeg på THP: Hjælper det min belastning, eller skaber split-/merge-begivenheder forstyrrende støj? Ved Opbevaring fortolker jeg blk_mq-Symboler og io_uring-stier som indikatorer for kødybder og sammenfletningsstrategier. Ved planlægningsprogram Jeg forbinder Wakeup-laviner med Lock- eller IO-kæder og aflaster stierne ved hjælp af backpressure i stedet for “flere tråde”.

Grænserne for »perf top« og hvornår jeg skifter taktik

Fordi perf top Da det er baseret på stikprøver, ser jeg gennemsnitsbilleder tydeligere end enkeltbegivenheder. Ved deterministiske forløbskæder skifter jeg til tracepoints, ftrace eller eBPF for at påvise præcise årsagssammenhænge. Hvis jeg har brug for nøjagtig kvantificering (f.eks. instruktioner pr. anmodning), kombinerer jeg med perf stat eller offline-analyser fra perf record/report. Hvis jeg støder på uklare stakke (manglende symboler, fejlbehæftet unwinding), sørger jeg først for at gøre dem synlige – alt andet ville være som at famle i blinde.

Kort opsummeret

Med perf top kan jeg i realtid se, hvor CPU’en bruger tid i kernen, og hvilke symboler jeg bør undersøge først. Ud fra procenttalene, de tilbagevendende mønstre og adskillelsen mellem kerne- og brugerrummet udleder jeg målrettede næste skridt. Derefter sammenfatter jeg resultaterne med perf record/report, verificerer ændringer under belastning og dokumenterer min målekæde. I hostingmiljøer betaler denne fremgangsmåde sig særligt godt, fordi mange tjenester og containere drager fordel af hinanden, så snart kernestierne kører mere effektivt. Den, der tilegner sig denne fremgangsmåde, sparer dage på fejlfinding og reducerer Forsinkelser og opnår mærkbart mere stabile responstider under reel belastning.