perf top Linux: CPU-hotspots in de kernel herkennen

Met perf top Onder Linux kan ik binnen enkele seconden achterhalen welke kernel-functies momenteel de meeste CPU-tijd in beslag nemen en waar zich knelpunten voordoen. In deze handleiding laat ik aan de hand van duidelijke stappen zien hoe ik live-hotspots herken, de uitvoer correct interpreteer en daaruit snelle optimalisaties voor de scheduler, het netwerk en het geheugen afleid.

Centrale punten

Ik vind de liveweergave van perf ideaal als startpunt, omdat het meteen de grootste tijdverslinders zichtbaar maakt. De percentages per symbool laten me zien of de bottleneck zich in de Kernel of zich in de gebruikersruimte bevindt. Aan de hand van terugkerende patronen bepaal ik of locks, IRQ’s, het netwerk of het geheugen de overhand hebben. Vervolgens baken ik de hotspot af met meer gedetailleerde tools en test ik de wijzigingen direct onder belasting. Zo verbeter ik stap voor stap de CPU-de bezettingsgraad verhogen en de latentie duurzaam verlagen.

• Live-hotspots herkennen en prioriteren
• Procentuele aandelen per functie correct interpreteren
• Kernfocus instellen: IRQ's, vergrendelingen, geheugen
• Werkstroom: top → record → rapport
• Optimalisaties gericht verifiëren

Wat is Perf Top en waar gebruik ik het voor?

Ik gebruik perf top, om tijdens het uitvoeren van een taak direct te zien welke symbolen het grootste deel van de CPU-tijd in beslag nemen. De tool maakt gebruik van hardware-prestatiemeters en toont mij met korte tussenpozen een bijgewerkte ranglijst van de meest CPU-intensieve functies. Volgens Linux-Magazin beheerst perf zowel profilering als tracing, wat de Live-weergave naadloos koppelt aan diepgaandere analyses. In de gebruikelijke werkwijze vul ik de momentopname aan met perf record en perf report om callgraphs en exacte paden te onderzoeken. Zo beantwoord ik de centrale vraag: waar brengt de CPU precies op dat moment – in de netwerkstack, in het geheugensubsysteem, in de scheduler of in een stuurprogramma?

perf top installeren en starten

Na de installatie via het distributiepakket voer ik het volgende in: perf top wordt doorgaans met uitgebreide rechten uitgevoerd, zodat kernel-symbolen en systeemgebeurtenissen zichtbaar worden. Een eenvoudige start met „perf top“ volstaat om een eerste live-weergave op te bouwen en dominante functies in kaart te brengen. Als ik me op afzonderlijke processen wil concentreren, voeg ik de PID met -p; voor specifieke CPU's gebruik ik -C met een lijst of een bereik. Gebeurtenissen stel ik in met -e, bijvoorbeeld cpu-cycles, instructions of branch-misses, afhankelijk van de vraag die ik wil beantwoorden. Voor reproduceerbare resultaten start ik de meting tijdens een daadwerkelijke belasting, zodat Hotspots duidelijk naar voren komen en niet verloren gaan in de ruis van de stationaire motor.

Zo lees ik deze uitgave op de juiste manier

In de lijst beoordeel ik eerst de Procentcijfers per symbool, omdat ze de relatieve tijdsverdelingen weergeven. Hoge percentages bij systeemfuncties duiden op een bottleneck in de kernel, terwijl dominante symbolen in de gebruikersruimte eerder wijzen op app-logica. Als ik veel scheduler-routines zie, denk ik aan te veel actieve threads, ongunstige affiniteiten of ongeschikte prioriteiten. Als geheugenfuncties bovenaan verschijnen, controleer ik toewijzingspatronen, page-fouts, NUMA-lokaliteit en caches. Bij netwerkpaden kijk ik naar IRQ-verdeling, Gro/TSO-instellingen en het gedrag van stuurprogramma’s, omdat dergelijke details de Latency sterk beïnvloeden.

Typische oorzaken van kernel-hotspots

Veel hotspots ontstaan doordat veel kleine kosten samen een grote Belasting bij elkaar opgeteld. Vaak zorgen overmatige contextwisselingen, lock-concurrentie en ongelijk verdeelde IRQ’s voor een toename van de CPU-tijd. Ook gefragmenteerde geheugenstructuren, inefficiënt gebruik van slabs of voortdurende paging leiden tot onnodige cycli. Als een bepaald stuurprogramma me opvalt, breng ik dit in verband met de workload, de hardware en de versie om neveneffecten te beperken. Bij multicore-systemen controleer ik bovendien op false sharing, omdat gedeelde cache-lijnen volgens de kernel-documentatie al snel leiden tot dure Overhead kunnen zorgen.

Een voorbeeld van een analyse van een hotspot

Als ik gedurende een langere periode een zeer hoog aandeel in netwerkgerelateerde functies zie, maak ik allereerst onderscheid tussen verschillende soorten belasting: kleine versus grote pakketten, TLS versus onversleuteld verkeer, veel verbindingen versus weinig langdurige sessies, om de Oorzaak inperken. Vervolgens ga ik dieper in op de materie met `perf record` en `perf report`, schakel ik callgraphs (-g) in en vergelijk ik de paden over meerdere runs. Als in plaats daarvan het geheugenbeheer de boel verstoort, controleer ik de allocator, Huge Pages, THP-instellingen en NUMA-affiniteit, omdat hier al snel onnodige omwegen ontstaan. Scheduler-hotspots interpreteer ik vaak als een teken van te veel runnable-threads of een ongeschikte CPU-toewijzing. Ik verander altijd slechts één Parameters per doorloop, zodat ik het effect duidelijk kan toewijzen.

uitmuntend in hostingomgevingen

In hosting-scenario's zie ik vaak hoe kleine kernelkosten de Latency van verschillende diensten bij elkaar optellen. Parallel draaiende containers, VM’s en database-instanties verschuiven het profiel duidelijk in de richting van netwerk, opslag en scheduler. Met perf top kan ik vaststellen of de knelpunten eerder liggen in de IRQ-afhandeling, de verwerking van softirq’s of in lock-paden. Vervolgens neem ik de kernelversie, NUMA-indeling, IRQ-affiniteiten en wachtrijdieptes mee in de analyse, omdat deze factoren op elkaar inwerken. Wie zich hier verder in wil verdiepen, vindt in deze handleiding over CPU-knelpunten analyseren andere praktische aanknopingspunten die ik in de praktijk regelmatig gebruik.

Praktische handleiding voor de analyse

Ik begin met een reproduceerbaar belastingsscenario, zodat de metingen vergelijkbaar blijven en Hotspots stabiel verschijnen. Daarna start ik perf top en noteer ik de dominante symbolen over meerdere verversingen heen. Deze momentopname verdicht ik met perf record/report tot een duidelijk beeld via callgraphs, zodat ik het pad naar de kostbare plek kan herkennen. Vervolgens pas ik doelgericht slechts één ding aan, bijvoorbeeld een IRQ-affiniteit of een wachtrijdiepte, en meet ik opnieuw. Pas als het effect duidelijk is, ga ik verder met de volgende Stap en leg de bevindingen vast voor toekomstige onderhoudsperiodes.

Wanneer andere hulpmiddelen zinvol zijn

Voor een historisch overzicht, gedetailleerdere callgraphs of specifieke gebeurtenisketens maak ik gebruik van perf record/report, ftrace of eBPF. Tracepoints helpen me om bepaalde paden gericht te onderzoeken, terwijl ik met BPF-programma’s flexibele statistieken verkrijg. Als ik dieper in kernelpaden wil kijken, bieden eBPF-analysetools waardevolle signalen direct ter plaatse. Voor cache- en sharing-problemen zijn perf-c2c en pahole nuttig, zodra de hotspot duidelijk is geïdentificeerd. Zo werk ik de analyse stap voor stap uit, van het live-beeld naar de oorzaak, zonder me te verliezen in irrelevante details te verliezen.

Samplingopties en filters in de praktijk

Ik pas de Bemonstering-strategie toe te passen op de vraag, in plaats van alles klakkeloos te meten. Bij sporadische pieken verhoog ik de bemonsteringsfrequentie en verkort ik de weergave-intervallen om vluchtige pieken vast te leggen. Voor procesfocus stel ik -p in op de relevante PID, voor CPU-focus -C op de ‘hete’ kernen. Met -e stel ik de gebeurtenis in, bijvoorbeeld cpu-cycles voor brede profilering of cache-misses als ik vermoed dat het geheugengedrag de oorzaak is. Ik gebruik callgraphs (-g) zodra ik een hotspot grofweg heb gelokaliseerd en de Oorzaak in de stack wil vinden.

De volgende tabel toont praktische toetscombinaties die ik in het dagelijks leven vaak gebruik, evenals typische toepassingen per optie:

Optie	Effect	Gebruik
-p PID	Beperkt de meting tot één proces	App-specifieke Hotspots beperken
-C Lijst met CPU's	Focus op geselecteerde kernactiviteiten	NUMA/IRQ-verdeling controleren
-e Evenement	Kies een hardware- of softwaregebeurtenis	cycli, instructies, cache-misses
-g	Callgraph-sampling inschakelen	Dure paden in de Stapel herkennen
–kernel/–user	Filtert op kernel- of gebruikersruimte	De bron van de CPU-tijd scheiden
–sorteren	Gesorteerd op symbool, DSO, dso:symbool	Leesbaarheid van de Ranglijst verhogen

Ik test configuraties altijd even kort uit voordat ik langere metingen start, zodat de Toon stabiel blijft en er geen bijwerkingen optreden. Vooral bij een hoge samplingfrequentie let ik op de overhead, om het systeem niet onnodig te belasten. Bij containerhosts controleer ik bovendien of namespace- en cgroup-limieten het zicht beperken. Voor reproduceerbare benchmarks documenteer ik alle opties, inclusief kernel- en stuurprogrammaversies. Deze werkwijze bespaart me later veel Tijd bij het duiden van veranderingen.

Interpretatie van subsystemen: netwerk, opslag, scheduler

Als er netwerkstraten bovenaan staan, controleer ik eerst de IRQ-affiniteiten, RSS/Receive-Side-Scaling en offloads zoals GRO/TSO, omdat deze instellingen de Doorvoer-De latentie-balans aanpassen. Bij opvallende geheugenfuncties kijk ik naar toewijzingspatronen, Huge Pages, slab-statistieken en page-fault-percentages. Scheduler-belasting breng ik vaak in verband met een te groot aantal threads, ontbrekende CPU-affiniteit of oneerlijke prioritering. Voor gerichte kernelgebeurtenissen plaats ik bovendien tracepoints of maak ik gebruik van bpftrace in de hostingomgeving, om hypothesen te bevestigen. Zo koppel ik de live-waarneming uit perf top aan dieper gelegen meetpunten en kom ik sneller tot de eigenlijke Oorzaak.

Voorwaarden en zichtbaarheid van de symbolen

Dus dat perf top Bij het omzetten van alle relevante kernel-symbolen let ik op twee dingen: de juiste machtigingen en beschikbare symboolinformatie. Op productiesystemen is kernel.perf_event_paranoid vaak hoog ingesteld. Voor diepgaande inzichten in de kernel verlaag ik deze waarde tijdelijk of werk ik als root met de benodigde rechten (CAP_PERFMON/CAP_SYS_ADMIN). Als kerneladressen zijn verborgen (kptr_restrict), zie ik meestal toch namen, maar geen ruwe adressen – dat is voor mij voldoende om prioriteiten te stellen. Voor de gebruikersruimte installeer ik de bijbehorende debuginfo-pakketten, zodat perf top functienamen weergeeft in plaats van offsets. Dat vermindert het giswerk en versnelt het opsporen van de oorzaak.

Procentuele waarden en valkuilen bij steekproeven

Ik interpreteer de percentages in de lijst als relatieve aandelen van de gemeten monsters, niet als exacte CPU-belasting in de tijd. Als ik meerdere gebeurtenissen selecteer, kan Multiplexing toepassen: Perf verdeelt de tellers over de tijd en genormaliseerd de weergave. Om een duidelijk beeld te krijgen, meet ik eerst in het algemeen met CPU-cycli of instructies en schakel ik speciale gebeurtenissen pas later in. Kortstondige pieken vang ik op met een hogere frequentie (-F) en kortere intervallen; bij rustige systemen volstaat de standaardfrequentie. Ik houd er bovendien rekening mee dat Inactief-fasen en frequentiewijzigingen (Turbo, Governor) die de waarneming kunnen verstoren. Voor vergelijkende metingen stel ik daarom de klok- en energie-instellingen uniform in.

Callgraphs in detail

Als ik een hotspot heb geïdentificeerd, vergroot ik de informatiewaarde ervan met behulp van callgraphs. Met -g en met een geschikte unwinding-methode krijg ik het pad naar de kostbare plek. Frame-pointers of DWARF-unwinding leveren me stabiele stacks op; waar beschikbaar, maak ik gebruik van hardware-ondersteunde terugsprongbuffers (LBR) voor zeer nauwkeurige ketens. Ik vergroot de mmap-buffers slechts zoveel als nodig is om de overhead laag te houden. Als de stack veel hulpfuncties vertoont, let ik op inclusief vs. exclusief Kosten: Het is van doorslaggevend belang of de functie zelf duur is of alleen als doorvoerroute een dominante rol speelt. Dit onderscheid bespaart me vaak uren bij het opsporen van de oorzaak.

Werken in containers en VM's

In containeromgevingen controleer ik of mijn weergave van cgroups en dat de naamruimten correct zijn. Ik richt mijn metingen op de relevante PID’s en CPU’s, zodat luidruchtige buren het beeld niet vertekenen. Voor VM’s controleer ik of de virtuele PMU is ingeschakeld; anders mis ik nauwkeurige hardware-events en zie ik voornamelijk softwaresignalen. KVM-hosts herken ik vaak aan symbolen rondom kvm_vcpu of vmx/svm. In dergelijke scenario's houd ik de analyses van de host en de guest strikt gescheiden, zodat ik oorzaak en gevolg niet door elkaar haal.

Herkenbare patronen en snelle hypothesen

In het dagelijks leven zijn er bepaalde patronen die hun nut hebben bewezen en die ik meteen controleer:

• Concurrentie op het gebied van sloten: Duiken queued_spin_lock_slowpath of mutex_spin_on_owner Als dat het geval is, zijn de gegevensstructuren te grof ingedeeld of zijn de werkwachtrijen te krap. Ik verminder de concurrentie door middel van sharding, een fijnere vergrendelingsgranulariteit of aangepaste batchgroottes.
• Afdrukken vanuit de planner: Komen steeds vaker voor schedule(), pick_next_task_fair of wake-up-paden, pas ik het aantal threads, affiniteiten en prioriteiten aan. Vaak volstaat het om “praatgrage” threads wat te temperen of de CPU-instellingen duidelijk te definiëren.
• Netwerk-Softirqs: pieken bij net_rx_action, napi_poll of checksum-offloads duiden op pakketstormen of een suboptimale verdeling van RSS en IRQ’s. Ik wijs IRQ’s toe aan geschikte kernen en pas GRO/TSO aan voor het gewenste doorvoer/latentieprofiel.
• Opslagpaden: Veel tijd in do_page_fault, copy_user_* Of met slab-functies kan ik toewijzingspatronen, THP/Huge Pages en NUMA-lokaliteit controleren. Een verkeerde plaatsing kost hier onopgemerkt heel veel cycli.
• RCU en timers: Domineren rcu_core of timer-callbacks, herzie ik de polling- en batch-strategieën van mijn diensten om het systeem soepeler te laten draaien.

Zich verdiepen in meetdiscipline en reproduceerbaarheid

Om de testruns goed vergelijkbaar te houden, houd ik de omgevingsfactoren constant: CPU-governor, turbo-standen, achtergrondtaken en zelfs de kamertemperatuur bij dicht op elkaar geplaatste knooppunten. Ik koppel testbelastingen aan bepaalde kernen en isoleer eventueel oververhitte CPU’s, zodat de beslissingen van de scheduler stabiel blijven. Wijzigingen documenteer ik, inclusief de versies van de kernel, stuurprogramma’s en firmware. Bij risicovollere aanpassingen plan ik terugvalpunten in en voer ik direct na de ingreep opnieuw metingen uit. Zo krijg ik een betrouwbare Voor/Na-Een verhaal dat ik zelfs maanden later nog steeds kan begrijpen.

Praktische tips: commando’s die ik vaak gebruik

Afhankelijk van de vraag gebruik ik beknopte recepten:

• Uitgebreide scoping onder belasting: perf top -e cpu-cycles –kernel –user
  Een snel overzicht om te zien of de kernel of de gebruikersruimte de touwtjes in handen heeft.
• Procesfocus met Callgraph: perf top -p PID -g –kernel –user
  Toon mij de live-paden van de betreffende toepassing, zonder systeemruis.
• CPU-focus: perf top -C 2-5 -e cpu-cycles -g
  Helpt bij NUMA- of IRQ-hotspots wanneer slechts enkele kernen “oververhit” raken.
• Verdacht van opslag: perf top -e cache-misses -e cycles -g –kernel
  Geeft opslagpaden weer in verhouding tot cycli.
• Tijdelijke pieken vastleggen: perf top -F 999 -I 1000 -e cycles
  Een hogere frequentie en kortere weergave-intervallen zorgen ervoor dat korte pieken worden geregistreerd.

Interpretatiehulp voor specifieke subsystemen

Op Netwerk Ik houd niet alleen de NAPI- en RX/TX-paden in de gaten, maar ook de TLS/crypto-onderdelen, die bij een hoog aantal handshakes de overhand kunnen krijgen. Ik controleer of zero-copy of coalescing zinvol werkt en of grote segmenten (TSO/GSO) mijn latentiebudgetten overschrijden. In de Geheugen-Op dit gebied kijk ik naar THP: helpt het mijn belasting, of zorgen split-/merge-events voor storingen? Bij Opslag ik bedoel blk_mq-Symbolen en io_uring-paden als indicatie van wachtrijdieptes en samenvoegstrategieën. Bij de planner Ik koppel wakeup-lawines aan lock- of IO-ketens en ontlast de paden door middel van backpressure in plaats van “meer threads”.

De grenzen van perf top en wanneer ik van koers verander

Omdat perf top Aangezien het op steekproeven is gebaseerd, zie ik gemiddelde beelden beter dan afzonderlijke gebeurtenissen. Voor deterministische verloopketens schakel ik over op tracepoints, ftrace of eBPF om precieze causale verbanden aan te tonen. Als ik exacte kwantificering nodig heb (bijv. instructies per verzoek), combineer ik dit met perfect stat of offline-analyses vanuit perf record/report. Als ik onduidelijke stacks tegenkom (ontbrekende symbolen, foutieve unwinding), zorg ik eerst dat ze zichtbaar worden – al het andere zou rondtasten in het duister zijn.

Kort samengevat

Met perf top Ik zie in realtime waar de CPU in de kernel tijd verliest en welke symbolen ik als eerste moet onderzoeken. Op basis van de percentages, terugkerende patronen en de scheiding tussen kernel- en gebruikersruimte bepaal ik gerichte vervolgstappen. Vervolgens vat ik de bevindingen samen met `perf record/report`, verifieer ik wijzigingen onder belasting en documenteer ik mijn meetketen. In hostingomgevingen loont deze aanpak bijzonder goed, omdat veel diensten en containers van elkaar profiteren zodra kernelpaden efficiënter werken. Wie dit proces onder de knie heeft, bespaart dagen aan diagnose en verlaagt Latencies en zorgt voor merkbaar stabielere responstijden onder reële belasting.