perf top Linux: Identifiera CPU-hotspots i kärnan

Med perf top Under Linux kan jag på några sekunder se vilka kärnfunktioner som för närvarande tar mest CPU-tid i anspråk och var flaskhalsar uppstår. I den här guiden visar jag, med hjälp av tydliga steg, hur jag identifierar live-hotspots, tolkar utdata på ett säkert sätt och utifrån detta drar slutsatser för snabba optimeringar av schemaläggare, nätverk och minne.

Centrala punkter

Jag anser att livevyn från perf Perfekt som utgångspunkt, eftersom det omedelbart visar de största tidstjuvarna. Procentandelarna per symbol visar mig om flaskhalsen finns i Kärnan eller om det ligger i användarutrymmet. Utifrån återkommande mönster avgör jag om det är lås, IRQ:er, nätverk eller minne som dominerar. Därefter avgränsar jag problemområdet med mer avancerade verktyg och testar ändringarna direkt under belastning. På så sätt förbättrar jag steg för steg CPU-utnyttjandet och minska latensen på ett hållbart sätt.

• Live-hotspots identifiera och prioritera
• Procentandelar tolka korrekt för varje funktion
• Huvudfokus ställa in: IRQ:er, lås, minne
• Arbetsflöde: topp → post → rapport
• Optimeringar verifiera på ett målinriktat sätt

Vad är Perf Top och vad använder jag det till?

Jag använder perf top, för att omedelbart kunna se vilka symboler som tar upp den största andelen av CPU-tiden medan programmet körs. Verktyget använder hårdvarans prestandamätare och visar mig med korta intervall en uppdaterad ranglista över de mest resurskrävande funktionerna. Enligt Linux-Magazin klarar perf både profilering och spårning, vilket gör att Live-vy sömlöst kopplar samman med djupare analyser. I det vanliga arbetsflödet kompletterar jag ögonblicksbilden med perf record och perf report för att undersöka callgraphs och exakta sökvägar. På så sätt besvarar jag den centrala frågan: Var tillbringar CPU just nu – i nätverksstacken, i lagringssubsystemet, i schemaläggaren eller i en drivrutin?

Installera och starta perf top

Efter installationen via distributionspaketet kör jag perf top körs vanligtvis med utökade behörigheter så att kärnsymboler och systemhändelser blir synliga. Det räcker med att starta programmet med „perf top“ för att skapa en första realtidsvy och identifiera dominerande funktioner. Om jag behöver fokusera på enskilda processer kopplar jag in PID med -p; för specifika processorer använder jag -C med en lista eller ett intervall. Händelser anger jag med -e, till exempel cpu-cycles, instructions eller branch-misses, beroende på vilken fråga jag vill utreda. För att få reproducerbara resultat startar jag mätningen under en verklig belastning, så att Hotspots tydligt framträda och inte försvinna i tomgångsbruset.

Så här läser jag tidningen på rätt sätt

I listan betygsätter jag först Procenttal per symbol, eftersom de återspeglar de relativa tidsandelarna. Höga andelar för systemfunktioner tyder på en flaskhals i kärnan, medan dominerande symboler i användarutrymmet snarare pekar på applikationslogik. Om jag ser många schemaläggningsrutiner tänker jag på för många aktiva trådar, ogynnsamma affiniteter eller olämpliga prioriteringar. Om minnesfunktioner dyker upp högt upp på listan kontrollerar jag allokeringsmönster, sidfel, NUMA-lokalitet och cacher. När det gäller nätverksvägar tittar jag på IRQ-fördelning, Gro/TSO-inställningar och drivrutinsbeteende, eftersom sådana detaljer Fördröjning påverka kraftigt.

Vanliga orsaker till hotspots i kärnan

Många hotspots uppstår eftersom många små kostnader sammantaget blir en stor Last summeras. Ofta ökar alltför många kontextbyten, låskonkurrens och ojämnt fördelade IRQ:er CPU-tiden. På samma sätt tar fragmenterade minnesstrukturer, ineffektiv användning av slab eller ständig paging upp onödiga cykler. Om jag upptäcker en viss drivrutin korrelerar jag den med arbetsbelastning, hårdvara och version för att begränsa bieffekter. På flerkärniga system kontrollerar jag dessutom falsk delning, eftersom delade cache-linjer enligt kärndokumentationen snabbt kan leda till kostsam Overhead kan orsaka.

Exempel på analys av en hotspot

Om jag ser att en viss typ av trafik har en konstant hög andel i nätverksrelaterade funktioner under en längre tid, börjar jag med att dela upp trafiktyperna: små kontra stora paket, TLS kontra klartext, många anslutningar kontra få långvariga sessioner, för att Orsak begränsa. Därefter fördjupar jag analysen med perf record och perf report, aktiverar callgraphs (-g) och jämför sökvägarna över flera körningar. Om det istället är minneshanteringen som är problemet kontrollerar jag allokatorn, Huge Pages, THP-inställningarna och NUMA-affinitet, eftersom onödiga vägar snabbt kan uppstå här. Jag tolkar ofta schemaläggarens hotspots som ett tecken på för många körbara trådar eller en olämplig CPU-bindning. Jag ändrar alltid bara en Parametrar per körning, så att jag kan koppla ihop effekten korrekt.

Perf Top i webbhotellsmiljöer

I webbhotellssammanhang ser jag ofta hur små kostnader för kärnan påverkar Fördröjning från många tjänster. Parallellt körda containrar, virtuella maskiner och databasinstanser förskjuter profilen tydligt mot nätverk, lagring och schemaläggare. Med perf top kan jag se om flaskhalsarna snarare ligger i IRQ-hantering, Softirq-bearbetning eller i låsvägar. Därefter tar jag med kärnversionen, NUMA-layouten, IRQ-affiniteter och ködjup i analysen, eftersom dessa faktorer samverkar. Den som vill fördjupa sig ytterligare hittar i denna guide till Analysera flaskhalsar i CPU:n ytterligare praktiska tillvägagångssätt som jag regelbundet använder i mitt arbete.

Praktisk handbok för analys

Jag börjar med ett reproducerbart belastningsscenario så att mätningarna förblir jämförbara och Hotspots dyker upp stabilt. Därefter startar jag perf top och noterar de dominerande symbolerna över flera uppdateringar. Denna ögonblicksbild sammanfattar jag med perf record/report till en tydlig bild av callgraferna, så att jag kan identifiera vägen till den resurskrävande delen. Därefter ändrar jag målmedvetet bara en sak, till exempel en IRQ-affinitet eller en ködjup, och mäter på nytt. Först när effekten är tydlig går jag vidare till nästa Steg genomgå och dokumentera resultaten inför framtida underhållsperioder.

När andra verktyg är lämpliga

För en historisk översikt, mer detaljerade callgraphs eller specifika händelsekedjor använder jag perf record/report, ftrace eller eBPF. Tracepoints hjälper mig att belysa specifika vägar, medan jag med BPF-program får fram flexibla mätvärden. När jag vill granska kärnvägarna mer ingående ger eBPF-analysverktyg värdefulla signaler direkt på plats. När det gäller cache- och delningsproblem är perf-c2c och pahole till stor hjälp så snart hotspoten har identifierats tydligt. På så sätt kan jag gradvis gå från live-vyn till orsaken utan att fastna i irrelevanta Detaljer ...att förlora.

Samplingsalternativ och filter i praktiken

Jag passar. Provtagning-strategi för att hantera frågan, istället för att mäta allt generellt. Vid sporadiska toppar ökar jag samplingsfrekvensen och förkortar visningsintervallen för att fånga upp flyktiga toppar. För processfokus sätter jag -p på den relevanta PID:en, för CPU-fokus -C på de aktiva kärnorna. Med -e styr jag händelsen, till exempel cpu-cycles för bred profilering eller cache-misses om jag misstänker problem med minneshanteringen. Jag använder callgraphs (-g) så snart jag grovt har lokaliserat en hotspot och Orsak som jag vill hitta i stacken.

Tabellen nedan visar praktiska tangentkombinationer som jag ofta använder i vardagen, samt typiska användningsområden för varje alternativ:

Alternativ	Effekt	Användning
-p PID	Begränsar mätningen till en process	Appspecifika Hotspots begränsa
-C Lista över processorer	Fokus på utvalda kärnområden	Kontrollera NUMA/IRQ-fördelningen
-e Evenemang	Välj hårdvaru- eller programvaruhändelse	cykler, instruktioner, cache-missar
-g	Aktivera Callgraph-sampling	Dyra vägar i Stack Känna igen
–kärna/–användare	Filtrerar på kärn- eller användarnivå	Separera källan till CPU-tiden
–sortering	Sorterat efter symbol, DSO, dso:symbol	Läsbarheten hos Rankning öka

Jag testar alltid konfigurationerna kort innan jag påbörjar längre mätningar, så att Visa förblir stabilt och att inga biverkningar uppstår. Särskilt vid hög samplingsfrekvens är jag uppmärksam på overhead för att inte belasta systemet i onödan. När det gäller container-värdar kontrollerar jag dessutom om gränser för namnutrymmen och cgroups begränsar överblicken. För att få reproducerbara prestandatester dokumenterar jag alla inställningar, inklusive kärn- och drivrutinsversioner. Denna noggrannhet sparar mig mycket tid senare Tid vid tolkningen av förändringar.

Tolkning av delsystem: Nätverk, lagring, schemaläggare

Om nätverksvägarna står högst upp kontrollerar jag först IRQ-affiniteter, RSS/Receive-Side-Scaling och avlastningar som GRO/TSO, eftersom dessa inställningsmöjligheter påverkar Genomströmning-Ändra latensbalansen. Vid onormala minnesfunktioner tittar jag på allokeringsmönster, Huge Pages, slab-statistik och frekvensen av sidfel. Schemaläggarens belastning kopplar jag ofta till ett för stort antal trådar, bristande CPU-affinitet eller orättvis prioritering. För specifika kärnhändelser sätter jag dessutom in spårpunkter eller använder bpftrace i webbhotellet, för att bekräfta hypoteser. På så sätt kopplar jag samman observationerna i realtid från perf top med mätpunkter på djupare nivåer och kommer snabbare fram till själva Orsak.

Villkor och symbolernas synlighet

Så att perf top När jag löser alla relevanta kernelsymboler är jag noga med två saker: rätt behörigheter och tillgänglig symbolinformation. På produktionssystem är kernel.perf_event_paranoid ofta inställt på ett högt värde. För djupgående inblick i kärnan sänker jag tillfälligt detta värde eller arbetar som root med nödvändiga behörigheter (CAP_PERFMON/CAP_SYS_ADMIN). Om kärnans adresser är dolda (kptr_restrict), ser jag oftast ändå namnen, men inga råadresser – det räcker för mig för att prioritera. För användarutrymmet installerar jag tillhörande debuginfo-paket, så att perf top visar funktionsnamn istället för offset. Det minskar gissandet och påskyndar arbetet med att hitta orsaken.

Procenttal och fallgropar vid urvalsförfaranden

Jag tolkar procenttalen i listan som relativa andelar av de uppmätta proverna, inte som exakt CPU-belastning över tid. Om jag väljer flera händelser kan Multiplexering tillämpa: Perf fördelar kontringarna över tiden och normaliserad visningen. För att få en tydlig bild mäter jag först övergripande med CPU-cykler eller instruktioner och lägger till specialhändelser senare. Kortvariga toppar fångar jag upp med högre frekvens (-F) och kortare intervall; för system i viloläge räcker standardfrekvensen. Jag beaktar dessutom att Inaktiv-Faser och frekvensförändringar (Turbo, Governor) kan påverka uppfattningen. För jämförande mätningar standardiserar jag därför klock- och energiinställningarna.

En djupgående analys av callgraphs

När jag har identifierat en hotspot förbättrar jag analysen med hjälp av callgraphs. Med -g och med en lämplig unwinding-metod får jag fram sökvägen till den kostsamma delen. Frame-Pointer eller DWARF-Unwinding ger mig stabila stackar; där det är möjligt använder jag hårdvarubaserade återhoppbuffertar (LBR) för mycket exakta kedjor. Jag ökar mmap-buffertarna endast så mycket som nödvändigt för att hålla overheaden låg. Om stacken visar många hjälpfunktioner är jag noga med att inklusive mot. exklusivt Kostnader: Det avgörande är om funktionen i sig är kostsam eller om den endast dominerar som genomströmningsväg. Denna distinktion sparar mig ofta timmar i orsaksutredningen.

Arbeta i containrar och virtuella maskiner

I container-miljöer kontrollerar jag om min vy av cgroups och att namnutrymmena är korrekta. Jag fokuserar mätningarna på de relevanta PID:erna och CPU:erna, så att ”bullriga grannar” inte förvränger bilden. För virtuella maskiner kontrollerar jag om den virtuella PMU:n är aktiverad; annars saknar jag exakta hårdvaruhändelser och ser främst mjukvarusignaler. KVM-värdar känner jag ofta igen på symboler runt kvm_vcpu eller . vmx/svm. I sådana situationer skiljer jag tydligt mellan värd- och gästanalyser för att inte blanda ihop orsak och verkan.

Tydliga mönster och snabba hypoteser

I vardagen har vissa mönster visat sig fungera bra, och dem kontrollerar jag omedelbart:

• Lock-konkurrens: Dykning queued_spin_lock_slowpath eller . mutex_spin_on_owner Om det uppstår problem på den övre nivån beror det på att datastrukturerna är för grovt uppdelade eller att arbetsköerna är för trånga. Jag minskar konkurrensen genom sharding, finare låsgranularitet eller ändrade batchstorlekar.
• Scheduler-utskrift: Blir allt vanligare schedule(), pick_next_task_fair eller wakeup-vägar, justerar jag antalet trådar, affiniteter och prioriteringar. Ofta räcker det med att dämpa “pratsamma” trådar eller att tydligt definiera CPU-inställningarna.
• Nätverks-Softirqs: Toppar vid net_rx_action, napi_poll Eller så kan checksum-offloads tyda på paketstormar eller en suboptimal fördelning av RSS och IRQ. Jag tilldelar IRQ:er till lämpliga kärnor och justerar GRO/TSO för den önskade genomströmnings- och latensprofilen.
• Lagringsvägar: Mycket tid i do_page_fault, copy_user_* Eller med hjälp av Slab-funktioner kan jag kontrollera allokeringsmönster, THP/Huge Pages och NUMA-lokalitet. Felaktig placering kostar här obemärkt väldigt många cykler.
• RCU och timers: Dominera rcu_core eller timer-callbacks, så ser jag över polling- och batch-strategierna för mina tjänster för att få systemet att fungera smidigare.

Fördjupa kunskaperna om mätdisciplin och reproducerbarhet

För att få tydligt jämförbara testkörningar håller jag omgivningsfaktorerna konstanta: CPU-regulator, turbolägen, bakgrundsjobb och till och med rumstemperaturen vid tätt packade noder. Jag kopplar testbelastningarna till definierade kärnor och isolerar vid behov överbelastade CPU:er, så att schemaläggarens beslut förblir stabila. Jag dokumenterar ändringar tillsammans med versioner av kärnan, drivrutinerna och firmware. Vid mer riskfyllda justeringar planerar jag in återställningspunkter och mäter om omedelbart efter ingreppet. På så sätt får jag en tillförlitlig Före/Efter-En historia som jag fortfarande kan förstå, även flera månader senare.

Praktiska tips: Kommandon som jag ofta använder

Beroende på frågan använder jag kortfattade recept:

• Omfattande scoping under belastning: perf top -e cpu-cycles –kernel –user
  En snabb översikt över om det är kärnan eller användarutrymmet som bestämmer.
• Processfokus med Callgraph: perf top -p PID -g –kernel –user
  Visa mig realtidsspår för den aktuella applikationen, utan systembuller.
• Fokus på CPU:n: perf top -C 2-5 -e cpu-cycles -g
  Hjälper vid NUMA- eller IRQ-hotspots när endast ett fåtal kärnor “glöder”.
• Misstankar om lagring: perf top -e cache-misses -e cycles -g –kernel
  Visar lagringsvägar i förhållande till cykler.
• Fästa tillfälliga spikar: perf top -F 999 -I 1000 -e cykler
  Högre frekvens och kortare visningsintervall fångar upp korta toppar.

Tolkningshjälpmedel för specifika delsystem

På Nätverk Förutom NAPI och RX/TX-vägar övervakar jag även TLS/krypto-andelar, som kan dominera vid hög handskakningsvolym. Jag kontrollerar om Zero-Copy respektive coalescing fungerar som avsett och om stora segment (TSO/GSO) överskrider mina latensbudgetar. I Minne-området tittar jag på THP: Hjälper det min belastning, eller orsakar split-/merge-händelser störningar? Vid Förvaring tolkar jag blk_mq-symboler och io_uring-vägar som indikation på ködjup och sammanfogningsstrategier. Vid schemaläggare Jag kopplar samman Wakeup-laviner med Lock- eller IO-kedjor och jämnar ut vägarna genom backpressure istället för “fler trådar”.

Gränserna för perf top och när jag byter taktik

Därför att perf top Eftersom det är baserat på stickprov ser jag snarare genomsnittsbilder än enskilda händelser. För deterministiska flöden byter jag till tracepoints, ftrace eller eBPF för att påvisa exakta orsakssamband. Om jag behöver exakt kvantifiering (t.ex. instruktioner per begäran) kombinerar jag med perf stat eller offline-analyser från perf record/report. Om jag stöter på otydliga stackar (saknade symboler, felaktig avveckling) åtgärdar jag först synligheten – allt annat vore som att famla i blindo.

Kortfattat sammanfattat

Med perf top Jag ser i realtid var i kärnan CPU:n tar tid och vilka symboler jag bör undersöka först. Utifrån procentvärdena, återkommande mönster och uppdelningen mellan kärn- och användarutrymmet drar jag slutsatser om vilka specifika nästa steg jag bör ta. Sedan sammanfattar jag resultaten med perf record/report, verifierar förändringar under belastning och dokumenterar min mätkedja. I hostingmiljöer lönar sig detta tillvägagångssätt särskilt väl, eftersom många tjänster och containrar drar nytta av varandra så snart kärnvägssekvenserna körs mer effektivt. Den som tillägnar sig denna process sparar flera dagars diagnostikarbete och minskar Fördröjningar och uppnår märkbart stabilare svarstider under verklig belastning.