{"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-kernel-tools","status":"publish","type":"post","link":"https:\/\/webhosting.de\/nl\/perf-top-linux-hotspots-kernel-tools\/","title":{"rendered":"perf top Linux: CPU-hotspots in de kernel herkennen"},"content":{"rendered":"<p>Met <strong>perf top<\/strong> 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.<\/p>\n\n<h2>Centrale punten<\/h2>\n\n<p>Ik vind de liveweergave van <strong>perf<\/strong> ideaal als startpunt, omdat het meteen de grootste tijdverslinders zichtbaar maakt. De percentages per symbool laten me zien of de bottleneck zich in de <strong>Kernel<\/strong> of zich in de gebruikersruimte bevindt. Aan de hand van terugkerende patronen bepaal ik of locks, IRQ\u2019s, 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 <strong>CPU<\/strong>-de bezettingsgraad verhogen en de latentie duurzaam verlagen.<\/p>\n<ul>\n  <li><strong>Live-hotspots<\/strong> herkennen en prioriteren<\/li>\n  <li><strong>Procentuele aandelen<\/strong> per functie correct interpreteren<\/li>\n  <li><strong>Kernfocus<\/strong> instellen: IRQ's, vergrendelingen, geheugen<\/li>\n  <li><strong>Werkstroom<\/strong>: top \u2192 record \u2192 rapport<\/li>\n  <li><strong>Optimalisaties<\/strong> gericht verifi\u00ebren<\/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>Wat is Perf Top en waar gebruik ik het voor?<\/h2>\n\n<p>Ik gebruik <strong>perf top<\/strong>, 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 <strong>Live-weergave<\/strong> 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 <strong>CPU<\/strong> precies op dat moment \u2013 in de netwerkstack, in het geheugensubsysteem, in de scheduler of in een stuurprogramma?<\/p>\n\n<h2>perf top installeren en starten<\/h2>\n\n<p>Na de installatie via het distributiepakket voer ik het volgende in: <strong>perf<\/strong> top wordt doorgaans met uitgebreide rechten uitgevoerd, zodat kernel-symbolen en systeemgebeurtenissen zichtbaar worden. Een eenvoudige start met \u201eperf top\u201c 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 <strong>PID<\/strong> 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 <strong>Hotspots<\/strong> duidelijk naar voren komen en niet verloren gaan in de ruis van de stationaire motor.<\/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>Zo lees ik deze uitgave op de juiste manier<\/h2>\n\n<p>In de lijst beoordeel ik eerst de <strong>Procentcijfers<\/strong> 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\u2019s, omdat dergelijke details de <strong>Latency<\/strong> sterk be\u00efnvloeden.<\/p>\n\n<h2>Typische oorzaken van kernel-hotspots<\/h2>\n\n<p>Veel hotspots ontstaan doordat veel kleine kosten samen een grote <strong>Belasting<\/strong> bij elkaar opgeteld. Vaak zorgen overmatige contextwisselingen, lock-concurrentie en ongelijk verdeelde IRQ\u2019s voor een toename van de CPU-tijd. Ook gefragmenteerde geheugenstructuren, ineffici\u00ebnt 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 <strong>Overhead<\/strong> kunnen zorgen.<\/p>\n\n<h2>Een voorbeeld van een analyse van een hotspot<\/h2>\n\n<p>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 <strong>Oorzaak<\/strong> 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 \u00e9\u00e9n <strong>Parameters<\/strong> per doorloop, zodat ik het effect duidelijk kan toewijzen.<\/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>uitmuntend in hostingomgevingen<\/h2>\n\n<p>In hosting-scenario's zie ik vaak hoe kleine kernelkosten de <strong>Latency<\/strong> van verschillende diensten bij elkaar optellen. Parallel draaiende containers, VM\u2019s 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\u2019s 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 <a href=\"https:\/\/webhosting.de\/nl\/linux-perf-tool-cpu-knelpunten-analyseren-optimalisatie-serverbelasting-profilering\/\">CPU-knelpunten analyseren<\/a> andere praktische aanknopingspunten die ik in de praktijk regelmatig gebruik.<\/p>\n\n<h2>Praktische handleiding voor de analyse<\/h2>\n\n<p>Ik begin met een reproduceerbaar belastingsscenario, zodat de metingen vergelijkbaar blijven en <strong>Hotspots<\/strong> 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 \u00e9\u00e9n 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 <strong>Stap<\/strong> en leg de bevindingen vast voor toekomstige onderhoudsperiodes.<\/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>Wanneer andere hulpmiddelen zinvol zijn<\/h2>\n\n<p>Voor een historisch overzicht, gedetailleerdere callgraphs of specifieke gebeurtenisketens maak ik gebruik van <strong>perf<\/strong> record\/report, ftrace of eBPF. Tracepoints helpen me om bepaalde paden gericht te onderzoeken, terwijl ik met BPF-programma\u2019s flexibele statistieken verkrijg. Als ik dieper in kernelpaden wil kijken, bieden <a href=\"https:\/\/webhosting.de\/nl\/ebpf-linux-analysetools-servermonitoring-inzichten\/\">eBPF-analysetools<\/a> waardevolle signalen direct ter plaatse. Voor cache- en sharing-problemen zijn perf-c2c en pahole nuttig, zodra de hotspot duidelijk is ge\u00efdentificeerd. Zo werk ik de analyse stap voor stap uit, van het live-beeld naar de oorzaak, zonder me te verliezen in irrelevante <strong>details<\/strong> te verliezen.<\/p>\n\n<h2>Samplingopties en filters in de praktijk<\/h2>\n\n<p>Ik pas de <strong>Bemonstering<\/strong>-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 \u2018hete\u2019 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 <strong>Oorzaak<\/strong> in de stack wil vinden.<\/p>\n\n<p>De volgende tabel toont praktische toetscombinaties die ik in het dagelijks leven vaak gebruik, evenals typische toepassingen per optie:<\/p>\n\n<table>\n  <thead>\n    <tr>\n      <th>Optie<\/th>\n      <th>Effect<\/th>\n      <th>Gebruik<\/th>\n    <\/tr>\n  <\/thead>\n  <tbody>\n    <tr>\n      <td><strong>-p<\/strong> PID<\/td>\n      <td>Beperkt de meting tot \u00e9\u00e9n proces<\/td>\n      <td>App-specifieke <strong>Hotspots<\/strong> beperken<\/td>\n    <\/tr>\n    <tr>\n      <td><strong>-C<\/strong> Lijst met CPU's<\/td>\n      <td>Focus op geselecteerde kernactiviteiten<\/td>\n      <td>NUMA\/IRQ-verdeling controleren<\/td>\n    <\/tr>\n    <tr>\n      <td><strong>-e<\/strong> Evenement<\/td>\n      <td>Kies een hardware- of softwaregebeurtenis<\/td>\n      <td>cycli, instructies, cache-misses<\/td>\n    <\/tr>\n    <tr>\n      <td><strong>-g<\/strong><\/td>\n      <td>Callgraph-sampling inschakelen<\/td>\n      <td>Dure paden in de <strong>Stapel<\/strong> herkennen<\/td>\n    <\/tr>\n    <tr>\n      <td><strong>\u2013kernel\/\u2013user<\/strong><\/td>\n      <td>Filtert op kernel- of gebruikersruimte<\/td>\n      <td>De bron van de CPU-tijd scheiden<\/td>\n    <\/tr>\n    <tr>\n      <td><strong>\u2013sorteren<\/strong><\/td>\n      <td>Gesorteerd op symbool, DSO, dso:symbool<\/td>\n      <td>Leesbaarheid van de <strong>Ranglijst<\/strong> verhogen<\/td>\n    <\/tr>\n  <\/tbody>\n<\/table>\n\n<p>Ik test configuraties altijd even kort uit voordat ik langere metingen start, zodat de <strong>Toon<\/strong> 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 <strong>Tijd<\/strong> bij het duiden van veranderingen.<\/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>Interpretatie van subsystemen: netwerk, opslag, scheduler<\/h2>\n\n<p>Als er netwerkstraten bovenaan staan, controleer ik eerst de IRQ-affiniteiten, RSS\/Receive-Side-Scaling en offloads zoals GRO\/TSO, omdat deze instellingen de <strong>Doorvoer<\/strong>-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 <a href=\"https:\/\/webhosting.de\/nl\/bpftrace-serverproblemen-bij-hosting-sneller-opsporen-en-diagnosticeren\/\">bpftrace in de hostingomgeving<\/a>, om hypothesen te bevestigen. Zo koppel ik de live-waarneming uit perf top aan dieper gelegen meetpunten en kom ik sneller tot de eigenlijke <strong>Oorzaak<\/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>Voorwaarden en zichtbaarheid van de symbolen<\/h2>\n\n<p>Dus dat <strong>perf top<\/strong> Bij het omzetten van alle relevante kernel-symbolen let ik op twee dingen: de juiste machtigingen en beschikbare symboolinformatie. Op productiesystemen is <em>kernel.perf_event_paranoid<\/em> 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 (<em>kptr_restrict<\/em>), zie ik meestal toch namen, maar geen ruwe adressen \u2013 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.<\/p>\n\n<h2>Procentuele waarden en valkuilen bij steekproeven<\/h2>\n\n<p>Ik interpreteer de percentages in de lijst als <strong>relatieve aandelen<\/strong> van de gemeten monsters, niet als exacte CPU-belasting in de tijd. Als ik meerdere gebeurtenissen selecteer, kan <strong>Multiplexing<\/strong> toepassen: Perf verdeelt de tellers over de tijd en <em>genormaliseerd<\/em> 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 <strong>Inactief<\/strong>-fasen en frequentiewijzigingen (Turbo, Governor) die de waarneming kunnen verstoren. Voor vergelijkende metingen stel ik daarom de klok- en energie-instellingen uniform in.<\/p>\n\n<h2>Callgraphs in detail<\/h2>\n\n<p>Als ik een hotspot heb ge\u00efdentificeerd, vergroot ik de informatiewaarde ervan met behulp van callgraphs. Met <strong>-g<\/strong> 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 <strong>inclusief<\/strong> vs. <strong>exclusief<\/strong> 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.<\/p>\n\n<h2>Werken in containers en VM's<\/h2>\n\n<p>In containeromgevingen controleer ik of mijn weergave van <strong>cgroups<\/strong> en dat de naamruimten correct zijn. Ik richt mijn metingen op de relevante PID\u2019s en CPU\u2019s, zodat luidruchtige buren het beeld niet vertekenen. Voor VM\u2019s 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 <em>kvm_vcpu<\/em> of <em>vmx<\/em>\/<em>svm<\/em>. 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.<\/p>\n\n<h2>Herkenbare patronen en snelle hypothesen<\/h2>\n\n<p>In het dagelijks leven zijn er bepaalde patronen die hun nut hebben bewezen en die ik meteen controleer:<\/p>\n<ul>\n  <li><strong>Concurrentie op het gebied van sloten<\/strong>: Duiken <em>queued_spin_lock_slowpath<\/em> of <em>mutex_spin_on_owner<\/em> 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.<\/li>\n  <li><strong>Afdrukken vanuit de planner<\/strong>: Komen steeds vaker voor <em>schedule()<\/em>, <em>pick_next_task_fair<\/em> of wake-up-paden, pas ik het aantal threads, affiniteiten en prioriteiten aan. Vaak volstaat het om \u201cpraatgrage\u201d threads wat te temperen of de CPU-instellingen duidelijk te defini\u00ebren.<\/li>\n  <li><strong>Netwerk-Softirqs<\/strong>: pieken bij <em>net_rx_action<\/em>, <em>napi_poll<\/em> of checksum-offloads duiden op pakketstormen of een suboptimale verdeling van RSS en IRQ\u2019s. Ik wijs IRQ\u2019s toe aan geschikte kernen en pas GRO\/TSO aan voor het gewenste doorvoer\/latentieprofiel.<\/li>\n  <li><strong>Opslagpaden<\/strong>: Veel tijd in <em>do_page_fault<\/em>, <em>copy_user_*<\/em> Of met slab-functies kan ik toewijzingspatronen, THP\/Huge Pages en NUMA-lokaliteit controleren. Een verkeerde plaatsing kost hier onopgemerkt heel veel cycli.<\/li>\n  <li><strong>RCU en timers<\/strong>: Domineren <em>rcu_core<\/em> of timer-callbacks, herzie ik de polling- en batch-strategie\u00ebn van mijn diensten om het systeem soepeler te laten draaien.<\/li>\n<\/ul>\n\n<h2>Zich verdiepen in meetdiscipline en reproduceerbaarheid<\/h2>\n\n<p>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\u2019s, zodat de beslissingen van de scheduler stabiel blijven. Wijzigingen documenteer ik, inclusief de versies van de kernel, stuurprogramma\u2019s en firmware. Bij risicovollere aanpassingen plan ik terugvalpunten in en voer ik direct na de ingreep opnieuw metingen uit. Zo krijg ik een betrouwbare <strong>Voor\/Na<\/strong>-Een verhaal dat ik zelfs maanden later nog steeds kan begrijpen.<\/p>\n\n<h2>Praktische tips: commando\u2019s die ik vaak gebruik<\/h2>\n\n<p>Afhankelijk van de vraag gebruik ik beknopte recepten:<\/p>\n<ul>\n  <li><strong>Uitgebreide scoping onder belasting<\/strong>: perf top -e cpu-cycles \u2013kernel \u2013user<br\/>Een snel overzicht om te zien of de kernel of de gebruikersruimte de touwtjes in handen heeft.<\/li>\n  <li><strong>Procesfocus met Callgraph<\/strong>: perf top -p PID -g \u2013kernel \u2013user<br\/>Toon mij de live-paden van de betreffende toepassing, zonder systeemruis.<\/li>\n  <li><strong>CPU-focus<\/strong>: perf top -C 2-5 -e cpu-cycles -g<br\/>Helpt bij NUMA- of IRQ-hotspots wanneer slechts enkele kernen \u201coververhit\u201d raken.<\/li>\n  <li><strong>Verdacht van opslag<\/strong>: perf top -e cache-misses -e cycles -g \u2013kernel<br\/>Geeft opslagpaden weer in verhouding tot cycli.<\/li>\n  <li><strong>Tijdelijke pieken vastleggen<\/strong>: perf top -F 999 -I 1000 -e cycles<br\/>Een hogere frequentie en kortere weergave-intervallen zorgen ervoor dat korte pieken worden geregistreerd.<\/li>\n<\/ul>\n\n<h2>Interpretatiehulp voor specifieke subsystemen<\/h2>\n\n<p>Op <strong>Netwerk<\/strong> 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 <strong>Geheugen<\/strong>-Op dit gebied kijk ik naar THP: helpt het mijn belasting, of zorgen split-\/merge-events voor storingen? Bij <strong>Opslag<\/strong> ik bedoel <em>blk_mq<\/em>-Symbolen en io_uring-paden als indicatie van wachtrijdieptes en samenvoegstrategie\u00ebn. Bij de <strong>planner<\/strong> Ik koppel wakeup-lawines aan lock- of IO-ketens en ontlast de paden door middel van backpressure in plaats van \u201cmeer threads\u201d.<\/p>\n\n<h2>De grenzen van perf top en wanneer ik van koers verander<\/h2>\n\n<p>Omdat <strong>perf top<\/strong> 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 <strong>perfect stat<\/strong> of offline-analyses vanuit perf record\/report. Als ik onduidelijke stacks tegenkom (ontbrekende symbolen, foutieve unwinding), zorg ik eerst dat ze zichtbaar worden \u2013 al het andere zou rondtasten in het duister zijn.<\/p>\n\n<h2>Kort samengevat<\/h2>\n\n<p>Met <strong>perf top<\/strong> 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\u00ebnter werken. Wie dit proces onder de knie heeft, bespaart dagen aan diagnose en verlaagt <strong>Latencies<\/strong> en zorgt voor merkbaar stabielere responstijden onder re\u00eble belasting.<\/p>","protected":false},"excerpt":{"rendered":"<p>perf top Linux toont live CPU-hotspots in de kernel. Zo kun je snel CPU-profilering uitvoeren en een nauwkeurige analyse van knelpunten maken.<\/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":"151","_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\/nl\/wp-json\/wp\/v2\/posts\/20626","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/webhosting.de\/nl\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/webhosting.de\/nl\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/webhosting.de\/nl\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/webhosting.de\/nl\/wp-json\/wp\/v2\/comments?post=20626"}],"version-history":[{"count":0,"href":"https:\/\/webhosting.de\/nl\/wp-json\/wp\/v2\/posts\/20626\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/webhosting.de\/nl\/wp-json\/wp\/v2\/media\/20619"}],"wp:attachment":[{"href":"https:\/\/webhosting.de\/nl\/wp-json\/wp\/v2\/media?parent=20626"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/webhosting.de\/nl\/wp-json\/wp\/v2\/categories?post=20626"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/webhosting.de\/nl\/wp-json\/wp\/v2\/tags?post=20626"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}