{"id":20626,"date":"2026-08-14T08:35:54","date_gmt":"2026-08-14T06:35:54","guid":{"rendered":"https:\/\/webhosting.de\/perf-top-linux-hotspots-kernel-tools\/"},"modified":"2026-08-14T08:35:54","modified_gmt":"2026-08-14T06:35:54","slug":"perf-top-linux-hotspots-kernelvaerktojer","status":"publish","type":"post","link":"https:\/\/webhosting.de\/da\/perf-top-linux-hotspots-kernel-tools\/","title":{"rendered":"perf top Linux: Identificering af CPU-hotspots i kernen"},"content":{"rendered":"<p>Med <strong>perf top<\/strong> Under Linux kan jeg p\u00e5 f\u00e5 sekunder finde ud af, hvilke kernefunktioner der i \u00f8jeblikket optager mest CPU-tid, og hvor der opst\u00e5r flaskehalse. I denne vejledning viser jeg ved hj\u00e6lp af klare trin, hvordan jeg identificerer live-hotspots, fortolker resultaterne korrekt og ud fra dem udleder hurtige optimeringer for scheduler, netv\u00e6rk og hukommelse.<\/p>\n\n<h2>Centrale punkter<\/h2>\n\n<p>Jeg synes, at live-visningen af <strong>perf<\/strong> Det er perfekt som udgangspunkt, fordi det straks viser de st\u00f8rste tidsslugere. Procentdelene ved hvert symbol viser mig, om flaskehalsen ligger i <strong>Kernen<\/strong> eller ligger i brugerrummet. Ud fra tilbagevendende m\u00f8nstre kan jeg se, om det er l\u00e5se, IRQ\u2019er, netv\u00e6rk eller hukommelse, der dominerer. Derefter indsn\u00e6vrer jeg problemomr\u00e5det med mere avancerede v\u00e6rkt\u00f8jer og tester \u00e6ndringerne direkte under belastning. P\u00e5 den m\u00e5de forbedrer jeg trin for trin <strong>CPU<\/strong>-Udnyttelse og reducerer latenstiderne p\u00e5 lang sigt.<\/p>\n<ul>\n  <li><strong>Live-hotspots<\/strong> identificere og prioritere<\/li>\n  <li><strong>Procentandele<\/strong> fortolke korrekt for hver funktion<\/li>\n  <li><strong>Hovedfokus<\/strong> indstille: IRQ'er, l\u00e5se, hukommelse<\/li>\n  <li><strong>Arbejdsgang<\/strong>: top \u2192 optegnelse \u2192 rapport<\/li>\n  <li><strong>Optimeringer<\/strong> m\u00e5lrettet verificere<\/li>\n<\/ul>\n\n\n<figure class=\"wp-block-image size-full is-resized\">\n  <img fetchpriority=\"high\" decoding=\"async\" src=\"https:\/\/webhosting.de\/wp-content\/uploads\/2026\/08\/cpu-hotspots-linux-kernel-4872.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Hvad er \u00bbperf top\u00ab, og hvad bruger jeg det til?<\/h2>\n\n<p>Jeg bruger <strong>perf top<\/strong>, s\u00e5 man under k\u00f8rende belastning straks kan se, hvilke symboler der bruger den st\u00f8rste andel af CPU-tiden. V\u00e6rkt\u00f8jet har adgang til hardware-performance-t\u00e6llere og viser mig med korte intervaller en opdateret rangliste over de mest ressourcekr\u00e6vende funktioner. If\u00f8lge Linux-Magazin mestrer perf b\u00e5de profilering og sporing, hvilket <strong>Live-visning<\/strong> sammenh\u00e6ngende med mere dybdeg\u00e5ende analyser. I den s\u00e6dvanlige arbejdsgang supplerer jeg \u00f8jebliksbilledet med \u00bbperf record\u00ab og \u00bbperf report\u00ab for at unders\u00f8ge callgraphs og pr\u00e6cise stier. P\u00e5 den m\u00e5de besvarer jeg det centrale sp\u00f8rgsm\u00e5l: Hvor bruger <strong>CPU<\/strong> netop nu \u2013 i netv\u00e6rksstakken, i lagringsundersystemet, i scheduleren eller i en driver?<\/p>\n\n<h2>Installer og start perf top<\/h2>\n\n<p>Efter installationen via distributionspakken k\u00f8rer jeg <strong>perf<\/strong> top k\u00f8rer som regel med udvidede rettigheder, s\u00e5 kernelsymboler og systemh\u00e6ndelser bliver synlige. En simpel opstart med \u201eperf top\u201c er nok til at oprette en f\u00f8rste live-visning og f\u00e5 overblik over de dominerende funktioner. Hvis jeg har brug for at fokusere p\u00e5 enkelte processer, h\u00e6nger jeg <strong>PID<\/strong> 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\u00e6ngigt af hvilket sp\u00f8rgsm\u00e5l jeg \u00f8nsker at afklare. For at opn\u00e5 reproducerbare resultater starter jeg m\u00e5lingen under en reel belastning, s\u00e5 <strong>Hotspots<\/strong> skal fremst\u00e5 tydeligt og ikke forsvinde i tomgangsst\u00f8jen.<\/p>\n\n\n<figure class=\"wp-block-image size-full is-resized\">\n  <img decoding=\"async\" src=\"https:\/\/webhosting.de\/wp-content\/uploads\/2026\/08\/cpuhotspotslinux3746.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>S\u00e5dan l\u00e6ser jeg udgaven korrekt<\/h2>\n\n<p>P\u00e5 listen vurderer jeg f\u00f8rst <strong>Procenttal<\/strong> pr. symbol, fordi de afspejler de relative tidsandele. H\u00f8je andele ved systemfunktioner tyder p\u00e5 en flaskehals i kernen, mens dominerende symbols i brugerrummet snarere peger p\u00e5 app-logik. Hvis jeg ser mange scheduler-rutiner, t\u00e6nker jeg p\u00e5 for mange aktive tr\u00e5de, ugunstige affiniteter eller uhensigtsm\u00e6ssige prioriteter. Hvis hukommelsesfunktioner dukker op \u00f8verst, tjekker jeg allokeringsm\u00f8nstre, sidefejl, NUMA-lokalitet og cacher. Ved netv\u00e6rksstier ser jeg p\u00e5 IRQ-fordeling, Gro\/TSO-indstillinger og driveradf\u00e6rd, fordi s\u00e5danne detaljer er <strong>Forsinkelse<\/strong> har stor indflydelse p\u00e5.<\/p>\n\n<h2>Typiske \u00e5rsager til kernel-hotspots<\/h2>\n\n<p>Mange hotspots opst\u00e5r, fordi mange sm\u00e5 udgifter tilsammen udg\u00f8r en stor <strong>Belastning<\/strong> akkumuleres. Ofte \u00f8ger hyppige kontekstskift, lock-konkurrence og ulige fordeling af IRQ\u2019er CPU-tiden. Ligeledes binder fragmenterede hukommelsesstrukturer, ineffektiv brug af slab\u2019er eller konstant paging un\u00f8dvendige cyklusser. Hvis jeg bem\u00e6rker en bestemt driver, s\u00e6tter jeg den i sammenh\u00e6ng med arbejdsbelastning, hardware og version for at indsn\u00e6vre bivirkningerne. P\u00e5 multicore-systemer tjekker jeg desuden for false sharing, da delte cache-linjer if\u00f8lge kernel-dokumentationen hurtigt kan f\u00f8re til dyr <strong>Overhead<\/strong> kan give anledning til bekymring.<\/p>\n\n<h2>Eksempel p\u00e5 en analyse af et hotspot<\/h2>\n\n<p>Hvis jeg ser, at der over en l\u00e6ngere periode er en meget h\u00f8j andel af netv\u00e6rksrelaterede funktioner, skelner jeg f\u00f8rst mellem forskellige belastningstyper: sm\u00e5 kontra store pakker, TLS kontra klartekst, mange forbindelser kontra f\u00e5 langvarige sessioner, for at <strong>\u00c5rsag<\/strong> at indsn\u00e6vre problemet. Derefter g\u00e5r jeg mere i dybden med \u00bbperf record\u00ab og \u00bbperf report\u00ab, aktiverer callgraphs (-g) og sammenligner stierne over flere k\u00f8rsler. Hvis det i stedet er hukommelsesstyringen, der dukker op, tjekker jeg allokatoren, Huge Pages, THP-indstillingerne og NUMA-affinitet, fordi der hurtigt opst\u00e5r un\u00f8dvendige veje her. Scheduler-hotspots tolker jeg ofte som et tegn p\u00e5 for mange k\u00f8rbare tr\u00e5de eller en uhensigtsm\u00e6ssig CPU-binding. Jeg \u00e6ndrer altid kun \u00e9n <strong>Parametre<\/strong> pr. genneml\u00f8b, s\u00e5 jeg kan tilordne effekten korrekt.<\/p>\n\n\n<figure class=\"wp-block-image size-full is-resized\">\n  <img decoding=\"async\" src=\"https:\/\/webhosting.de\/wp-content\/uploads\/2026\/08\/linux-cpu-hotspots-perf-top-7351.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Perf Top i hostingmilj\u00f8er<\/h2>\n\n<p>I hosting-scenarier ser jeg ofte, hvordan sm\u00e5 kerneomkostninger p\u00e5virker <strong>Forsinkelse<\/strong> mange tjenester. Parallelt k\u00f8rende containere, VM\u2019er og databaseinstanser flytter profilen markant i retning af netv\u00e6rk, lagring og scheduler. Med \u00bbperf top\u00ab kan jeg se, om flaskehalse snarere ligger i IRQ-h\u00e5ndtering, SoftIRQ-behandling eller i l\u00e5seveje. Derefter inddrager jeg kerneversion, NUMA-layout, IRQ-affiniteter og k\u00f8dybder i analysen, da disse faktorer p\u00e5virker hinanden. Hvis du \u00f8nsker at g\u00e5 mere i dybden, kan du finde yderligere information i denne vejledning til <a href=\"https:\/\/webhosting.de\/da\/linux-perf-vaerktoj-analyse-af-cpu-flaskehalse-optimering-serverbelastning-profilering\/\">Analyse af flaskehalse i CPU\u2019en<\/a> andre praktiske tilgange, som jeg regelm\u00e6ssigt anvender i praksis.<\/p>\n\n<h2>Praktisk vejledning til analyse<\/h2>\n\n<p>Jeg starter med et reproducerbart belastningsscenarie, s\u00e5 m\u00e5lingerne forbliver sammenlignelige, og <strong>Hotspots<\/strong> dukker stabilt op. Derefter starter jeg \u00bbperf top\u00ab og noterer de dominerende symboler over flere opdateringer. Dette \u00f8jebliksbillede sammenfatter jeg med \u00bbperf record\/report\u00ab til et klart overblik over callgraphs, s\u00e5 jeg kan identificere stien til det ressourcekr\u00e6vende sted. Derefter \u00e6ndrer jeg m\u00e5lrettet kun \u00e9n ting, for eksempel en IRQ-affinitet eller en k\u00f8dybde, og m\u00e5ler igen. F\u00f8rst n\u00e5r effekten er tydelig, g\u00e5r jeg videre til det n\u00e6ste <strong>Trin<\/strong> gennemg\u00e5 og dokumentere resultaterne med henblik p\u00e5 fremtidige vedligeholdelsesvinduer.<\/p>\n\n\n<figure class=\"wp-block-image size-full is-resized\">\n  <img loading=\"lazy\" decoding=\"async\" src=\"https:\/\/webhosting.de\/wp-content\/uploads\/2026\/08\/TechOffice_Nacht_CPUs_3421.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Hvorn\u00e5r andre v\u00e6rkt\u00f8jer er en god id\u00e9<\/h2>\n\n<p>N\u00e5r jeg har brug for et historisk overblik, mere detaljerede callgraphs eller specifikke h\u00e6ndelsesk\u00e6der, benytter jeg mig af <strong>perf<\/strong> record\/report, ftrace eller eBPF. Tracepoints hj\u00e6lper mig med at belyse bestemte stier, mens jeg med BPF-programmer f\u00e5r fleksible m\u00e5linger. N\u00e5r jeg vil se n\u00e6rmere p\u00e5 kernelstier, leverer <a href=\"https:\/\/webhosting.de\/da\/ebpf-linux-analysevaerktojer-serverovervagning-indsigt\/\">eBPF-analysev\u00e6rkt\u00f8jer<\/a> v\u00e6rdifulde signaler direkte p\u00e5 selve stedet. Til cache- og delingsproblemer er perf-c2c og pahole nyttige, s\u00e5 snart hotspottet er tydeligt identificeret. P\u00e5 den m\u00e5de kan jeg gradvist g\u00e5 fra live-visningen til \u00e5rsagen uden at fordybe mig i irrelevante <strong>Detaljer<\/strong> at tabe.<\/p>\n\n<h2>Sampling-indstillinger og filtre i praksis<\/h2>\n\n<p>Jeg passer <strong>Pr\u00f8veudtagning<\/strong>-strategi til det konkrete problem i stedet for at m\u00e5le alt generelt. Ved sporadiske spidsbelastninger \u00f8ger jeg samplingfrekvensen og forkorter visningsintervallerne for at fange flygtige spidsbelastninger. For at fokusere p\u00e5 processer s\u00e6tter jeg -p til den relevante PID, og for at fokusere p\u00e5 CPU'en s\u00e6tter 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\u00e6rd. Jeg bruger callgraphs (-g), s\u00e5 snart jeg groft har lokaliseret et hotspot, og <strong>\u00c5rsag<\/strong> som jeg vil finde i stakken.<\/p>\n\n<p>Den f\u00f8lgende tabel viser praktiske tastkombinationer, som jeg ofte bruger i hverdagen, samt typiske anvendelsesform\u00e5l for hver enkelt mulighed:<\/p>\n\n<table>\n  <thead>\n    <tr>\n      <th>Mulighed<\/th>\n      <th>Effekt<\/th>\n      <th>Brug<\/th>\n    <\/tr>\n  <\/thead>\n  <tbody>\n    <tr>\n      <td><strong>-p<\/strong> PID<\/td>\n      <td>Begr\u00e6nser m\u00e5lingen til en proces<\/td>\n      <td>App-specifikke <strong>Hotspots<\/strong> indsn\u00e6vre<\/td>\n    <\/tr>\n    <tr>\n      <td><strong>-C<\/strong> CPU-liste<\/td>\n      <td>Fokus p\u00e5 udvalgte kerneomr\u00e5der<\/td>\n      <td>Kontroller NUMA\/IRQ-fordelingen<\/td>\n    <\/tr>\n    <tr>\n      <td><strong>-e<\/strong> Begivenhed<\/td>\n      <td>V\u00e6lg hardware- eller softwareh\u00e6ndelse<\/td>\n      <td>cyklusser, instruktioner, cache-fejl<\/td>\n    <\/tr>\n    <tr>\n      <td><strong>-g<\/strong><\/td>\n      <td>Aktiverer Callgraph-sampling<\/td>\n      <td>Dyre stier i <strong>Stak<\/strong> Genkende<\/td>\n    <\/tr>\n    <tr>\n      <td><strong>\u2013kernel\/\u2013user<\/strong><\/td>\n      <td>Filtrerer efter kernel eller brugerrum<\/td>\n      <td>Adskille kilden til CPU-tiden<\/td>\n    <\/tr>\n    <tr>\n      <td><strong>\u2013sort<\/strong><\/td>\n      <td>Sorteret efter symbol, DSO, dso:symbol<\/td>\n      <td>L\u00e6sbarheden af <strong>Rangliste<\/strong> \u00f8ge<\/td>\n    <\/tr>\n  <\/tbody>\n<\/table>\n\n<p>Jeg tester altid konfigurationerne kort, f\u00f8r jeg starter l\u00e6ngerevarende m\u00e5linger, s\u00e5 <strong>Vis<\/strong> forbliver stabil, og der ikke opst\u00e5r bivirkninger. Is\u00e6r ved h\u00f8je samplingsfrekvenser er jeg opm\u00e6rksom p\u00e5 overhead for ikke at belaste systemet un\u00f8digt. Ved container-v\u00e6rter tjekker jeg desuden, om namespace- og cgroup-begr\u00e6nsninger indskr\u00e6nker overblikket. For at sikre reproducerbare benchmarks dokumenterer jeg alle indstillinger, herunder kerne- og driverversioner. Denne disciplin sparer mig for meget arbejde senere <strong>Tid<\/strong> ved klassificeringen af \u00e6ndringer.<\/p>\n\n\n<figure class=\"wp-block-image size-full is-resized\">\n  <img loading=\"lazy\" decoding=\"async\" src=\"https:\/\/webhosting.de\/wp-content\/uploads\/2026\/08\/cpuhotspots_kernel1234.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Fortolkning af delsystemer: Netv\u00e6rk, lager, planl\u00e6gger<\/h2>\n\n<p>N\u00e5r netv\u00e6rksstierne er angivet \u00f8verst, tjekker jeg f\u00f8rst IRQ-affiniteter, RSS\/Receive-Side-Scaling og offloads som GRO\/TSO, fordi disse indstillingsmuligheder har indflydelse p\u00e5 <strong>Gennemstr\u00f8mning<\/strong>-\u00c6ndre latenstidsbalancen. Ved p\u00e5faldende hukommelsesfunktioner ser jeg p\u00e5 allokeringsm\u00f8nstre, Huge Pages, slab-statistikker og page-fault-rater. Scheduler-belastning forbinder jeg ofte med et for stort antal tr\u00e5de, manglende CPU-affinitet eller uretf\u00e6rdig prioritering. For m\u00e5lrettede kernel-begivenheder s\u00e6tter jeg desuden tracepoints eller bruger <a href=\"https:\/\/webhosting.de\/da\/bpftrace-hurtigere-pavisning-af-problemer-pa-hosting-serveren-diagnose\/\">bpftrace i hosting<\/a>, for at bekr\u00e6fte hypoteser. P\u00e5 den m\u00e5de sammenholder jeg live-observationerne fra perf top med m\u00e5linger fra dybere punkter og n\u00e5r hurtigere frem til selve <strong>\u00c5rsag<\/strong>.<\/p>\n\n\n<figure class=\"wp-block-image size-full is-resized\">\n  <img loading=\"lazy\" decoding=\"async\" src=\"https:\/\/webhosting.de\/wp-content\/uploads\/2026\/08\/linux-kernel-hotspots-7894.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Foruds\u00e6tninger og symbolernes synlighed<\/h2>\n\n<p>S\u00e5 det <strong>perf top<\/strong> N\u00e5r jeg l\u00f8ser alle relevante kernelsymboler, er jeg opm\u00e6rksom p\u00e5 to ting: de rette rettigheder og tilg\u00e6ngelige symboloplysninger. P\u00e5 produktive systemer er <em>kernel.perf_event_paranoid<\/em> ofte sat h\u00f8jt. For at f\u00e5 indblik dybt ned i kernen s\u00e6nker jeg midlertidigt denne v\u00e6rdi eller arbejder som root med de n\u00f8dvendige rettigheder (CAP_PERFMON\/CAP_SYS_ADMIN). Hvis kerneadresserne er skjult (<em>kptr_restrict<\/em>), ser jeg som regel alligevel navne, men ingen r\u00e5adresser \u2013 det er nok for mig til at prioritere. Til brugerrummet installerer jeg de tilh\u00f8rende debuginfo-pakker, s\u00e5 perf top viser funktionsnavne i stedet for offset-v\u00e6rdier. Det mindsker g\u00e6tteriet og g\u00f8r det hurtigere at finde \u00e5rsagen.<\/p>\n\n<h2>Procenttal og faldgruber ved stikpr\u00f8veudtagning<\/h2>\n\n<p>Jeg fortolker procenttallene i listen som <strong>relative andele<\/strong> de m\u00e5lte pr\u00f8ver, ikke som den n\u00f8jagtige CPU-udnyttelse over tid. Hvis jeg v\u00e6lger flere begivenheder, kan <strong>Multiplexing<\/strong> gribe ind: Perf fordeler kontraangrebene over tid og <em>normaliseret<\/em> visningen. For at f\u00e5 et klart billede m\u00e5ler jeg f\u00f8rst bredt med CPU-cykler eller instruktioner og tilf\u00f8jer f\u00f8rst senere specielle begivenheder. Kortvarige spidsbelastninger fanger jeg med en h\u00f8jere frekvens (-F) og kortere intervaller; for systemer i rolig drift er standardfrekvensen tilstr\u00e6kkelig. Jeg l\u00e6gger desuden m\u00e6rke til, at <strong>Inaktiv<\/strong>-faser og frekvens\u00e6ndringer (Turbo, Governor) kan forvride opfattelsen. Til sammenligningsm\u00e5linger standardiserer jeg derfor takt- og energiindstillingerne.<\/p>\n\n<h2>En dybdeg\u00e5ende gennemgang af callgraphs<\/h2>\n\n<p>N\u00e5r jeg har identificeret et hotspot, \u00f8ger jeg indsigtsv\u00e6rdien ved hj\u00e6lp af callgraphs. Med <strong>-g<\/strong> og med en passende unwinding-metode f\u00e5r jeg stien til det ressourcekr\u00e6vende sted. Frame-pointer eller DWARF-unwinding giver mig stabile stakke; hvor det er muligt, bruger jeg hardwarebaserede returbuffere (LBR) for at opn\u00e5 meget pr\u00e6cise k\u00e6der. Jeg \u00f8ger mmap-bufferne kun s\u00e5 meget som n\u00f8dvendigt for at holde overheadet p\u00e5 et lavt niveau. Hvis stakken viser mange hj\u00e6lpefunktioner, er jeg opm\u00e6rksom p\u00e5 <strong>inklusive<\/strong> vs. <strong>eksklusivt<\/strong> Omkostninger: Det afg\u00f8rende 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\u00f8gningen.<\/p>\n\n<h2>Arbejde i containere og virtuelle maskiner<\/h2>\n\n<p>I container-milj\u00f8er tjekker jeg, om min visning af <strong>cgroups<\/strong> og at navneomr\u00e5derne er korrekte. Jeg fokuserer m\u00e5lingerne p\u00e5 de relevante PID\u2019er og CPU\u2019er, s\u00e5 st\u00f8jende naboer ikke forvr\u00e6nger billedet. For VM\u2019er kontrollerer jeg, om den virtuelle PMU er aktiveret; ellers mangler jeg pr\u00e6cise hardwarebegivenheder og ser prim\u00e6rt softwaresignaler. KVM-v\u00e6rter genkender jeg ofte p\u00e5 symboler omkring <em>kvm_vcpu<\/em> eller <em>vmx<\/em>\/<em>svm<\/em>. I s\u00e5danne situationer adskiller jeg n\u00f8je analyser af v\u00e6rten og g\u00e6sten, s\u00e5 jeg ikke forveksler \u00e5rsag og virkning.<\/p>\n\n<h2>Genkendelige m\u00f8nstre og hurtige hypoteser<\/h2>\n\n<p>I hverdagen har visse m\u00f8nstre vist sig at fungere, og dem tjekker jeg straks:<\/p>\n<ul>\n  <li><strong>Konkurrence om Lock<\/strong>: Dykning <em>queued_spin_lock_slowpath<\/em> eller <em>mutex_spin_on_owner<\/em> Ovenst\u00e5ende skyldes, at datastrukturerne er for groft opdelte, eller at arbejdsk\u00f8erne er for smalle. Jeg reducerer konkurrencen ved hj\u00e6lp af sharding, finere l\u00e5segranularitet eller \u00e6ndrede batchst\u00f8rrelser.<\/li>\n  <li><strong>Udskrivning fra planl\u00e6gningsprogrammet<\/strong>: Der er en stigende tendens til <em>schedule()<\/em>, <em>pick_next_task_fair<\/em> eller wakeup-stier, justerer jeg antallet af tr\u00e5de, affiniteter og prioriteter. Ofte er det nok at d\u00e6mpe \u201csnakkesalige\u201d tr\u00e5de eller definere CPU-indstillingerne pr\u00e6cist.<\/li>\n  <li><strong>Netv\u00e6rks-Softirqs<\/strong>: H\u00f8jdepunkter ved <em>net_rx_action<\/em>, <em>napi_poll<\/em> Eller checksum-offloads tyder p\u00e5 pakkestorme eller suboptimal fordeling af RSS og IRQ. Jeg tildeler IRQ\u2019er til passende kerner og justerer GRO\/TSO for at opn\u00e5 den \u00f8nskede gennemstr\u00f8mning\/latensprofil.<\/li>\n  <li><strong>Lagringsstier<\/strong>: Masser af tid i <em>do_page_fault<\/em>, <em>copy_user_*<\/em> eller Slab-funktioner giver mig mulighed for at kontrollere allokeringsm\u00f8nstre, THP\/Huge Pages og NUMA-lokalitet. Forkert placering koster her ubem\u00e6rket rigtig mange cyklusser.<\/li>\n  <li><strong>RCU og timere<\/strong>: At dominere <em>rcu_core<\/em> eller timer-callbacks, genovervejer jeg polling- og batch-strategierne for mine tjenester for at f\u00e5 systemet til at k\u00f8re mere stabilt.<\/li>\n<\/ul>\n\n<h2>Uddybe m\u00e5lepr\u00e6cision og reproducerbarhed<\/h2>\n\n<p>For at sikre, at testk\u00f8rslerne kan sammenlignes p\u00e5 et ensartet grundlag, holder jeg milj\u00f8faktorerne konstante: CPU-governor, turbo-tilstande, baggrundsopgaver og endda rumtemperaturen ved t\u00e6tpakkede noder. Jeg tildeler testbelastninger til bestemte kerner og isolerer eventuelt overbelastede CPU\u2019er, s\u00e5 schedulerens beslutninger forbliver stabile. Jeg dokumenterer \u00e6ndringer sammen med versioner af kerne, drivere og firmware. Ved mere risikable justeringer planl\u00e6gger jeg tilbagef\u00f8rselspunkter og foretager en ny m\u00e5ling umiddelbart efter indgrebet. P\u00e5 den m\u00e5de f\u00e5r jeg et p\u00e5lideligt <strong>F\u00f8r\/Efter<\/strong>-En historie, som jeg stadig kan forst\u00e5, selv flere m\u00e5neder senere.<\/p>\n\n<h2>Praktiske tip: Kommandoer, jeg ofte bruger<\/h2>\n\n<p>Afh\u00e6ngigt af sp\u00f8rgsm\u00e5let bruger jeg kortfattede opskrifter:<\/p>\n<ul>\n  <li><strong>Omfattende scoping under belastning<\/strong>: perf top -e cpu-cycles \u2013kernel \u2013user<br\/>Et hurtigt overblik over, om det er kernen eller brugerrummet, der bestemmer.<\/li>\n  <li><strong>Procesfokus med Callgraph<\/strong>: perf top -p PID -g \u2013kernel \u2013user<br\/>Vis mig live-stier til den relevante applikation uden systemst\u00f8j.<\/li>\n  <li><strong>Fokus p\u00e5 CPU'en<\/strong>: perf top -C 2-5 -e cpu-cycles -g<br\/>Hj\u00e6lper ved NUMA- eller IRQ-hotspots, n\u00e5r kun f\u00e5 kerner \u201cgl\u00f8der\u201d.<\/li>\n  <li><strong>Mistanke om lagring<\/strong>: perf top -e cache-misses -e cycles -g \u2013kernel<br\/>Viser hukommelsesstier i forhold til cyklusser.<\/li>\n  <li><strong>Fastg\u00f8re flygtige spidser<\/strong>: perf top -F 999 -I 1000 -e cykler<br\/>H\u00f8jere frekvens og kortere visningsintervaller registrerer korte spidser.<\/li>\n<\/ul>\n\n<h2>Fortolkningsvejledning til konkrete delsystemer<\/h2>\n\n<p>P\u00e5 <strong>Netv\u00e6rk<\/strong> Ud over NAPI og RX\/TX-stier overv\u00e5ger jeg ogs\u00e5 TLS\/krypto-andele, som kan dominere ved h\u00f8j h\u00e5ndtryksaktivitet. Jeg tjekker, om Zero-Copy eller coalescing fungerer hensigtsm\u00e6ssigt, og om store segmenter (TSO\/GSO) overskrider mine latenstidsbudgetter. I <strong>Hukommelse<\/strong>-omr\u00e5det ser jeg p\u00e5 THP: Hj\u00e6lper det min belastning, eller skaber split-\/merge-begivenheder forstyrrende st\u00f8j? Ved <strong>Opbevaring<\/strong> fortolker jeg <em>blk_mq<\/em>-Symboler og io_uring-stier som indikatorer for k\u00f8dybder og sammenfletningsstrategier. Ved <strong>planl\u00e6gningsprogram<\/strong> Jeg forbinder Wakeup-laviner med Lock- eller IO-k\u00e6der og aflaster stierne ved hj\u00e6lp af backpressure i stedet for \u201cflere tr\u00e5de\u201d.<\/p>\n\n<h2>Gr\u00e6nserne for \u00bbperf top\u00ab og hvorn\u00e5r jeg skifter taktik<\/h2>\n\n<p>Fordi <strong>perf top<\/strong> Da det er baseret p\u00e5 stikpr\u00f8ver, ser jeg gennemsnitsbilleder tydeligere end enkeltbegivenheder. Ved deterministiske forl\u00f8bsk\u00e6der skifter jeg til tracepoints, ftrace eller eBPF for at p\u00e5vise pr\u00e6cise \u00e5rsagssammenh\u00e6nge. Hvis jeg har brug for n\u00f8jagtig kvantificering (f.eks. instruktioner pr. anmodning), kombinerer jeg med <strong>perf stat<\/strong> eller offline-analyser fra perf record\/report. Hvis jeg st\u00f8der p\u00e5 uklare stakke (manglende symboler, fejlbeh\u00e6ftet unwinding), s\u00f8rger jeg f\u00f8rst for at g\u00f8re dem synlige \u2013 alt andet ville v\u00e6re som at famle i blinde.<\/p>\n\n<h2>Kort opsummeret<\/h2>\n\n<p>Med <strong>perf top<\/strong> kan jeg i realtid se, hvor CPU\u2019en bruger tid i kernen, og hvilke symboler jeg b\u00f8r unders\u00f8ge f\u00f8rst. Ud fra procenttalene, de tilbagevendende m\u00f8nstre og adskillelsen mellem kerne- og brugerrummet udleder jeg m\u00e5lrettede n\u00e6ste skridt. Derefter sammenfatter jeg resultaterne med perf record\/report, verificerer \u00e6ndringer under belastning og dokumenterer min m\u00e5lek\u00e6de. I hostingmilj\u00f8er betaler denne fremgangsm\u00e5de sig s\u00e6rligt godt, fordi mange tjenester og containere drager fordel af hinanden, s\u00e5 snart kernestierne k\u00f8rer mere effektivt. Den, der tilegner sig denne fremgangsm\u00e5de, sparer dage p\u00e5 fejlfinding og reducerer <strong>Forsinkelser<\/strong> og opn\u00e5r m\u00e6rkbart mere stabile responstider under reel belastning.<\/p>","protected":false},"excerpt":{"rendered":"<p>perf top Linux viser CPU-hotspots i kernen i realtid. Det muligg\u00f8r hurtig CPU-profilering og en pr\u00e6cis analyse af flaskehalse.<\/p>","protected":false},"author":1,"featured_media":20619,"comment_status":"","ping_status":"","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"inline_featured_image":false,"footnotes":""},"categories":[780],"tags":[],"class_list":["post-20626","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-administration-anleitungen"],"acf":[],"_wp_attached_file":null,"_wp_attachment_metadata":null,"litespeed-optimize-size":null,"litespeed-optimize-set":null,"_elementor_source_image_hash":null,"_wp_attachment_image_alt":null,"stockpack_author_name":null,"stockpack_author_url":null,"stockpack_provider":null,"stockpack_image_url":null,"stockpack_license":null,"stockpack_license_url":null,"stockpack_modification":null,"color":null,"original_id":null,"original_url":null,"original_link":null,"unsplash_location":null,"unsplash_sponsor":null,"unsplash_exif":null,"unsplash_attachment_metadata":null,"_elementor_is_screenshot":null,"surfer_file_name":null,"surfer_file_original_url":null,"envato_tk_source_kit":null,"envato_tk_source_index":null,"envato_tk_manifest":null,"envato_tk_folder_name":null,"envato_tk_builder":null,"envato_elements_download_event":null,"_menu_item_type":null,"_menu_item_menu_item_parent":null,"_menu_item_object_id":null,"_menu_item_object":null,"_menu_item_target":null,"_menu_item_classes":null,"_menu_item_xfn":null,"_menu_item_url":null,"_trp_menu_languages":null,"rank_math_primary_category":null,"rank_math_title":null,"inline_featured_image":null,"_yoast_wpseo_primary_category":null,"rank_math_schema_blogposting":null,"rank_math_schema_videoobject":null,"_oembed_049c719bc4a9f89deaead66a7da9fddc":null,"_oembed_time_049c719bc4a9f89deaead66a7da9fddc":null,"_yoast_wpseo_focuskw":null,"_yoast_wpseo_linkdex":null,"_oembed_27e3473bf8bec795fbeb3a9d38489348":null,"_oembed_c3b0f6959478faf92a1f343d8f96b19e":null,"_trp_translated_slug_en_us":null,"_wp_desired_post_slug":null,"_yoast_wpseo_title":null,"tldname":null,"tldpreis":null,"tldrubrik":null,"tldpolicylink":null,"tldsize":null,"tldregistrierungsdauer":null,"tldtransfer":null,"tldwhoisprivacy":null,"tldregistrarchange":null,"tldregistrantchange":null,"tldwhoisupdate":null,"tldnameserverupdate":null,"tlddeletesofort":null,"tlddeleteexpire":null,"tldumlaute":null,"tldrestore":null,"tldsubcategory":null,"tldbildname":null,"tldbildurl":null,"tldclean":null,"tldcategory":null,"tldpolicy":null,"tldbesonderheiten":null,"tld_bedeutung":null,"_oembed_d167040d816d8f94c072940c8009f5f8":null,"_oembed_b0a0fa59ef14f8870da2c63f2027d064":null,"_oembed_4792fa4dfb2a8f09ab950a73b7f313ba":null,"_oembed_33ceb1fe54a8ab775d9410abf699878d":null,"_oembed_fd7014d14d919b45ec004937c0db9335":null,"_oembed_21a029d076783ec3e8042698c351bd7e":null,"_oembed_be5ea8a0c7b18e658f08cc571a909452":null,"_oembed_a9ca7a298b19f9b48ec5914e010294d2":null,"_oembed_f8db6b27d08a2bb1f920e7647808899a":null,"_oembed_168ebde5096e77d8a89326519af9e022":null,"_oembed_cdb76f1b345b42743edfe25481b6f98f":null,"_oembed_87b0613611ae54e86e8864265404b0a1":null,"_oembed_27aa0e5cf3f1bb4bc416a4641a5ac273":null,"_oembed_time_27aa0e5cf3f1bb4bc416a4641a5ac273":null,"_tldname":null,"_tldclean":null,"_tldpreis":null,"_tldcategory":null,"_tldsubcategory":null,"_tldpolicy":null,"_tldpolicylink":null,"_tldsize":null,"_tldregistrierungsdauer":null,"_tldtransfer":null,"_tldwhoisprivacy":null,"_tldregistrarchange":null,"_tldregistrantchange":null,"_tldwhoisupdate":null,"_tldnameserverupdate":null,"_tlddeletesofort":null,"_tlddeleteexpire":null,"_tldumlaute":null,"_tldrestore":null,"_tldbildname":null,"_tldbildurl":null,"_tld_bedeutung":null,"_tldbesonderheiten":null,"_oembed_ad96e4112edb9f8ffa35731d4098bc6b":null,"_oembed_8357e2b8a2575c74ed5978f262a10126":null,"_oembed_3d5fea5103dd0d22ec5d6a33eff7f863":null,"_eael_widget_elements":null,"_oembed_0d8a206f09633e3d62b95a15a4dd0487":null,"_oembed_time_0d8a206f09633e3d62b95a15a4dd0487":null,"_aioseo_description":null,"_eb_attr":null,"_eb_data_table":null,"_oembed_819a879e7da16dd629cfd15a97334c8a":null,"_oembed_time_819a879e7da16dd629cfd15a97334c8a":null,"_acf_changed":null,"_wpcode_auto_insert":null,"_edit_last":null,"_edit_lock":null,"_oembed_e7b913c6c84084ed9702cb4feb012ddd":null,"_oembed_bfde9e10f59a17b85fc8917fa7edf782":null,"_oembed_time_bfde9e10f59a17b85fc8917fa7edf782":null,"_oembed_03514b67990db061d7c4672de26dc514":null,"_oembed_time_03514b67990db061d7c4672de26dc514":null,"rank_math_news_sitemap_robots":null,"rank_math_robots":null,"_eael_post_view_count":"145","_trp_automatically_translated_slug_ru_ru":null,"_trp_automatically_translated_slug_et":null,"_trp_automatically_translated_slug_lv":null,"_trp_automatically_translated_slug_fr_fr":null,"_trp_automatically_translated_slug_en_us":null,"_wp_old_slug":null,"_trp_automatically_translated_slug_da_dk":null,"_trp_automatically_translated_slug_pl_pl":null,"_trp_automatically_translated_slug_es_es":null,"_trp_automatically_translated_slug_hu_hu":null,"_trp_automatically_translated_slug_fi":null,"_trp_automatically_translated_slug_ja":null,"_trp_automatically_translated_slug_lt_lt":null,"_elementor_edit_mode":null,"_elementor_template_type":null,"_elementor_version":null,"_elementor_pro_version":null,"_wp_page_template":null,"_elementor_page_settings":null,"_elementor_data":null,"_elementor_css":null,"_elementor_conditions":null,"_happyaddons_elements_cache":null,"_oembed_75446120c39305f0da0ccd147f6de9cb":null,"_oembed_time_75446120c39305f0da0ccd147f6de9cb":null,"_oembed_3efb2c3e76a18143e7207993a2a6939a":null,"_oembed_time_3efb2c3e76a18143e7207993a2a6939a":null,"_oembed_59808117857ddf57e478a31d79f76e4d":null,"_oembed_time_59808117857ddf57e478a31d79f76e4d":null,"_oembed_965c5b49aa8d22ce37dfb3bde0268600":null,"_oembed_time_965c5b49aa8d22ce37dfb3bde0268600":null,"_oembed_81002f7ee3604f645db4ebcfd1912acf":null,"_oembed_time_81002f7ee3604f645db4ebcfd1912acf":null,"_elementor_screenshot":null,"_oembed_7ea3429961cf98fa85da9747683af827":null,"_oembed_time_7ea3429961cf98fa85da9747683af827":null,"_elementor_controls_usage":null,"_elementor_page_assets":[],"_elementor_screenshot_failed":null,"theplus_transient_widgets":null,"_eael_custom_js":null,"_wp_old_date":null,"_trp_automatically_translated_slug_it_it":null,"_trp_automatically_translated_slug_pt_pt":null,"_trp_automatically_translated_slug_zh_cn":null,"_trp_automatically_translated_slug_nl_nl":null,"_trp_automatically_translated_slug_pt_br":null,"_trp_automatically_translated_slug_sv_se":null,"rank_math_analytic_object_id":null,"rank_math_internal_links_processed":"1","_trp_automatically_translated_slug_ro_ro":null,"_trp_automatically_translated_slug_sk_sk":null,"_trp_automatically_translated_slug_bg_bg":null,"_trp_automatically_translated_slug_sl_si":null,"litespeed_vpi_list":null,"litespeed_vpi_list_mobile":null,"rank_math_seo_score":null,"rank_math_contentai_score":null,"ilj_limitincominglinks":null,"ilj_maxincominglinks":null,"ilj_limitoutgoinglinks":null,"ilj_maxoutgoinglinks":null,"ilj_limitlinksperparagraph":null,"ilj_linksperparagraph":null,"ilj_blacklistdefinition":null,"ilj_linkdefinition":null,"_eb_reusable_block_ids":null,"rank_math_focus_keyword":"perf top","rank_math_og_content_image":null,"_yoast_wpseo_metadesc":null,"_yoast_wpseo_content_score":null,"_yoast_wpseo_focuskeywords":null,"_yoast_wpseo_keywordsynonyms":null,"_yoast_wpseo_estimated-reading-time-minutes":null,"rank_math_description":null,"surfer_last_post_update":null,"surfer_last_post_update_direction":null,"surfer_keywords":null,"surfer_location":null,"surfer_draft_id":null,"surfer_permalink_hash":null,"surfer_scrape_ready":null,"_thumbnail_id":"20619","footnotes":null,"_links":{"self":[{"href":"https:\/\/webhosting.de\/da\/wp-json\/wp\/v2\/posts\/20626","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/webhosting.de\/da\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/webhosting.de\/da\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/webhosting.de\/da\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/webhosting.de\/da\/wp-json\/wp\/v2\/comments?post=20626"}],"version-history":[{"count":0,"href":"https:\/\/webhosting.de\/da\/wp-json\/wp\/v2\/posts\/20626\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/webhosting.de\/da\/wp-json\/wp\/v2\/media\/20619"}],"wp:attachment":[{"href":"https:\/\/webhosting.de\/da\/wp-json\/wp\/v2\/media?parent=20626"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/webhosting.de\/da\/wp-json\/wp\/v2\/categories?post=20626"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/webhosting.de\/da\/wp-json\/wp\/v2\/tags?post=20626"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}