{"id":20682,"date":"2026-08-15T18:19:23","date_gmt":"2026-08-15T16:19:23","guid":{"rendered":"https:\/\/webhosting.de\/bcc-tools-linux-performance-ebpf-observability-focus\/"},"modified":"2026-08-15T18:19:23","modified_gmt":"2026-08-15T16:19:23","slug":"bcc-vaerktojer-linux-ydeevne-ebpf-overvagning-fokus","status":"publish","type":"post","link":"https:\/\/webhosting.de\/da\/bcc-tools-linux-performance-ebpf-observability-focus\/","title":{"rendered":"bcc tools i praksis: Praktisk vejledning til Linux-ydeevneoptimering med eBPF"},"content":{"rendered":"<p>Jeg viser trin for trin, hvordan jeg <strong>bcc-v\u00e6rkt\u00f8jer<\/strong> bruger eBPF til hurtigt at indkredse og afhj\u00e6lpe flaskehalse p\u00e5 Linux-servere. Her benytter jeg praktiske arbejdsgange, m\u00e5ler reelle forsinkelser i kernen og sammenk\u00e6der h\u00e6ndelser fra CPU, I\/O og netv\u00e6rk til en <strong>klar<\/strong> \u00c5rsagsanalyse.<\/p>\n\n<h2>Centrale punkter<\/h2>\n<ul>\n  <li><strong>eBPF<\/strong> giver dyb sporingsfunktion med lav overhead.<\/li>\n  <li><strong>bcc-v\u00e6rkt\u00f8jer<\/strong> omfatter CPU, I\/O, netv\u00e6rk og processer.<\/li>\n  <li><strong>Produktionsn\u00e6rt<\/strong> kan bruges uden \u00e6ndringer i appen.<\/li>\n  <li><strong>Tjekliste<\/strong> med ti v\u00e6rkt\u00f8jer til at komme i gang.<\/li>\n  <li><strong>Sikkerhed<\/strong> ved hj\u00e6lp af Verifier og klare retningslinjer.<\/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\/linux-performance-ebpf-4976.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Hvorfor eBPF til Linux-ydeevneoptimering<\/h2>\n<p>Jeg r\u00e6kker ud efter <strong>eBPF<\/strong>, fordi jeg \u00f8nsker at m\u00e5le kernelh\u00e6ndelser p\u00e5 en sikker og selektiv m\u00e5de og med meget lidt overhead. Traditionelle v\u00e6rkt\u00f8jer viser samlede tal, men de forklarer sj\u00e6ldent, hvorfor tr\u00e5de venter, pakker sendes igen, eller I\/O g\u00e5r i st\u00e5; eBPF udfylder dette hul med <strong>konkrete<\/strong> Begivenheder. Programmerne k\u00f8rer i kernen, verifikatoren kontrollerer dem p\u00e5 forh\u00e5nd, og jeg kan starte dem uden at genstarte. P\u00e5 den m\u00e5de kan jeg sammenholde userland-kald med kernestier og f\u00e5 et overblik, der muligg\u00f8r \u00f8jeblikkelige optimeringer. Hvis du \u00f8nsker at dykke dybere ned i emnet, kan du finde en oversigt i min korte introduktion til <a href=\"https:\/\/webhosting.de\/da\/ebpf-ydeevneanalyse-linux-sporing-serverovervagning-observabilitet\/\">eBPF-ydeevneanalyse<\/a>, der skitserer samspillet mellem sporing og observabilitet.<\/p>\n\n<h2>Hvad er BCC-v\u00e6rkt\u00f8jer, og hvor kan jeg finde dem?<\/h2>\n<p>Die <strong>bcc<\/strong> tools er f\u00e6rdige diagnosticeringsprogrammer baseret p\u00e5 eBPF og findes typisk i \/usr\/share\/bcc\/tools. Jeg starter dem direkte fra shellen, f\u00e5r tydelige standardudskrifter og beh\u00f8ver ikke at omprogrammere mine applikationer. Samlingen d\u00e6kker processer, systemkald, filsystemer, blok-I\/O, netv\u00e6rk, scheduler og profilering og er dermed velegnet til <strong>produktiv<\/strong> Analyser. Da jeg m\u00e5lrettet aktiverer sporing, er indflydelsen begr\u00e6nset, og m\u00e5lefejl som f\u00f8lge af overv\u00e5gningen er sm\u00e5. I mere komplekse tilf\u00e6lde supplerer jeg v\u00e6rkt\u00f8jerne med mit eget eBPF eller anvender desuden sampling-profiler.<\/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\/bcc_tools_linux_eBPF_7438.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Installation og krav<\/h2>\n<p>Jeg installerer den <strong>bcc<\/strong> v\u00e6rkt\u00f8jer via pakkeh\u00e5ndteringen (bcc-tools eller bpfcc-tools) p\u00e5 g\u00e6ngse distributioner. Det kr\u00e6ver en kerne med eBPF-underst\u00f8ttelse (fra 4.x, helst 4.9+), aktiverede BPF-funktioner og tilstr\u00e6kkelige rettigheder til at indl\u00e6se programmerne. P\u00e5 produktive servere tester jeg p\u00e5 forh\u00e5nd kernelens og distributionens eBPF-funktioner i et testmilj\u00f8, s\u00e5 senere m\u00e5linger <strong>p\u00e5lidelig<\/strong> k\u00f8rer. Jeg forhindrer sikkerhedsprofiler, der blokerer eBPF fuldst\u00e6ndigt, ved hj\u00e6lp af tilpassede politikker. De kortfattede vejledninger til ops\u00e6tning og betjening giver et praktisk overblik over <a href=\"https:\/\/webhosting.de\/da\/ebpf-linux-analysevaerktojer-serverovervagning-indsigt\/\">eBPF-analysev\u00e6rkt\u00f8jer<\/a>.<\/p>\n\n<h2>F\u00f8r start: System- og sikkerhedskontrol<\/h2>\n<p>Inden jeg foretager m\u00e5linger i produktionen, kontrollerer jeg v\u00e6rtsenhedens grundl\u00e6ggende funktioner. P\u00e5 den m\u00e5de undg\u00e5r jeg fejl ved opstart og opn\u00e5r reproducerbare resultater.<\/p>\n<ul>\n  <li>Kontroller kernefunktioner: <code>uname -r<\/code> og tilg\u00e6ngelige BPF-funktioner (f.eks. via Feature-Check). Vigtige er kprobes\/tracepoints, BTF (til stabile typeoplysninger) og perf-begivenheder.<\/li>\n  <li>Rettigheder og politikker: Jeg sikrer, at kun autoriserede brugere m\u00e5 indl\u00e6se eBPF (CAP_BPF\/CAP_SYS_ADMIN eller tilsvarende politik), og at LSM-profiler ikke blokerer indl\u00e6sningen.<\/li>\n  <li>Systemparametre: <code>kernel.unprivileged_bpf_disabled<\/code> er normalt aktiv i produktive milj\u00f8er. Derfor arbejder jeg bevidst ud fra sikrede sessioner og med tydelig logf\u00f8ring.<\/li>\n  <li>Gennemsigtige stier: Jeg foretr\u00e6kker mapper som <code>\/sys\/kernel\/debug\/tracing<\/code> og <code>\/sys\/fs\/bpf<\/code> med henblik p\u00e5 at rydde op i artefakter efter m\u00e5lingerne.<\/li>\n<\/ul>\n<p>Denne hygiejne sikrer, at jeg kan udf\u00f8re m\u00e5linger m\u00e5lrettet og p\u00e5 en reproducerbar m\u00e5de \u2013 uden bivirkninger.<\/p>\n\n<h2>Praktisk vejledning: De f\u00f8rste ti v\u00e6rkt\u00f8jer<\/h2>\n<p>Til en hurtig ydeevne-tjek f\u00f8lger jeg en fast r\u00e6kkef\u00f8lge. P\u00e5 den m\u00e5de kan jeg pr\u00e6cist indkredse \u00e5rsagerne i CPU, I\/O eller netv\u00e6rket og beslutte, om jeg skal se n\u00e6rmere p\u00e5 stakker eller timinger. Tabellen viser v\u00e6rkt\u00f8jernes hovedform\u00e5l og det sp\u00f8rgsm\u00e5l, jeg bruger dem til at afklare. Jeg holder k\u00f8rselstiden kort i f\u00f8rste omgang og gentager m\u00e5lingerne, s\u00e5 snart jeg har en mistanke <strong>bekr\u00e6fte<\/strong> vil. P\u00e5 den m\u00e5de undg\u00e5r jeg blinde vinkler og spilder ikke tid p\u00e5 akutte <strong>H\u00e6ndelser<\/strong>.<\/p>\n\n<table>\n  <thead>\n    <tr>\n      <th>V\u00e6rkt\u00f8j<\/th>\n      <th>Observeret<\/th>\n      <th>Typisk sp\u00f8rgsm\u00e5l<\/th>\n    <\/tr>\n  <\/thead>\n  <tbody>\n    <tr>\n      <td>execsnoop<\/td>\n      <td>Nye processer<\/td>\n      <td>Hvem opretter kortvarige job, der skaber en byrde?<\/td>\n    <\/tr>\n    <tr>\n      <td>opensnoop<\/td>\n      <td>Filttyper<\/td>\n      <td>Hvilke stier \u00e5bnes eller logges l\u00f8bende?<\/td>\n    <\/tr>\n    <tr>\n      <td>ext4 er langsommere (xfs*, btrfs*, zfs*)<\/td>\n      <td>Langsomme FS-operationer<\/td>\n      <td>Hvilke opkald viser h\u00f8je ventetider pr. volumen?<\/td>\n    <\/tr>\n    <tr>\n      <td>biolatency<\/td>\n      <td>Fordeling af blok-I\/O<\/td>\n      <td>Er der sporadiske eller vedvarende spidsbelastninger?<\/td>\n    <\/tr>\n    <tr>\n      <td>biosnoop<\/td>\n      <td>Enkelte I\/O-anmodninger<\/td>\n      <td>Hvilken proces f\u00e5r visse enheder til at bryde sammen?<\/td>\n    <\/tr>\n    <tr>\n      <td>cachestat<\/td>\n      <td>Side-cache-adf\u00e6rd<\/td>\n      <td>Er det v\u00e6rd at opgradere til mere RAM, eller oplever appen problemer?<\/td>\n    <\/tr>\n    <tr>\n      <td>tcpconnect<\/td>\n      <td>Nye TCP-forbindelser<\/td>\n      <td>Hvem henvender sig til hvilken service, og hvor ofte?<\/td>\n    <\/tr>\n    <tr>\n      <td>tcpaccept<\/td>\n      <td>Godkendte forbindelser<\/td>\n      <td>Hvilke serversockets er udsat for stor belastning?<\/td>\n    <\/tr>\n    <tr>\n      <td>tcpretrans<\/td>\n      <td>Re-udsendelser<\/td>\n      <td>Er tab af pakker et tegn p\u00e5 ustabile stier?<\/td>\n    <\/tr>\n    <tr>\n      <td>runqlat<\/td>\n      <td>Scheduler-forsinkelser<\/td>\n      <td>Venter tr\u00e5dene for l\u00e6nge p\u00e5 CPU-tid?<\/td>\n    <\/tr>\n  <\/tbody>\n<\/table>\n<p>Jeg bruger ogs\u00e5 <strong>profiler<\/strong> for at identificere hotspots i bruger- eller kernelspace og sammenfatte call-stacks. P\u00e5 den m\u00e5de opdager jeg ressourcekr\u00e6vende regul\u00e6re udtryk, ineffektive drivere eller spinlocks, som jeg derefter afhj\u00e6lper i koden eller i konfigurationen. Jeg bruger korte sampling-intervaller og sammenligner flere k\u00f8rsler, s\u00e5 outliers <strong>synlig<\/strong> bliver. Denne kombination af overblik og dybdeg\u00e5ende analyse sparer mig for meget tid p\u00e5 analysen. Derefter tester jeg optimeringen igen under den samme belastning.<\/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-performance-ebpf-tools-4528.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Udvidelse: Visning af off-CPU, l\u00e5sninger og ventetider<\/h2>\n<p>Ikke alle tilf\u00e6lde af h\u00f8j latenstid skyldes CPU\u2019en. Ofte venter tr\u00e5de \u201eoff-CPU\u201c p\u00e5 I\/O, l\u00e5se eller wakeups. Her kan supplerende bcc-v\u00e6rkt\u00f8jer og -profiler v\u00e6re til hj\u00e6lp:<\/p>\n<ul>\n  <li>Off-CPU-analyse: Jeg m\u00e5ler, hvor l\u00e6nge tr\u00e5de ikke befinder sig p\u00e5 CPU\u2019en, og hvilke stakke der f\u00f8rer dertil. Dette adskiller regnetid fra ventetid og afsl\u00f8rer blokeringer.<\/li>\n  <li>L\u00e5sekonflikter: Jeg ser specifikt p\u00e5 kritiske l\u00e5se i kernen og brugerrummet. Lange ventetider eller h\u00f8je konflikter tyder p\u00e5 serialiseringspunkter, som jeg bryder op (f.eks. ved hj\u00e6lp af sharding, finere granularitet eller andre datastrukturer).<\/li>\n  <li>Wakeup-stier: Forsinkelser mellem \u201eblev v\u00e6kket\u201c og \u201ek\u00f8rer igen\u201c afsl\u00f8rer problemer med planl\u00e6gning og prioritering eller for store worker-puljer.<\/li>\n<\/ul>\n<p>Jeg sammenholder disse signaler med <strong>runqlat<\/strong> og <strong>biolatency<\/strong>, for at skelne mellem \u00e5rsager relateret til hukommelse, I\/O og scheduler.<\/p>\n\n<h2>M\u00e5lehygiejne: Filtre, varighed, t\u00e6rskelv\u00e6rdier<\/h2>\n<p>For at sikre, at eBPF-m\u00e5lingerne forbliver reproducerbare, f\u00f8lger jeg tre grundregler:<\/p>\n<ul>\n  <li>Kort og pr\u00e6cist: I starten lader jeg v\u00e6rkt\u00f8jerne k\u00f8re i kort tid (f.eks. 10\u201330 sekunder) og fokuserer p\u00e5 mist\u00e6nkelige PID\u2019er, containere eller sockets.<\/li>\n  <li>Indstilling af t\u00e6rskelv\u00e6rdier: N\u00e5r jeg bruger \u201e*slower\u201c-v\u00e6rkt\u00f8jer, filtrerer jeg sm\u00e5 forsinkelser fra for at reducere st\u00f8j og kun se de problematiske opkald.<\/li>\n  <li>Begr\u00e6nsning af frekvens: Jeg bruger selektive filtre (f.eks. procesnavn, TID'er, porte) for at holde begivenhedsfrekvensen lav. P\u00e5 den m\u00e5de holdes overheadet p\u00e5 et minimum, og jeg undg\u00e5r tabte begivenheder.<\/li>\n<\/ul>\n<p>F\u00f8rst n\u00e5r jeg ser et m\u00f8nster, forl\u00e6nger jeg l\u00f8betiden eller udvider omfanget. P\u00e5 den m\u00e5de f\u00e5r jeg <strong>ren<\/strong> og p\u00e5lidelige stikpr\u00f8ver.<\/p>\n\n<h2>Praksisscenarie 1: Uforklarligt h\u00f8j CPU-belastning<\/h2>\n<p>Hvis CPU-indikatoren konstant viser h\u00f8je v\u00e6rdier, starter jeg med <strong>execsnoop<\/strong>, for at identificere kortvarige processer. Derefter m\u00e5ler jeg med runqlat, hvor l\u00e6nge tr\u00e5de venter p\u00e5 CPU-tid, og kontrollerer, om k\u00f8erne er overfyldte, eller om prioriteterne er forkert indstillet. Hvis ventetiderne bliver for lange, reducerer jeg antallet af arbejdstr\u00e5de, \u00e6ndrer tr\u00e5dpuljerne eller spreder cron-jobbene, s\u00e5 scheduleren <strong>Tag fat<\/strong> kan. Med profile samler jeg stacks og finder de egentlige hotspots i biblioteker og i min egen kode. F\u00f8rst n\u00e5r jeg har samlet disse oplysninger, tr\u00e6ffer jeg beslutninger om gr\u00e6nser, garbage collection, affiniteter eller kompilerflags.<\/p>\n\n<h2>Praktisk scenario 2: I\/O-forsinkelser og tr\u00e6ge applikationer<\/h2>\n<p>Hvis brugerne klager over, at systemet fryser ved lav CPU-belastning, tjekker jeg med <strong>ext4 er langsommere<\/strong> langsomme filsystemkald pr. proces. Dern\u00e6st bruger jeg biolatency til at se p\u00e5 fordelingen af blok-I\/O-tiderne pr. enhed for at opdage sporadiske spidsbelastninger eller vedvarende flaskehalse. biosnoop viser mig, om en enkelt tjeneste genererer et unormalt stort antal sm\u00e5 skrivninger og dermed udl\u00f8ser k\u00f8dannelse, der bremser andre processer. Med cachestat kan jeg se, om sidecachen rammer, eller om der er fejl <strong>dominere<\/strong> og mere RAM ville hj\u00e6lpe. I sidste ende er det mig, der afg\u00f8r, om batch-skrivninger, st\u00f8rre buffere eller en overgang til hurtigere lagringsmedier vil betale sig.<\/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\/tech_office_nachtarbeit_1234.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Praksisscenarie 3: Netv\u00e6rksstier og mikrotjenester<\/h2>\n<p>I distribuerede milj\u00f8er starter jeg med <strong>tcpconnect<\/strong>, for at m\u00e5le oprettelsen af forbindelser mellem tjenester. Derefter tjekker jeg med tcpaccept, hvilke serversockets der har s\u00e6rligt mange indg\u00e5ende forbindelser, og om begr\u00e6nsningerne p\u00e5 listener-siden virker. tcpretrans afsl\u00f8rer gentagne forsendelser og skelner mellem transportproblemer og applikationsfejl, inden jeg justerer timeouts og gentagelsesfors\u00f8g. Med disse tre signaler kan jeg se, om det er netv\u00e6rket, appen eller en upstream-tjeneste, der er \u00e5rsagen til <strong>Forsinkelse<\/strong> . Derefter tilpasser jeg backoff-strategier, keepalive-v\u00e6rdier, load balancer-indstillinger og bufferst\u00f8rrelser.<\/p>\n\n<h2>Driftssikkerhed og p\u00e5lidelighed ved eBPF<\/h2>\n<p>Jeg uploader kun <strong>p\u00e5lidelig<\/strong> Jeg tester mine egne eBPF-programmer f\u00f8rst p\u00e5 Staging. Kernel-Verifier blokerer fejlbeh\u00e6ftede programmer, men jeg s\u00e6tter desuden gr\u00e6nser for maps og buffers, s\u00e5 hukommelsesforbruget holdes inden for rimelige rammer. Jeg gemmer logfilerne for at holde \u00f8je med adf\u00e6rd og bivirkninger og hurtigt kunne gribe ind, hvis det bliver n\u00f8dvendigt. Politikker fastl\u00e6gger, hvem der m\u00e5 indl\u00e6se eBPF, s\u00e5 kontrollen forbliver hos platformsteamet, og sikkerhedskravene overholdes. Disse regler sikrer, at sporing i produktionsmilj\u00f8er <strong>P\u00e5lidelig<\/strong> forbliver u\u00e6ndret og giver ingen overraskelser.<\/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\/entwickler_schreibtisch_tools_4829.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Container- og Kubernetes-milj\u00f8er<\/h2>\n<p>I containere adskiller jeg systematiske problemer fra pod-specifikke effekter. Til det form\u00e5l filtrerer jeg m\u00e5linger efter cgroup, navnerum eller PID-interval. Mange bcc-v\u00e6rkt\u00f8jer tillader filtrering efter procesnavne eller -ID'er; alternativt foretager jeg m\u00e5linger p\u00e5 v\u00e6rten og tildeler h\u00e6ndelser til arbejdsbelastningerne via cgroup. Vigtigt:<\/p>\n<ul>\n  <li>PID-navneomr\u00e5de: PID\u2019erne er forskellige p\u00e5 v\u00e6rten og i containeren. Jeg kortl\u00e6gger ID\u2019erne eller filtrerer efter procesnavne\/porte.<\/li>\n  <li>Ressourcekvoter: CPU-begr\u00e6nsning via CFS-kvoter viser sig som lange ventetider, selvom systemet ikke udnyttes fuldt ud. Det kan jeg se ved hj\u00e6lp af <strong>runqlat<\/strong> i kombination med kvotem\u00e5linger.<\/li>\n  <li>Netv\u00e6rksnavneomr\u00e5der: Ved socket-analyser er jeg opm\u00e6rksom p\u00e5, at jeg bruger det rigtige navneomr\u00e5de. Jeg foretager m\u00e5linger p\u00e5 v\u00e6rtsgr\u00e6nsefladen og sammenholder resultaterne med pod-IP-adresser og porte.<\/li>\n<\/ul>\n<p>P\u00e5 den m\u00e5de forbliver m\u00e5leresultaterne p\u00e5lidelige, selv n\u00e5r mange arbejdsbelastninger k\u00f8rer t\u00e6t p\u00e5 hinanden.<\/p>\n\n<h2>Integration i observability-stacks<\/h2>\n<p>Jeg erstatter ikke min overv\u00e5gning, men supplerer den med <strong>eBPF<\/strong>. bcc-v\u00e6rkt\u00f8jer giver mig dybden, mens metrik-systemer, logfiler og APM viser bredden; tilsammen giver det et sammenh\u00e6ngende billede. Om n\u00f8dvendigt leder jeg traces fra bcc ind i log-pipelines, udl\u00f8ser snapshots ved h\u00e6ndelser og dokumenterer resultaterne i teamet. Til punktuelle profiler bruger jeg sampling som supplement til tidslinjer fra metrics, s\u00e5 afvigelser <strong>h\u00e5ndgribelig<\/strong> bliver. Hvis man desuden foretr\u00e6kker scripting, finder man i <a href=\"https:\/\/webhosting.de\/da\/bpftrace-hurtigere-pavisning-af-problemer-pa-hosting-serveren-diagnose\/\">bpftrace i hosting<\/a> en enkel m\u00e5de at besvare ad hoc-sp\u00f8rgsm\u00e5l ved hj\u00e6lp af miniskripter.<\/p>\n\n<h2>Almindelige forhindringer \u2013 og hvordan jeg kommer uden om dem<\/h2>\n<ul>\n  <li>Noisy Neighbor: Enkelte job skaber en kortvarig, men intens belastning. <strong>execsnoop<\/strong> plus <strong>profiler<\/strong> disse m\u00f8nstre afsl\u00f8res p\u00e5lideligt; jeg s\u00e6tter tidsrammer for dem eller isolerer dem ved hj\u00e6lp af kvoter.<\/li>\n  <li>NUMA og affiniteter: H\u00f8je ventetider p\u00e5 trods af ledige kerner tyder p\u00e5 adgang p\u00e5 tv\u00e6rs af NUMA-omr\u00e5der. Jeg tjekker CPU-affiniteter, hukommelsestilknytning og IRQ-fordeling.<\/li>\n  <li>IRQ\/SoftIRQ-hotspots: Netv\u00e6rksbelastningen kan overbelaste ksoftirqd-kerner. Jeg overv\u00e5ger retransmissioner, fordeler IRQ\u2019er via RSS\/k\u00f8er og justerer RPS\/XPS.<\/li>\n  <li>Effekter af sidecache: Koldstarter virker langsommere. Jeg tager h\u00f8jde for opvarmningsfaser og sammenligner <strong>cachestat<\/strong>-V\u00e6rdier f\u00f8r og efter belastning.<\/li>\n  <li>Kernel-opdateringer: Kprobes kan \u00e6ndre sig ved versionsskift. Jeg foretr\u00e6kker stabile tracepoints, tester p\u00e5 forh\u00e5nd og har et minimalt s\u00e6t klar.<\/li>\n<\/ul>\n\n<h2>Arbejdsgange, der har vist sig at fungere godt<\/h2>\n<ul>\n  <li>Incident-Snapshot: 60\u2013120 sekunders kombineret k\u00f8rsel (execsnoop, runqlat, biolatency, tcpretrans, profile). Derefter fokuserer jeg p\u00e5 det p\u00e5faldende delsystem.<\/li>\n  <li>Baseline-rutine: Ugentlige korte m\u00e5linger p\u00e5 centrale stier (f.eks. lager- og netv\u00e6rksprofil). P\u00e5 den m\u00e5de opdager jeg afvigelser i god tid.<\/li>\n  <li>Validering af \u00e6ndringer: F\u00f8r og efter konfigurations\u00e6ndringer sammenligner jeg de samme m\u00e5lepunkter for at kunne kvantificere effekten.<\/li>\n<\/ul>\n\n<h2>L\u00f8bende Linux-ydeevneoptimering<\/h2>\n<p>Jeg betragter performance som en l\u00f8bende proces, ikke som <strong>Engangsaktion<\/strong>. I CI\/CD integrerer jeg korte eBPF-baserede kontroller for at opdage regressioner tidligt og stoppe dem inden udrulningen. I vedligeholdelsesvinduer m\u00e5ler jeg typiske stier under belastning, opstiller baselinjer og dokumenterer acceptable latenstidsintervaller. P\u00e5 den m\u00e5de opdager jeg afvigelser hurtigt og undg\u00e5r at skulle g\u00e6tte mig frem under en h\u00e6ndelse, fordi sammenligningsdata <strong>tilg\u00e6ngelig<\/strong>. Denne rutine bidrager direkte til tilg\u00e6ngelighed, omkostningsstyring og brugeroplevelsen.<\/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\/bcc-tools-leitfaden-4956.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Mini-casestudie: Fra symptom til \u00e5rsag p\u00e5 12 minutter<\/h2>\n<p>Et API-cluster melder stigende 99p-forsinkelser, mens RPS forbliver u\u00e6ndret. Jeg tager et snapshot af h\u00e6ndelsen: <strong>tcpconnect<\/strong> viser ingen uregelm\u00e6ssigheder i oprettelsen af forbindelsen, <strong>tcpretrans<\/strong> forbliver lav \u2013 det er netv\u00e6rket tilsyneladende ikke. <strong>runqlat<\/strong> rapporterer korte, men hyppige ventetider; <strong>profiler<\/strong> viser hotspots i en JSON-serialisering. Samtidig overv\u00e5ger jeg med <strong>cachestat<\/strong> et fald i cache-hitraten under spidsbelastninger. Korrelationen tyder p\u00e5: Mange sm\u00e5 payloads, der serialiseres synkront og skrives med det samme.<\/p>\n<p>Jeg verificerer med <strong>ext4 er langsommere<\/strong>, der viser fsync-operationer p\u00e5 flere millisekunder p\u00e5 det samme volumen for API-processen; <strong>biolatency<\/strong> bekr\u00e6fter sporadiske spidsbelastninger i k\u00f8en p\u00e5 den ber\u00f8rte enhed. Modforanstaltning: Batching af skrivninger, st\u00f8rre buffer og asynkron t\u00f8mning p\u00e5 mindre f\u00f8lsomme punkter. Efter implementeringen falder 99p-latenserne med 35 %, cache-hitrate genoprettes, og <strong>runqlat<\/strong> viser igen smalle fordelinger.<\/p>\n\n<h2>Resum\u00e9 til brug i praksis<\/h2>\n<p>Med <strong>bcc<\/strong> Med v\u00e6rkt\u00f8jer og eBPF f\u00e5r jeg hurtigt et overblik over CPU, I\/O og netv\u00e6rk uden at skulle \u00e6ndre p\u00e5 applikationerne. Tjeklisten best\u00e5ende af execsnoop, opensnoop, ext4slower, biolatency, biosnoop, cachestat, tcpconnect, tcpaccept, tcpretrans og runqlat udg\u00f8r et godt udgangspunkt. Som supplement bruger jeg profile til at synligg\u00f8re hotspots og afhj\u00e6lpe kodepatier. Takket v\u00e6re klare retningslinjer, logning og begr\u00e6nsninger forbliver brugen i kernen <strong>sikker<\/strong> og overskuelig. Den, der konsekvent anvender denne metode, l\u00f8ser kapacitetsproblemer hurtigere, planl\u00e6gger kapaciteten bedre og s\u00e6nker omkostningerne pr. foresp\u00f8rgsel.<\/p>","protected":false},"excerpt":{"rendered":"<p>L\u00e6r, hvordan du professionelt analyserer og optimerer Linux-ydeevnen ved hj\u00e6lp af bcc-v\u00e6rkt\u00f8jer og eBPF. Vejledningen viser praktisk ydeevneoptimering med fokus p\u00e5 n\u00f8gleordet bcc-v\u00e6rkt\u00f8jer.<\/p>","protected":false},"author":1,"featured_media":20675,"comment_status":"","ping_status":"","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"inline_featured_image":false,"footnotes":""},"categories":[922],"tags":[],"class_list":["post-20682","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":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":"133","_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":"bcc tools","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":"20675","footnotes":null,"_links":{"self":[{"href":"https:\/\/webhosting.de\/da\/wp-json\/wp\/v2\/posts\/20682","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=20682"}],"version-history":[{"count":0,"href":"https:\/\/webhosting.de\/da\/wp-json\/wp\/v2\/posts\/20682\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/webhosting.de\/da\/wp-json\/wp\/v2\/media\/20675"}],"wp:attachment":[{"href":"https:\/\/webhosting.de\/da\/wp-json\/wp\/v2\/media?parent=20682"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/webhosting.de\/da\/wp-json\/wp\/v2\/categories?post=20682"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/webhosting.de\/da\/wp-json\/wp\/v2\/tags?post=20682"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}