{"id":21347,"date":"2026-09-13T08:35:03","date_gmt":"2026-09-13T06:35:03","guid":{"rendered":"https:\/\/webhosting.de\/linux-softirq-auslastung-analysieren-performance-tuning-datacenter\/"},"modified":"2026-09-13T08:35:03","modified_gmt":"2026-09-13T06:35:03","slug":"analyse-af-linux-softirq-udnyttelse-ydeevneoptimering-datacenter","status":"publish","type":"post","link":"https:\/\/webhosting.de\/da\/linux-softirq-auslastung-analysieren-performance-tuning-datacenter\/","title":{"rendered":"Analyse og optimering af Linux SoftIRQ-udnyttelse"},"content":{"rendered":"<p>Jeg viser trin for trin, hvordan jeg <strong>Linux SoftIRQ<\/strong>-m\u00e5le udnyttelsen, synligg\u00f8re flaskehalse og genvinde kontrollen med blot et par justeringer i kernen. Her prioriterer jeg m\u00e5lbare effekter: kortere <strong>Forsinkelser<\/strong>, afbalancerede CPU-kerner og stabil pakkeh\u00e5ndtering under h\u00f8j netv\u00e6rksbelastning.<\/p>\n\n<h2>Centrale punkter<\/h2>\n<ul>\n  <li><strong>M\u00e5lepunkter<\/strong> forst\u00e5: \/proc\/softirqs, softnet_stat, interrupts<\/li>\n  <li><strong>Symptomer<\/strong> identificere: ksoftirqd-belastning, pakketab, latenstoppe<\/li>\n  <li><strong>Indstilling<\/strong> styring: netdev_budget og netdev_budget_usecs<\/li>\n  <li><strong>Distribution<\/strong> Sikre: IRQ-affinitet, RSS, k\u00f8-mapping<\/li>\n  <li><strong>Overv\u00e5gning<\/strong> gennemf\u00f8re: mpstat, perf, Tracing<\/li>\n<\/ul>\n\n<h2>Oversigt over SoftIRQ'er: S\u00e5dan fungerer kernen<\/h2>\n<p>Efter en hardware-interrupt flytter kernen dele af arbejdet til s\u00e5kaldte <strong>SoftIRQs<\/strong>, s\u00e5 kritiske stier hurtigt bliver frigjort, og behandlingen forbliver planl\u00e6gbar. Is\u00e6r i netv\u00e6rksstien indsamler NAPI-handlere pakker fra NIC-ringene, igangs\u00e6tter protokolbehandlingen og videregiver dataene til <strong>Netv\u00e6rksstakken<\/strong>. Hvis antallet af h\u00e6ndelser stiger, tr\u00e6der tr\u00e5de pr. CPU, s\u00e5som ksoftirqd\/cpuN, til og overtager polling samt efterbehandling. Denne adskillelse forbedrer den samlede gennemstr\u00f8mning, men kan ved overbelastning medf\u00f8re lange SoftIRQ-k\u00f8retider p\u00e5 enkelte <strong>Kerner<\/strong> f\u00f8rer til. Derfor holder jeg tidligt \u00f8je med, om NET_RX- og NET_TX-stier dominerer, og om ksoftirqd synligt sluger CPU-tid. P\u00e5 den m\u00e5de kan jeg se, hvorn\u00e5r SoftIRQ\u2019er bliver en flaskehals, og yderligere <strong>Optimeringer<\/strong> er n\u00f8dvendige.<\/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-analyse-optimierung-5893.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Genkende typiske symptomer p\u00e5 h\u00f8j SoftIRQ-belastning<\/h2>\n<p>En markant SoftIRQ-belastning kan jeg f\u00f8rst se p\u00e5 en konstant h\u00f8j <strong>Kernel-CPU<\/strong> og ksoftirqd-processer, der holder spidsbelastninger i mange sekunder. Samtidig stiger ventetiderne for netv\u00e6rks- og blok-I\/O, hvilket resulterer i langsomme TLS-h\u00e5ndtryk eller tr\u00e6g <strong>API'er<\/strong> udtrykkes. Ofte opst\u00e5r der pakketab, mens netv\u00e6rkskortets ringe l\u00f8ber over, og backlogs vokser. N\u00e5r interrupts er d\u00e5rligt fordelt, lider CPU 0 ofte meget under det, fordi mange IRQ-linjer sammen med det deraf f\u00f8lgende arbejde samles p\u00e5 en <strong>Kerne<\/strong> . Denne binding til \u00e9n kerne \u00f8ger ventetiderne for tjenesterne og mindsker den effektive gennemstr\u00f8mning. Jeg unders\u00f8ger derfor, om m\u00f8nsteret er systematisk, eller om det kun opst\u00e5r <strong>Tinder<\/strong> f\u00f8rer til.<\/p>\n\n<h2>Vigtige m\u00e5lepunkter: S\u00e5dan afl\u00e6ser man \/proc og v\u00e6rkt\u00f8jerne korrekt<\/h2>\n<p>Jeg starter med \/proc\/softirqs, for der kan jeg se, hvor meget der cirka er pr. CPU og type <strong>NET_RX<\/strong>, NET_TX, TIMER eller BLOCK stiger. I \/proc\/net\/softnet_stat gennemg\u00e5r jeg linjerne med fokus p\u00e5 felter, der indikerer overskredne budgetter eller tabte pakker, hvilket ved en konstant stigning tydeligt peger p\u00e5 for korte <strong>Afstemningscyklusser<\/strong> tyder p\u00e5. \/proc\/interrupts afsl\u00f8rer derefter, om hardware-interrupts fordeles uj\u00e6vnt p\u00e5 CPU\u2019erne, og hvilke IRQ\u2019er der er mest aktive. V\u00e6rkt\u00f8jer som mpstat, top eller htop hj\u00e6lper mig med at identificere ksoftirqd\/cpuN og fordelingen af <strong>Softirq-tider<\/strong> vurderes pr. kerne. Om n\u00f8dvendigt viser perf hotspots i stakken, s\u00e5 jeg kan finde handlere og driverveje, der optager meget tid. Den f\u00f8lgende tabel opsummerer de vigtigste m\u00e5lepunkter, indikatorer og typiske <strong>Handlinger<\/strong> sammen.<\/p>\n<table>\n  <thead>\n    <tr>\n      <th>M\u00e5lepunkt<\/th>\n      <th>Vigtigste omr\u00e5der\/indikatorer<\/th>\n      <th>fortolkning<\/th>\n      <th>Handling<\/th>\n    <\/tr>\n  <\/thead>\n  <tbody>\n    <tr>\n      <td>\/proc\/softirqs<\/td>\n      <td>NET_RX, NET_TX, BLOCK pr. <strong>CPU<\/strong><\/td>\n      <td>Uj\u00e6vn belastningsfordeling kan ses<\/td>\n      <td>Juster IRQ-affinitet, aktiver RSS<\/td>\n    <\/tr>\n    <tr>\n      <td>\/proc\/net\/softnet_stat<\/td>\n      <td>Budget-\/drop-t\u00e6ller, tredje <strong>Kolonne<\/strong><\/td>\n      <td>Budgetterne er for sm\u00e5, pakkerne bliver liggende<\/td>\n      <td>For\u00f8g netdev_budget\/usecs, kontroller RPS<\/td>\n    <\/tr>\n    <tr>\n      <td>\/proc\/afbrydelser<\/td>\n      <td>IRQ-linjer pr. <strong>CPU<\/strong>, k\u00f8-kortl\u00e6gning<\/td>\n      <td>For mange IRQ\u2019er p\u00e5 f\u00e5 kerner<\/td>\n      <td>Kontroller irqbalance, indstil smp_affinity<\/td>\n    <\/tr>\n    <tr>\n      <td>mpstat \/ perf<\/td>\n      <td>%soft, hotspots, <strong>Stakke<\/strong><\/td>\n      <td>Dominerende h\u00e5ndtag og kerner er synlige<\/td>\n      <td>Prioriter optimering af drivere og stak<\/td>\n    <\/tr>\n  <\/tbody>\n<\/table>\n\n<h2>\u00c5rsager til og m\u00f8nstre ved h\u00f8j belastning<\/h2>\n<p>Spidser opst\u00e5r ofte p\u00e5 grund af meget h\u00f8je <strong>Gennemstr\u00f8mning<\/strong>, mange parallelle forbindelser eller UDP-bursts, der dominerer NET_RX. Nogle gange indstiller driverne som standard sm\u00e5 batcher, hvilket medf\u00f8rer for mange interrupts og overbelaster ksoftirqd, mens GRO\/LRO forbliver uudnyttet <strong>rester<\/strong>. Ugunstige affiniteter koncentrerer arbejdet p\u00e5 CPU 0, selvom der er flere k\u00f8er til r\u00e5dighed, og RSS kunne lette fordelingen. I virtuelle maskiner belaster vNIC\u2019er v\u00e6rtskernelen, hvilket \u00f8ger SoftIRQ-tiderne i v\u00e6rten p\u00e5 bekostning af g\u00e6sterne <strong>\u00f8ger<\/strong>. Container-overlays l\u00e6gger yderligere pakker p\u00e5 stakken, hvilket f\u00e5r enkle datastr\u00f8mme til pludselig at blive til mere komplekse ruter. F\u00f8rst kombinationen af fordeling, budget og <strong>Batching<\/strong> giver et helhedsbillede.<\/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_softirq_meeting_8593.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>M\u00e5lrettet overv\u00e5gning: G\u00f8r SoftIRQ\u2019er synlige<\/h2>\n<p>For at sikre en holdbar overv\u00e5gning l\u00e6ser jeg regelm\u00e6ssigt <strong>\/proc<\/strong>-gr\u00e6nseflader og knytter dem til host-metrikker som belastning og sched-latenser. Jeg korrelerer stigninger i NET_RX med drop-t\u00e6llere for at afklare, om det kun er gennemstr\u00f8mningen, der stiger, eller om der g\u00e5r pakker tabt undervejs <strong>ophold<\/strong>. mpstat viser mig tidsfordelingen for SoftIRQ\u2019er pr. CPU, mens top\/htop viser de i\u00f8jnefaldende ksoftirqd\/cpuN-tr\u00e5de. Med perf record\/perf top isolerer jeg ressourcekr\u00e6vende processer, for eksempel checksum-offloads, GRO-sammenl\u00e6gning eller <strong>qdisc<\/strong>-Arbejde. eBPF- eller ftrace-baserede sporinger viser handlerens start og slutning, hvilket giver mig mulighed for at vurdere handlerens k\u00f8retid og planl\u00e6gningseffekter. P\u00e5 den m\u00e5de f\u00e5r jeg et klart overblik baseret p\u00e5 m\u00e5linger, tidsforl\u00f8b og <strong>Hotspots<\/strong>.<\/p>\n\n<h2>Tuning med netdev_budget og netdev_budget_usecs<\/h2>\n<p>Hvis NAPI-stien er for kort, \u00f8ger jeg den gradvist <strong>net.core.netdev_budget<\/strong> og net.core.netdev_budget_usecs for at kunne behandle flere pakker pr. polling-cyklus. Her holder jeg \u00f8je med den tredje kolonne i \/proc\/net\/softnet_stat; hvis stigningen aftager, rammer \u00e6ndringerne plet, og latenstiderne bliver <strong>kortere<\/strong>. Jeg \u00f8ger v\u00e6rdierne moderat, for eksempel fra 300 til 600 pakker og fra 2000 til 4000 mikrosekunder, og kontrollerer, om andre opgaver stadig f\u00e5r tilstr\u00e6kkelig CPU-tid. For mange opgaver blokerer scheduleren, hvorfor jeg n\u00f8je overv\u00e5ger belastningsspidser, kontekstskift og r\u00e6kkef\u00f8lgel\u00e6ngder <strong>f\u00f8lg med<\/strong>. Derudover er det en god id\u00e9 at tjekke RPS\/RFS, GRO\/LRO og MTU for at udnytte batching og pakkest\u00f8rrelser optimalt. For at mindske antallet af interrupts tager jeg h\u00f8jde for <a href=\"https:\/\/webhosting.de\/da\/interrupt-coalescing-netvaerksoptimering-serverflux\/\">Sammenl\u00e6gning af afbrydelser<\/a> og justerer de samme finjusteringer med NIC-driverne, hvis denne indstilling er tilg\u00e6ngelig <strong>er<\/strong>.<\/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-softirq-analyse-optimierung-4738.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Optimering af interrupt-fordeling og IRQ-affinitet<\/h2>\n<p>For at undg\u00e5 flaskehalse i en enkelt kerne fordeler jeg IRQ\u2019erne p\u00e5 flere <strong>CPU'er<\/strong>, enten via irqbalance eller med manuelle smp_affinity-masker. Her tager jeg udgangspunkt i de eksisterende NIC-k\u00f8er og aktiverer RSS, s\u00e5 hardwaren fordeler indg\u00e5ende datastr\u00f8mme j\u00e6vnt, og hver kerne f\u00e5r arbejdet lettere <strong>Batches<\/strong> modtager. Jeg s\u00f8rger for ikke at blande styrings-IRQ\u2019er med vigtige dataveje for at bevare cache-lokalitet og planl\u00e6gningsmuligheder. Korrekt indstillede affiniteter mindsker ventetider og reducerer tab, fordi efterbehandling af SoftIRQ\u2019er ikke l\u00e6ngere h\u00e6nger fast p\u00e5 en kerne <strong>rester<\/strong>. Drivere viser ofte tilknytninger mellem k\u00f8er og CPU\u2019er i sysfs; der kontrollerer jeg, om hver k\u00f8 har en passende kerne, og at der ikke opst\u00e5r asymmetrier. Mere indg\u00e5ende orienterer jeg mig efter vejledninger som <a href=\"https:\/\/webhosting.de\/da\/server-irq-affinitet-multicore-netvaerksoptimering-ydelse\/\">IRQ-affinitet<\/a>, for ogs\u00e5 at tage h\u00f8jde for NUMA-aspekter og cache-effekten <strong>tage hensyn til<\/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\/09\/linux_softirq_optimierung_2793.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Praktisk vejledning: Fra symptomer til l\u00f8sning<\/h2>\n<p>F\u00f8rst tjekker jeg symptomerne: ksoftirqd\/cpuN i top, SoftIRQ-andele pr. kerne i <strong>mpstat<\/strong> og markante NET_RX-spidsbelastninger. Derefter indsamler jeg konkrete data fra \/proc\/softirqs, \/proc\/net\/softnet_stat og \/proc\/interrupts for at kortl\u00e6gge dominerende stier og sk\u00e6ve fordelinger. Derefter foretager jeg sm\u00e5 finjusteringer, f\u00f8rst af netdev-budgetterne, efterfulgt af IRQ-affinitet og RSS, hver gang med t\u00e6t overv\u00e5gning <strong>Kontrol<\/strong>. Hvis der stadig er drops, tjekker jeg driverindstillinger, coalescing-indstillinger, offloads og GRO\/LRO-adf\u00e6rd. I VM- eller container-v\u00e6rter vurderer jeg desuden, hvordan vNIC\u2019erne interagerer med den fysiske v\u00e6rtsstack, og hvor <strong>Hotspots<\/strong> virkelig er. Jeg vurderer enhver \u00e6ndring ud fra tidsserier, indtil m\u00e5lev\u00e6rdier og latenstider ligger stabilt p\u00e5 et godt niveau <strong>Land<\/strong>.<\/p>\n\n<h2>Bedste praksis for b\u00e6redygtig ydeevne<\/h2>\n<p>Jeg indf\u00f8rer regelm\u00e6ssig overv\u00e5gning af SoftIRQ-t\u00e6llerne, for kun konstante <strong>Gennemsigtighed<\/strong> forhindrer tilbagefald til flaskehalse. De nyeste kernelversioner er en fordel, fordi NAPI og stakken l\u00f8bende forbedres internt, hvilket skaber reserver til kr\u00e6vende <strong>Belastninger<\/strong> oprette. En afbalanceret fordeling p\u00e5 flere kerner er stadig et krav, ligesom fornuftige budgetter, der henter nok pakker uden at overbelaste scheduleren. For hostingprofiler med meget HTTPS- og API-trafik er det v\u00e6rd at kigge p\u00e5 <a href=\"https:\/\/webhosting.de\/da\/softirq-cpu-hosting-optimering-af-netvaerksgennemstromning-datacenter\/\">SoftIRQ i hosting<\/a>, for det er her, man kan se, hvor meget valget af NIC\u2019er, k\u00f8er og finjustering forbedrer servicekvaliteten. I kapacitetsplanl\u00e6gningen tager jeg h\u00f8jde for CPU-kerner, NIC-funktioner, hukommelse og NUMA-zoner, s\u00e5 der er reserver til r\u00e5dighed, f\u00f8r <strong>Tips<\/strong> indtr\u00e6ffer. P\u00e5 den m\u00e5de forbliver platformen robust og reagerer pr\u00e6cist p\u00e5 s\u00e6sonbestemte eller kampagnedrevne <strong>Trafikspidser<\/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\/09\/linux_softirq_analyse_4839.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>softnet_stat i detaljer: Hvad tallene egentlig betyder<\/h2>\n<p>For at sk\u00e6rpe mine f\u00e6rdigheder m\u00e5lrettet l\u00e6ser jeg <strong>\/proc\/net\/softnet_stat<\/strong> i forl\u00f8bet og fortolk is\u00e6r de f\u00f8rste kolonner. De f\u00f8rste felter t\u00e6ller behandlede og kasserede pakker pr. CPU, som <strong>tredje kolonne<\/strong> peger p\u00e5 tidspres (kort sagt: for lille budget\/tidsramme, NAPI m\u00e5 afbryde). Hvis drops eller tidspresset stiger line\u00e6rt med belastningen, er budgetter eller coalescing de f\u00f8rste h\u00e5ndtag. Ser jeg derimod spidsbelastninger uden en vedvarende stigning, komprimerer bursts blot arbejdet p\u00e5 kort sigt \u2013 s\u00e5 hj\u00e6lper batching (GRO) oftere end store budgetter. Nyere kerner udvider statistikkerne med felter for RPS\/RFS og flow-gr\u00e6nser; stiger disse, fordeler jeg bevidst via RPS eller reducerer RFS, hvis dens lookups bliver dyrere end fordelene. Jeg korrelerer altid t\u00e6llerne med <strong>\/proc\/softirqs<\/strong>: Hvis NET_RX stiger p\u00e5 enkelte kerner samtidig med, at tidspresset i softnet_stat \u00f8ges, fokuserer jeg f\u00f8rst p\u00e5 fordelingen (IRQ\/RSS) og f\u00f8rst i anden omgang p\u00e5 st\u00f8rre budgetter.<\/p>\n\n<h2>RPS\/RFS og XPS: Fuld kontrol over software-styring og k\u00f8optimering<\/h2>\n<p>Hvis der mangler hardware-RSS, eller hvis det ikke er tilstr\u00e6kkeligt, indstiller jeg <strong>RPS<\/strong> (Receive Packet Steering) for at fordele RX-belastningen p\u00e5 flere kerner. Via rps_cpus tildeler jeg RX-k\u00f8erne de kerner, der passer til de aktive arbejdsprocesser, og s\u00e5 vidt muligt <strong>T\u00e6t p\u00e5 NUMA<\/strong> ligger. I mange flows tilf\u00f8jer jeg <strong>RFS<\/strong> (Receive Flow Steering), s\u00e5 indg\u00e5ende pakker ender der, hvor de tilh\u00f8rende sockets behandles \u2013 godt for cache-lokaliteten, s\u00e5 l\u00e6nge flow-tabellerne ikke bliver en flaskehals. P\u00e5 afsendersiden hj\u00e6lper <strong>XPS<\/strong> (Transmit Packet Steering), hvor valget af TX-k\u00f8 tilpasses applikationens CPU-tilknytning. M\u00e5let er, at en str\u00f8m konsekvent skal k\u00f8re gennem den samme RX\/TX-k\u00f8 og den samme kerne, hvilket reducerer latenstiderne og <strong>GRO<\/strong>-Batches bliver st\u00f8rre. Jeg tester altid fordelinger trin for trin: f\u00f8rst aktiverer jeg RPS p\u00e5 nogle f\u00e5 k\u00f8er, m\u00e5ler effekten (drops, %soft, latenstider) og tilf\u00f8jer derefter RFS\/XPS. Hvis kernerne bliver overbelastet af RPS, eller hvis L3-hitraten forringes, reducerer jeg CPU-maskerne igen eller knytter k\u00f8erne t\u00e6ttere til kernerne for de p\u00e5g\u00e6ldende tjenester.<\/p>\n\n<h2>NUMA, CPU-isolering og interaktioner mellem schedulere<\/h2>\n<p>Selv de bedste budgetter og fordelinger nytter ikke meget, hvis adgangen til hukommelsen skal f\u00f8lge lange NUMA-veje. Jeg s\u00f8rger for, at NIC-interrupts, NAPI-efterbehandling og de anmodende processer s\u00e5 vidt muligt foreg\u00e5r inden for samme <strong>NUMA-dom\u00e6ne<\/strong> forbliver. I konfigurationer med dedikerede realtids- eller latenstkerner isolerer jeg disse ved hj\u00e6lp af CPU- og Cgroup-politikker og holder bevidst SoftIRQ-aktiviteter v\u00e6k derfra. <strong>ksoftirqd<\/strong> b\u00f8r ikke ende p\u00e5 isolerede kerner, ellers hober pakkerne sig ubem\u00e6rket op. Omvendt m\u00e5 isolerede kerner ikke st\u00e5 helt uden IRQ-betjening, n\u00e5r de afslutter dataveje \u2013 en klar affinitet og <strong>Reng\u00f8ring<\/strong>-Strategien er afg\u00f8rende. Ved arbejdsbelastninger med strenge SLO\u2019er undg\u00e5r jeg alt for aggressive SCHED_FIFO\/RR-prioriteter, som kunne fortr\u00e6nge NAPI-udf\u00f8relsen. Jeg overv\u00e5ger runk\u00f8-l\u00e6ngder, wakeups og pr\u00e6emptionsrater: Hvis SoftIRQ-tiderne stiger i takt med appens stigende interaktivitet, justerer jeg granularitet og affiniteter i stedet for blot at skrue op for budgetterne generelt.<\/p>\n\n<h2>qdisc, offloads og Busy-Poll: Balance mellem latenstid og gennemstr\u00f8mning<\/h2>\n<p>P\u00e5 Egress-stien koster hver <strong>qdisc<\/strong>-CPU-tid pr. operation. Jeg v\u00e6lger den disciplin, der passer til profilen: fq_codel hj\u00e6lper med at afhj\u00e6lpe bufferbloat og udj\u00e6vner bursts, mens <em>mq<\/em>-varianter af Multi-Queue-NIC\u2019er. Ved ren datagennemstr\u00f8mning p\u00e5 stabile forbindelser kan en lettere qdisc minimere forsinkelsestoppe. P\u00e5 ingress-porten er det en god id\u00e9 at finjustere <strong>GRO\/TSO\/GSO<\/strong>: St\u00f8rre batches s\u00e6nker SoftIRQ-frekvensen, men \u00f8ger i gr\u00e6nsetilf\u00e6lde pakketiden i stakken. Jeg m\u00e5ler, om GRO-flush-intervaller eller hardware-offloads f\u00f8rer til for store aggregeringer, der skader applikationen. For stier, hvor latenstiden er meget kritisk, indstiller jeg <strong>busy_poll<\/strong> og bruger busy_read med m\u00e5de for aktivt at tr\u00e6kke pakker ud af driveren \u2013 dog kun under n\u00f8je overv\u00e5gning, s\u00e5 andre opgaver ikke bliver sultne. Ligeledes indstiller jeg <strong>Sammenl\u00e6gning af afbrydelser<\/strong> V\u00e6r opm\u00e6rksom p\u00e5 pludselige stigninger: At \u00f8ge mikrosekunderne en smule forbedrer gennemstr\u00f8mningen, men for meget forsinker ACK\u2019er og forl\u00e6nger h\u00e5ndtryk. Det er vigtigt at vurdere hver \u00e6ndring separat: Simulerede spidsbelastninger, reelle produktionsspidser og perioder med lav belastning viser ofte forskellige latenstidsprofiler.<\/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-softirq-analyse-1934.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Diagnosetjekliste og sikker tilbagef\u00f8rsel<\/h2>\n<p>Jeg gennemg\u00e5r \u00e6ndringer systematisk ved hj\u00e6lp af en kort tjekliste: 1) Dokumentere symptomer (ksoftirqd, %soft, Drops). 2) Kontroller fordelingen (\/proc\/interrupts, Queue-&gt;CPU, RSS\/RPS-status). 3) Juster budgetterne, effekt i <strong>softnet_stat<\/strong> overv\u00e5ge (tidspresset aftager, drops stagnerer). 4) Finjustere offloads\/coalescing, gennemg\u00e5 qdisc. 5) Kontroller NUMA\/CPU-tilknytninger og cgroups. Hvert trin afsluttes med en tydelig forbedring af m\u00e5lingerne eller med <strong>Rollback<\/strong> til den seneste gode status. Jeg dokumenterer m\u00e5l- og faktiske v\u00e6rdier (latens P95\/P99, %soft pr. kerne, drop-rater, kontekstskift), s\u00e5 senere iterationer ikke foreg\u00e5r i blinde. Hvis flere sm\u00e5 forbedringer ikke f\u00f8rer til en aflastning, afbryder jeg og s\u00f8ger efter strukturelle \u00e5rsager (k\u00f8-flaskehalse, app-blokeringer, p\u00e5virkninger fra lagring). Denne disciplin forhindrer fejlkorrektioner og beskytter mod optimeringsspiraler, der ganske vist \u00f8ger genneml\u00f8bstallene, men forringer interaktiviteten og stabiliteten.<\/p>\n\n<h2>Skille klart mellem gr\u00e6nsetilf\u00e6lde og arbejdsbelastningsprofiler<\/h2>\n<p>Jeg skelner bevidst mellem bulk-overf\u00f8rsel, latenstidsf\u00f8lsomme API\u2019er og burst-trafik <strong>UDP<\/strong>-Trafik. Ved store datam\u00e6ngder anvender jeg batching og coalescing tidligere, s\u00e5 l\u00e6nge der ikke opst\u00e5r pakketab. Ved API-trafik prioriterer jeg j\u00e6vn fordeling, begr\u00e6nsede batches og stabile E2E-forsinkelser, selvom den nominelle maksimale gennemstr\u00f8mning falder en smule. UDP-bursts bek\u00e6mper jeg helst via k\u00f8udvidelse og affiniteter \u2013 for store budgetter \u00f8ger ellers kun head-of-line-blocking. Hvis et milj\u00f8 bruger mange container- eller overlay-hops, indregner jeg ekstra stakarbejde og spreder SoftIRQ-belastningen bredere. Desuden vurderer jeg firewall-\/Conntrack-overhead separat: N\u00e5r tabellerne n\u00e5r deres gr\u00e6nser, stiger SoftIRQ-belastningen uundg\u00e5eligt, uanset hvor god IRQ-fordelingen er. F\u00f8rst n\u00e5r stierne pr. profil er konsekvent slanke, er det umagen v\u00e6rd at finjustere de sidste procenter.<\/p>\n\n<h2>SoftIRQ'er i cloud- og containermilj\u00f8er<\/h2>\n<p>I virtualiserede scenarier flyttes belastningen gennem vSwitches, overlay-netv\u00e6rk og host-stacks, hvorfor jeg b\u00e5de g\u00e6st- og v\u00e6rt-<strong>Metrikker<\/strong> analysere. Lange SoftIRQ-tider i v\u00e6rten bremser containere og VM\u2019er \u00f8jeblikkeligt, selvom g\u00e6stesystemerne tilsyneladende k\u00f8rer problemfrit <strong>arbejde<\/strong>. Jeg unders\u00f8ger derfor offloads og coalescing p\u00e5 det fysiske netv\u00e6rkskort, mens RPS\/RFS i v\u00e6rten fordeler software-stien bedre. For container-workloads ser jeg p\u00e5, om Cgroup-gr\u00e6nserne for CPU og IRQ-efterbehandling er indstillet fornuftigt, s\u00e5 vigtige tjenester ikke havner i <strong>K\u00f8er<\/strong> sultes ihjel. vNIC\u2019er med underst\u00f8ttelse af flere k\u00f8er (Multi-Queue) og RSS forbedrer paralleliteten, forudsat at affiniteterne og k\u00f8-mappingerne er korrekte. Med dette perspektiv holder jeg datastierne korte og stabiliserer <strong>Forsinkelser<\/strong> og p\u00e5lidelig, reproducerbar ydeevne.<\/p>\n\n<h2>Resum\u00e9: S\u00e5dan mestrer du SoftIRQ-analysen med bravur<\/h2>\n<p>Den, der analyserer SoftIRQ-belastningen grundigt, anvender klare m\u00e5lepunkter, unders\u00f8ger fordelingerne og indf\u00f8rer differentierede <strong>Trin<\/strong>. Jeg starter med \/proc\/softirqs og softnet_stat, sammenholder dem med ksoftirqd og mpstat og udleder deraf r\u00e6kkef\u00f8lgen af mine <strong>Foranstaltninger<\/strong>. F\u00f8rst justerer jeg netdev_budget og netdev_budget_usecs, derefter optimerer jeg IRQ-affinitet, RSS samt batching-indstillinger som GRO og offloads. Hver \u00e6ndring er lille, bliver m\u00e5lt og forts\u00e6ttes kun, hvis den har en positiv effekt, indtil tabene forsvinder og <strong>Forsinkelser<\/strong> falder. Denne disciplin forhindrer bivirkninger, bevarer interaktiviteten p\u00e5 CPU\u2019en og opretholder tjenesterne selv under trafikspidser <strong>lydh\u00f8r<\/strong>. P\u00e5 den m\u00e5de forbliver Linux-ydeevnen gennemsigtig, robust og tilpasningsdygtig, uden at skjulte flaskehalse p\u00e5virker <strong>Stabilitet<\/strong> uds\u00e6tte for fare.<\/p>","protected":false},"excerpt":{"rendered":"<p>L\u00e6r, hvordan du systematisk analyserer og optimerer Linux SoftIRQ-udnyttelsen for at \u00f8ge dine serveres Linux-ydeevne gennem m\u00e5lrettet netdev-tuning og bedre fordeling af interrupts.<\/p>","protected":false},"author":1,"featured_media":21340,"comment_status":"","ping_status":"","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"inline_featured_image":false,"footnotes":""},"categories":[676],"tags":[],"class_list":["post-21347","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-server_vm"],"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":"93","_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":"Linux SoftIRQ","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":"21340","footnotes":null,"_links":{"self":[{"href":"https:\/\/webhosting.de\/da\/wp-json\/wp\/v2\/posts\/21347","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=21347"}],"version-history":[{"count":0,"href":"https:\/\/webhosting.de\/da\/wp-json\/wp\/v2\/posts\/21347\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/webhosting.de\/da\/wp-json\/wp\/v2\/media\/21340"}],"wp:attachment":[{"href":"https:\/\/webhosting.de\/da\/wp-json\/wp\/v2\/media?parent=21347"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/webhosting.de\/da\/wp-json\/wp\/v2\/categories?post=21347"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/webhosting.de\/da\/wp-json\/wp\/v2\/tags?post=21347"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}