{"id":21631,"date":"2026-09-21T15:04:22","date_gmt":"2026-09-21T13:04:22","guid":{"rendered":"https:\/\/webhosting.de\/kernel-tracepoints-linux-performanceanalyse-tracing-focus\/"},"modified":"2026-09-21T15:04:22","modified_gmt":"2026-09-21T13:04:22","slug":"kernel-tracepoints-linux-ydeevneanalyse-sporing-fokus","status":"publish","type":"post","link":"https:\/\/webhosting.de\/da\/kernel-tracepoints-linux-performanceanalyse-tracing-focus\/","title":{"rendered":"Forst\u00e5else og anvendelse af kernel-tracepoints til ydeevneanalyser i Linux"},"content":{"rendered":"<p>Ved hj\u00e6lp af kernel-tracepoints kan jeg forst\u00e5 ydelsesproblemer i Linux helt ned i kernen og m\u00e5lrettet m\u00e5le, hvor tiden g\u00e5r tabt. Jeg bruger disse <strong>M\u00e5lepunkter<\/strong>, for at overv\u00e5ge processer i scheduleren, i I\/O-stakken og i netv\u00e6rksstien \u2013 med minimal ekstra indsats og klare h\u00e6ndelsesdata.<\/p>\n\n<h2>Centrale punkter<\/h2>\n<p>De f\u00f8lgende centrale aspekter giver dig et hurtigt overblik over, hvad jeg l\u00e6gger v\u00e6gt p\u00e5, n\u00e5r jeg arbejder med tracepoints.<\/p>\n<ul>\n  <li><strong>Statisk<\/strong> Forankrede begivenheder leverer p\u00e5lidelige data p\u00e5 markante steder i koden.<\/li>\n  <li><strong>Lavt overhead<\/strong> g\u00f8r sporing praktisk gennemf\u00f8rlig, selv under stor belastning.<\/li>\n  <li><strong>Et bredt \u00f8kosystem<\/strong> med ftrace, perf, LTTng og eBPF-v\u00e6rkt\u00f8jer.<\/li>\n  <li><strong>M\u00e5lrettet aktivering<\/strong> og filtrering forhindrer dataoversv\u00f8mmelser.<\/li>\n  <li><strong>Kombination<\/strong> ved hj\u00e6lp af pr\u00e6stationst\u00e6llere viser \u00e5rsagsk\u00e6der.<\/li>\n<\/ul>\n<p>Jeg holder listen kort og fokuserer p\u00e5 <strong>Prioriteringer<\/strong> analysen. P\u00e5 den m\u00e5de spilder jeg ikke tid p\u00e5 sideforhold og holder \u00f8je med de vigtigste signaler. De n\u00e6vnte punkter styrer mit praktiske arbejde fra den f\u00f8rste mistanke til den verificerede optimering. Dermed skaber jeg <strong>Gennemsigtighed<\/strong> og reproducerbarhed. Jeg arbejder ud fra data og kontrollerer hvert eneste trin.<\/p>\n\n<h2>Hvad er kernel-tracepoints?<\/h2>\n\n<p>Et tracepoint er et statisk instrumenteringspunkt i kernekoden, der udl\u00f8ser en begivenhed med strukturerede felter. Der ser jeg blandt andet <strong>PID<\/strong>, tidsstempler, CPU, statuskoder eller st\u00f8rrelsesangivelser, afh\u00e6ngigt af begivenheden. Via makroer som TRACE_EVENT definerer kernen placeringen, formatet og de leverede data. Disse begivenheder forekommer ved relevante gr\u00e6nseflader som planl\u00e6gning, blok-I\/O, filsystemer eller netv\u00e6rksstien. Jeg kan aktivere dem n\u00e5r som helst uden at patche kernen eller s\u00e6tte produktive systemer p\u00e5 spil, hvilket giver mig <strong>Planl\u00e6gning af sikkerhed<\/strong> der.<\/p>\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\/09\/linux-tracepoints-analyse-4875.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Hvorfor bruge tracepoints til m\u00e5ling af ydeevne<\/h2>\n\n<p>Tracepoints koster n\u00e6sten ingenting, n\u00e5r de er inaktive, og medf\u00f8rer kun en lille ekstra belastning, n\u00e5r de aktiveres. Selv n\u00e5r begivenhederne er aktiveret, m\u00e5ler jeg typisk kun en ekstra latenstid i det lave tocifrede nanosekundomr\u00e5de \u2013 hvilket er godt nok til systemer med strenge <strong>Latensm\u00e5l<\/strong>. Da de er solidt forankret i kernen, kan jeg gentage analyser p\u00e5 tv\u00e6rs af kerneversioner p\u00e5 en konsistent m\u00e5de. Deres strukturerede output kan p\u00e5lideligt analyseres og viderebehandles. Dermed opn\u00e5r jeg <strong>p\u00e5lidelig<\/strong> M\u00e5linger i stedet for uklare logfragmenter.<\/p>\n\n<h2>Tidsstempler, ure og r\u00e6kkef\u00f8lge<\/h2>\n<p>For at kunne fortolke forsinkelser korrekt er jeg opm\u00e6rksom p\u00e5 den anvendte tidskilde. Monotone ure (f.eks. CLOCK_MONOTONIC) er mere p\u00e5lidelige til m\u00e5linger end realtid, fordi NTP-korrektioner ikke virker tilbagevirkende. P\u00e5 flerkernede systemer leverer buffere pr. CPU begivenheder, hvis r\u00e6kkef\u00f8lge er korrekt p\u00e5 det enkelte CPU, men som kun kan sammenlignes p\u00e5 tv\u00e6rs af CPU\u2019er via tidsstempler. Derfor kalibrerer jeg perspektivet: Enten sorterer jeg begivenhederne pr. CPU, eller ogs\u00e5 bruger jeg v\u00e6rkt\u00f8jer, der synkroniserer buffere og l\u00f8ser tidslinjekonflikter korrekt. Ved meget stramme budgetter tjekker jeg, om TSC-grundlaget er stabilt, s\u00e5 afvigelser ikke fejlagtigt fremst\u00e5r som jitter. P\u00e5 den m\u00e5de forhindrer jeg fejlagtige fortolkninger, n\u00e5r der for eksempel sker wakeups p\u00e5 CPU 3 og kontekstskift p\u00e5 CPU 7.<\/p>\n\n<h2>Oversigt over Linux-tracing-\u00f8kosystemet<\/h2>\n\n<p>Jeg bruger flere v\u00e6rkt\u00f8jer, som alle bygger p\u00e5 de samme tracepoint-begivenheder. ftrace kan hurtigt aktiveres via sporingsfilsystemet og egner sig til ad hoc-kontroller med <strong>Live-udsigt<\/strong>. Med perf forbinder jeg tracepoints, hardwaret\u00e6llere og sampling for at synligg\u00f8re sammenh\u00e6nge. LTTng kan h\u00e5ndtere lange optagelser med h\u00f8j h\u00e6ndelsesfrekvens og lav ekstra belastning, hvilket er afg\u00f8rende for dybdeg\u00e5ende analyser. eBPF-baserede v\u00e6rkt\u00f8jer l\u00e6ser tracepoints, udf\u00f8rer aggregeringer i kernen og reducerer dermed <strong>Datatrafik<\/strong> til brugerrummet.<\/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\/09\/linux_kernel_trace_4173.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Ringbuffer og tabskontrol<\/h2>\n<p>Bag hver aktiv begivenhed arbejder en ringbuffer pr. CPU. Jeg dimensionerer disse buffere, s\u00e5 belastningstoppe udj\u00e6vnes uden at begivenheder g\u00e5r tabt. Tabst\u00e6llere og advarsler fra v\u00e6rkt\u00f8jerne er vigtige: I perf holder jeg \u00f8je med t\u00e6lleren for tabte begivenheder, og i ftrace tjekker jeg statistikkerne for droppede begivenheder i tracefs. LTTng viser ligeledes, hvis forbrugerstien ikke f\u00f8lger med. Opst\u00e5r der tab, \u00f8ger jeg bufferne, filtrerer mere strengt eller aggregerer tidligt. Til \u201eFlight Recorder\u201c-scenarier bruger jeg snapshots, der bevarer en tidsperiode omkring en trigger. P\u00e5 den m\u00e5de holder jeg datakvaliteten h\u00f8j og undg\u00e5r fejlagtige hypoteser baseret p\u00e5 ufuldst\u00e6ndige spor.<\/p>\n\n<h2>Valg af v\u00e6rkt\u00f8jer: ftrace, perf, LTTng, eBPF<\/h2>\n\n<p>Jeg starter ofte med perf, fordi jeg der kan analysere sampling, t\u00e6llerv\u00e6rdier og tracepoints samlet. Til hurtige begivenhedsinspektioner bruger jeg ftrace og aktiverer m\u00e5lrettet <strong>Begivenheder<\/strong> fri. Komplekse, langvarige sessioner med mange CPU\u2019er k\u00f8rer jeg gerne med LTTng, da det p\u00e5lideligt registrerer h\u00f8je datahastigheder. Hvis jeg \u00f8nsker at foretage forh\u00e5ndsaggregering i kernen, bruger jeg eBPF-baserede tracere for kun at eksportere sammenfattede n\u00f8gletal. Hvis du vil dykke dybere ned i perf, finder du praktiske tips i artiklen om <a href=\"https:\/\/webhosting.de\/da\/linux-perf-vaerktoj-analyse-af-cpu-flaskehalse-optimering-serverbelastning-profilering\/\">perf-v\u00e6rkt\u00f8j<\/a>, hvilket er til hj\u00e6lp for b\u00e5de begyndere og \u00f8vede.<\/p>\n\n<h2>Reproducerbarhed og automatisering af sessioner<\/h2>\n<p>Jeg gemmer opskriften p\u00e5 vellykkede sessioner: aktiverede begivenheder, filtre, bufferst\u00f8rrelser, samplingshastigheder og k\u00f8retid. Derudover dokumenterer jeg kerneversion, v\u00e6rkt\u00f8jsversioner, CPU-topologi og str\u00f8mindstillinger, s\u00e5 senere m\u00e5linger kan sammenlignes. P\u00e5 den m\u00e5de kan jeg om n\u00f8dvendigt gentage en session u\u00e6ndret, overf\u00f8re den til andre v\u00e6rter eller automatisere den i CI-pipelines. Ved l\u00e6ngerevarende analyser gemmer jeg r\u00e5data og genererer sammenfatninger (histogrammer, percentiler, heatmaps) umiddelbart efter m\u00e5lingen. Jeg arbejder iterativt: korte, m\u00e5lrettede k\u00f8rsler, evaluering, pr\u00e6cisering af hypotesen \u2013 og s\u00e5 m\u00e5ler jeg igen. P\u00e5 den m\u00e5de forsvinder jeg ikke i dataene, men kan drage p\u00e5lidelige konklusioner med minimal l\u00f8betid.<\/p>\n\n<h2>Anvendelsesscenarier i praksis<\/h2>\n\n<p>I scheduleren overv\u00e5ger jeg kontekstskift, wakeups og k\u00f8-interaktioner for at afd\u00e6kke overdreven skift eller uhensigtsm\u00e6ssige prioriteter. I blokstakken korrelerer jeg indsendelse og afslutning af anmodninger med k\u00f8ens dybde og st\u00f8rrelse, og p\u00e5 den m\u00e5de afd\u00e6kker jeg <strong>Opbevaring<\/strong>-flaskehalse. I netv\u00e6rksstien sporer jeg ind- og udg\u00e5ende pakker samt k\u00f8er for at forst\u00e5 latensek\u00e6der pr. flow. Ved systemkald unders\u00f8ger jeg hyppighed og latenstid for at identificere afvigelser i hotpaths. Om n\u00f8dvendigt kombinerer jeg dette med hardwaret\u00e6llere, s\u00e5 cache-misses, branch-mispredictions og I\/O-h\u00e6ndelser kan <strong>\u00e5rsagsk\u00e6de<\/strong> resultat.<\/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\/09\/kernel-tracepoints-linux-8101.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Konkrete navne p\u00e5 begivenheder og fortolkning af felter<\/h2>\n<p>Jeg v\u00e6lger begivenheder p\u00e5 en s\u00e5dan m\u00e5de, at jeg kan rekonstruere hele forl\u00f8bet med f\u00e5 m\u00e5lepunkter. Et grunds\u00e6t, der har vist sig at fungere godt:<\/p>\n<ul>\n  <li>Scheduler: sched:sched_switch (forrige\/n\u00e6ste kommando, forrige tilstand), sched:sched_wakeup og sched:sched_wakeup_new (v\u00e6kningskilde, m\u00e5l-CPU)<\/li>\n  <li>Block-I\/O: block:block_rq_issue, block:block_rq_complete (sektorer, st\u00f8rrelse, enhed, latenstid via delta)<\/li>\n  <li>Netv\u00e6rk: net:net_dev_queue, net:netif_receive_skb (k\u00f8h\u00e5ndtering og modtagelse), tcp:tcp_retransmit_skb (genudsendelser)<\/li>\n  <li>Syscalls: syscalls:sys_enter_*, syscalls:sys_exit_* (varighed pr. opkald, fejlkoder)<\/li>\n<\/ul>\n<p>Jeg tjekker feltbetydningerne p\u00e5 forh\u00e5nd, s\u00e5 jeg kan korrelere korrekt: Fra prev_state udleder jeg sovende opgaver, og fra CPU-felterne kan jeg se bev\u00e6gelser p\u00e5 tv\u00e6rs af sockets. Ved netv\u00e6rksh\u00e6ndelser inddrager jeg, hvis det er muligt, flow-metadata (f.eks. porte) for at gruppere latenstider pr. forbindelse. P\u00e5 den m\u00e5de f\u00e5r jeg stier, der faktisk stemmer overens med den observerede adf\u00e6rd i tjenesten.<\/p>\n\n<h2>Trin for trin: Fra sp\u00f8rgsm\u00e5let til tracesessionen<\/h2>\n\n<p>Jeg starter altid med et klart sp\u00f8rgsm\u00e5l, for eksempel: \u201eHvorfor stiger svartiderne i spidsbelastningsperioder?\u201c Dette trin tvinger mig til at finde det rigtige <strong>Delsystem<\/strong> at v\u00e6lge: Scheduler, Netv\u00e6rk, Blok, Filsystem eller Hukommelsesstyring. Derefter viser jeg relevante sporingspunkter med \u201eperf list\u201c eller i sporingsfilsystemet og noterer de relevante felter. Jeg konfigurerer sessionen, indstiller filtre p\u00e5 PID-, CPU- eller h\u00e6ndelsesfelter og fastl\u00e6gger buffere samt varighed. Derefter k\u00f8rer jeg belastningsscenariet og analyserer efterf\u00f8lgende latenstidsfordelinger, r\u00e6kkef\u00f8lger og korrelationer, inden jeg tester en hypotese og m\u00e5ler \u00e6ndringen igen for at <strong>Effekt<\/strong> for at bekr\u00e6fte.<\/p>\n\n<h2>Filtrering og korrelation: PID\u2019er, TID\u2019er, cgroups og flows<\/h2>\n<p>Pr\u00e6cise filtre sparer mig tid. Afh\u00e6ngigt af form\u00e5let arbejder jeg med PID-\/TID-filtre, CPU-udv\u00e6lgelse eller cgroup-filtre for at overholde gr\u00e6nserne for containere eller tjenester. N\u00e5r jeg vil forst\u00e5 netv\u00e6rkslatens, korrelerer jeg h\u00e6ndelser via flow-attributter (f.eks. kilde-\/destinationsport), s\u00e5 jeg kan adskille bulktrafik og latensf\u00f8lsomme flows. N\u00e5r det g\u00e6lder filer, sorterer jeg efter enhed\/blokadresse eller grupperer efter mount-punkt, afh\u00e6ngigt af v\u00e6rkt\u00f8jet. I scheduler-omr\u00e5det m\u00e5ler jeg fra wakeup til den f\u00f8rste sched_switch til m\u00e5l-CPU\u2019en; p\u00e5 den m\u00e5de kan jeg se ventetiden i runqueues adskilt fra den egentlige CPU-tid.<\/p>\n\n<h2>Styring af overhead: Bedste praksis<\/h2>\n\n<p>Jeg aktiverer kun de sporingspunkter, jeg virkelig har brug for, for at holde datam\u00e6ngden og den ekstra belastning p\u00e5 et lavt niveau. Filtrering efter PID, CPU eller felter holder st\u00f8jniveauet lavt og sk\u00e5ner systemet <strong>Buffer<\/strong>. Jeg tilpasser bufferst\u00f8rrelsen til begivenhedsfrekvensen, s\u00e5 jeg ikke g\u00e5r glip af nogen begivenheder. Jeg s\u00e6tter klare tidsbegr\u00e6nsninger for sessionerne og gentager dem kun, hvis jeg vil teste en hypotese. Ved ekstremt hyppige begivenheder anvender jeg sampling eller in-kernel-aggregering via eBPF, s\u00e5 analysen i brugerrummet <strong>slank<\/strong> rester.<\/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\/09\/kernel_tracepoints_analyse_4512.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Sammenligning: Tracepoints og performance-begivenheder<\/h2>\n\n<p>De to tilgange supplerer hinanden. Tracepoints forklarer konkrete h\u00e6ndelser i delsystemer og leverer meningsfulde <strong>Felter<\/strong>. Ydelsesm\u00e5linger giver mig et statistisk overblik over cyklusser, cache-misses eller forgreninger. Ved at se p\u00e5 det samlede billede kan jeg se, hvor meget tid der g\u00e5r tabt, og hvor det g\u00e5r galt. Den f\u00f8lgende tabel hj\u00e6lper mig med at v\u00e6lge v\u00e6rkt\u00f8jer og fokuserer p\u00e5 det, jeg har brug for i den n\u00e6ste m\u00e5lerunde. Den fungerer som <strong>\u00d8nskeliste<\/strong> til planl\u00e6gningen af sessionen.<\/p>\n\n<table>\n  <thead>\n    <tr>\n      <th>Aspekt<\/th>\n      <th>Tracepoints<\/th>\n      <th>Performance-begivenheder (perf)<\/th>\n    <\/tr>\n  <\/thead>\n  <tbody>\n    <tr>\n      <td>Stabilitet<\/td>\n      <td>Statiske begivenheder p\u00e5 kernel-steder, stort set versionskonsistente<\/td>\n      <td>Afh\u00e6nger af hardwaret\u00e6llere og kerneimplementering<\/td>\n    <\/tr>\n    <tr>\n      <td>Overhead<\/td>\n      <td>Lav, begivenhedsstyret<\/td>\n      <td>Meget lav ved sampling<\/td>\n    <\/tr>\n    <tr>\n      <td>Fokus<\/td>\n      <td>Konkrete begivenheder i delsystemerne<\/td>\n      <td>Systemomfattende n\u00f8gletal<\/td>\n    <\/tr>\n    <tr>\n      <td>Dataformat<\/td>\n      <td>Struktureret, maskinl\u00e6sbar<\/td>\n      <td>M\u00e5lev\u00e6rdier, pr\u00f8ver, profiler<\/td>\n    <\/tr>\n    <tr>\n      <td>Typisk brug<\/td>\n      <td>\u201eHvad\u201c og \u201ehvorn\u00e5r\u201c i en rute<\/td>\n      <td>\u201eHvor meget\u201c og \u201eHvor dyrt\u201c<\/td>\n    <\/tr>\n  <\/tbody>\n<\/table>\n\n<p>Jeg starter gerne med performance-events for at lokalisere en grov flaskehals og g\u00e5r derefter i detaljer med tracepoints. Omvendt aktiverer jeg f\u00f8rst tracepoints, n\u00e5r jeg vil forst\u00e5 en sti, og tilf\u00f8jer senere t\u00e6llere til <strong>Kvantisering<\/strong>. Denne r\u00e6kkef\u00f8lge sparer tid og sikrer, at dataindsamlingen forbliver m\u00e5lrettet. Det er vigtigt at holde \u00f8je med h\u00e6ndelsesfrekvensen, s\u00e5 der ikke g\u00e5r data tabt. P\u00e5 den m\u00e5de holder jeg styr p\u00e5 <strong>M\u00e5lemetode<\/strong> p\u00e5 rette kurs.<\/p>\n\n<h2>Gr\u00e6nser, validering og krydskontrol<\/h2>\n<p>Ikke alle driver-stier er fuldt ud instrumenteret, og nogle sj\u00e6ldne fejlforl\u00f8b vises ikke i sporene. Derfor sammenligner jeg m\u00e5lingerne med alternative datakilder: t\u00e6llere, logfiler, syntetiske tests, men ogs\u00e5 simple tidsm\u00e5linger i selve tjenesten. Hvis spor og t\u00e6llere ikke stemmer overens, tjekker jeg f\u00f8rst filtre og datatab, derefter klokkebasen. Jeg er desuden opm\u00e6rksom p\u00e5 interferenser: Debug-builds, h\u00f8je logningshastigheder eller sikkerhedshooks kan forskyde latenstiderne. Kun ved hj\u00e6lp af krydskontrol kan jeg med sikkerhed fastsl\u00e5, at en fundet \u00e5rsag rent faktisk er n\u00f8glen til optimeringen.<\/p>\n\n<h2>Eksempel: M\u00e5ling af lagtider i lagringssystemer<\/h2>\n\n<p>I Block-Stack aktiverer jeg sporingspunkter for indsendelse og afslutning af I\/O-anmodninger. Mens en belastningstest k\u00f8rer, registrerer jeg tidsstempler, anmodningens st\u00f8rrelse, enhed og PID for at <strong>Forsinkelser<\/strong> at g\u00f8re dem synlige for hver proces. Derefter sorterer jeg efter varighed og f\u00e5r vist histogrammer, der viser toppe og afvigelser. I en anden gennemgang inkluderer jeg desuden CPU-t\u00e6llere for at unders\u00f8ge, om regnebelastningen og I\/O-forsinkelserne h\u00e6nger sammen. Til sidst justerer jeg I\/O-scheduleren, k\u00f8dybden eller storage-backend og gentager m\u00e5lingen, indtil <strong>M\u00e5l<\/strong> er n\u00e5et p\u00e5 en p\u00e5lidelig m\u00e5de.<\/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\/09\/linux_tracepoints_analyse_4723.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Eksempel: Forst\u00e5 forsinkelser i scheduler og wakeup<\/h2>\n<p>N\u00e5r tr\u00e5de reagerer \u201espiky\u201c, m\u00e5ler jeg tiden fra `sched:sched_wakeup` til den f\u00f8rste `sched:sched_switch` p\u00e5 m\u00e5l-CPU\u2019en. P\u00e5 den m\u00e5de adskiller jeg ventetiden i runqueues fra den faktiske eksekveringstid. Jeg grupperer efter CPU, prioritet og politik (CFS\/RT) for at opdage uoverensstemmelser \u2013 for eksempel n\u00e5r tr\u00e5de med stort CPU-behov ender p\u00e5 overbelastede kerner, selvom der findes ledige kerner. Hvis jeg ser mange cross-CPU-wakeups, tjekker jeg affiniteter og NUMA-tildeling. I kombination med Perf-t\u00e6llere for LLC-misses dokumenterer jeg, om forkert placering \u00f8ger cache-latenser. En lille justering af tr\u00e5daffinitet eller planl\u00e6gningsparametre giver her ofte \u00f8jeblikkelige, m\u00e5lbare forbedringer.<\/p>\n\n<h2>Tips til produktive arbejdsmilj\u00f8er<\/h2>\n\n<p>Jeg aktiverer sporingen uden for vedligeholdelsesvinduerne kun med klare filtre og korte tidsvinduer. F\u00f8rst tjekker jeg h\u00e6ndelsesfrekvenserne p\u00e5 et testsystem som eksempel, s\u00e5 jeg kan <strong>Buffer<\/strong> indstiller det passende. I produktive milj\u00f8er bruger jeg aggregering i kernen for at reducere belastningen i brugerrummet. Til hurtige ad hoc-diagnoser er det v\u00e6rd at kigge p\u00e5 <a href=\"https:\/\/webhosting.de\/da\/bpftrace-hurtigere-pavisning-af-problemer-pa-hosting-serveren-diagnose\/\">bpftrace i hosting<\/a>, fordi jeg dermed f\u00e5r de f\u00f8rste svar p\u00e5 f\u00e5 minutter. Jeg dokumenterer hver m\u00e5ling med det samme, s\u00e5 jeg <strong>Repeterbarhed<\/strong> sande.<\/p>\n\n<h2>Sikkerhed, rettigheder og gr\u00e6nser for isolation<\/h2>\n<p>Tracing p\u00e5 kernelen kr\u00e6ver de rette rettigheder. Jeg sikrer mig, at tracefs er monteret korrekt, og tjekker systemomfattende indstillinger som perf_event_paranoid eller kptr_restrict, der kan skjule detaljer. I f\u00f8lsomme milj\u00f8er begr\u00e6nser jeg, hvem der m\u00e5 aktivere sporing, og fastl\u00e6gger procedurer for godkendelse. Jeg anonymiserer procesnavne eller IP-adresser, n\u00e5r data skal deles, og definerer klare regler for opbevaring af sporingsdata. I containere g\u00e6lder f\u00f8lgende: Root i containeren har ikke automatisk adgang til at l\u00e6se host-kernel-begivenheder. Jeg foretager derfor helst sporing fra v\u00e6rten eller arbejder med eksplicitte cgroup-filtre for kun at registrere den p\u00e5g\u00e6ldende arbejdsbelastning.<\/p>\n\n<h2>Tjekliste og typiske fejl<\/h2>\n\n<p>F\u00f8rst definerer jeg sp\u00f8rgsm\u00e5let, derefter delsystemerne og til sidst begivenhederne \u2013 i netop denne r\u00e6kkef\u00f8lge. Jeg tjekker, om jeg virkelig registrerer alle de n\u00f8dvendige felter, f\u00f8r jeg starter belastningstesten. Glem ikke at indstille filtre; ufiltrerede sessioner skaber hurtigt datastr\u00f8mme og overbelaster <strong>Hukommelse<\/strong>. Jeg sammenligner kerneversion, begivenhedsnavn og v\u00e6rkt\u00f8jsindstillinger for at undg\u00e5 misforst\u00e5elser. Til mere avancerede eBPF-workflows udvider jeg ops\u00e6tningen med <a href=\"https:\/\/webhosting.de\/da\/bcc-vaerktojer-linux-ydeevne-ebpf-overvagning-fokus\/\">BCC-v\u00e6rkt\u00f8jer<\/a>, for at forbehandle komplekse m\u00e5lev\u00e6rdier i kernen og kun eksportere aggregerede signaler, hvilket <strong>Klarhed<\/strong> skaber.<\/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\/09\/linux-performance-analyse-5921.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Tracing i containere og VM\u2019er<\/h2>\n<p>I container-ops\u00e6tninger filtrerer jeg helst efter cgroup for at se netop den tjeneste, der interesserer mig. P\u00e5 den m\u00e5de kan jeg foretage m\u00e5linger i multi-tenant-milj\u00f8er uden at registrere andre arbejdsbelastninger. P\u00e5 virtuelle maskiner (VM\u2019er) g\u00e6lder det, at jeg kun ser, hvad der sker i g\u00e6stekernelen. Virtio-\/vhost-stier og hypervisor-siden forbliver usynlige uden host-tracing. For at m\u00e5le ende-til-ende-latenser korrelerer jeg derfor g\u00e6st- og host-m\u00e5linger, n\u00e5r jeg vil have overblik over begge indflydelsesomr\u00e5der. Derudover tager jeg h\u00f8jde for tidssynkroniseringen mellem v\u00e6rt og g\u00e6st, s\u00e5 jeg kan sammenholde logfiler, metrikker og sporinger p\u00e5 en meningsfuld m\u00e5de. Med denne disciplin forbliver analyserne p\u00e5lidelige, selv i virtualiserede milj\u00f8er.<\/p>\n\n<h2>Til senere brug: De vigtigste erfaringer<\/h2>\n\n<p>Tracepoints giver mig stabile ankerpunkter i kernen og leverer strukturerede begivenheder uden un\u00f8dvendig ballast. Jeg bruger dem til at f\u00e5 pr\u00e6cise <strong>Processer<\/strong> at forst\u00e5, isolere flaskehalse og kontrollere \u00e6ndringer p\u00e5 en m\u00e5lbar m\u00e5de. Med ftrace, perf, LTTng og eBPF v\u00e6lger jeg det rette v\u00e6rkt\u00f8j alt efter m\u00e5let og kombinerer dem efter behov. En klar problemstilling, strenge filtre og passende bufferst\u00f8rrelser holder belastningen lav og dataene brugbare. P\u00e5 den m\u00e5de finder jeg \u00e5rsagerne hurtigere, dokumenterer effekten af mine tiltag og holder <strong>Ydelse<\/strong> under konstant kontrol.<\/p>","protected":false},"excerpt":{"rendered":"<p>L\u00e6r, hvordan du bruger kernel-tracepoints i Linux-kernen til effektiv ydeevneanalyse. Artiklen viser, hvilke Linux-tracingv\u00e6rkt\u00f8jer der bygger p\u00e5 tracepoints, og hvordan du kan identificere reelle flaskehalse med dem.<\/p>","protected":false},"author":1,"featured_media":21624,"comment_status":"","ping_status":"","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"inline_featured_image":false,"footnotes":""},"categories":[922],"tags":[],"class_list":["post-21631","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-technologie"],"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":"1790008692:1","_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":"106","_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":"kernel tracepoints","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":"21624","footnotes":null,"_links":{"self":[{"href":"https:\/\/webhosting.de\/da\/wp-json\/wp\/v2\/posts\/21631","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=21631"}],"version-history":[{"count":0,"href":"https:\/\/webhosting.de\/da\/wp-json\/wp\/v2\/posts\/21631\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/webhosting.de\/da\/wp-json\/wp\/v2\/media\/21624"}],"wp:attachment":[{"href":"https:\/\/webhosting.de\/da\/wp-json\/wp\/v2\/media?parent=21631"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/webhosting.de\/da\/wp-json\/wp\/v2\/categories?post=21631"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/webhosting.de\/da\/wp-json\/wp\/v2\/tags?post=21631"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}