{"id":19569,"date":"2026-06-01T08:35:01","date_gmt":"2026-06-01T06:35:01","guid":{"rendered":"https:\/\/webhosting.de\/softirq-cpu-hosting-netzwerkdurchsatz-optimierung-datacenter\/"},"modified":"2026-06-01T08:35:01","modified_gmt":"2026-06-01T06:35:01","slug":"softirq-cpu-hosting-optimering-af-netvaerksgennemstromning-datacenter","status":"publish","type":"post","link":"https:\/\/webhosting.de\/da\/softirq-cpu-hosting-netzwerkdurchsatz-optimierung-datacenter\/","title":{"rendered":"softirq cpu-hosting: optimer serverens ydeevne og netv\u00e6rkets gennemstr\u00f8mning"},"content":{"rendered":"<p>Jeg viser, hvordan <strong>softirq cpu<\/strong> sammen med NAPI, IRQ-distribution og k\u00f8-design begr\u00e6nser eller frig\u00f8r netv\u00e6rksgennemstr\u00f8mningen i hosting. Med klare m\u00e5lepunkter, m\u00e5lrettet tuning og rene affiniteter reducerer jeg <strong>Forsinkelser<\/strong> og konsekvent \u00f8ge pps-gennemstr\u00f8mningen p\u00e5 produktive servere.<\/p>\n\n<h2>Centrale punkter<\/h2>\n<p>Disse kerneideer transporterer netv\u00e6rkspakker effektivt via CPU, kerne og NIC - og holder svartiderne p\u00e5 et minimum. <strong>konstant<\/strong> lav.<\/p>\n<ul>\n  <li><strong>NAPI-budget<\/strong> finjustering: Flere pakker pr. afstemning reducerer overhead og udj\u00e6vner <strong>CPU-belastning<\/strong>.<\/li>\n  <li><strong>IRQ-balancering<\/strong> og affinitet: undg\u00e5 hotspots, \u00f8g antallet af cache-hits, <strong>Toppen af ventetiden<\/strong> tryk.<\/li>\n  <li><strong>Multi-k\u00f8<\/strong>, RSS\/RPS\/XPS: paralleliserer flows, opretholder NUMA-tilpasning, <strong>pps<\/strong> rejser sig.<\/li>\n  <li><strong>Afl\u00e6sning<\/strong> Brug bevidst: GRO\/LRO, TSO, evaluere sammensmeltning, <strong>Jitter<\/strong> i udsigt.<\/li>\n  <li><strong>Isolering<\/strong> og Busy Polling: Forudsigelige svartider p\u00e5 dedikerede <strong>Kerner<\/strong>.<\/li>\n<\/ul>\n\n<h2>Grundl\u00e6ggende: Hvad sker der i kernen under netv\u00e6rkstrafik?<\/h2>\n<p>En pakke lander f\u00f8rst i et hardware-interrupt, hvorefter kernen overtager arbejdet i <strong>SoftIRQs<\/strong> og NAPI poll-loops. Jeg s\u00f8rger for, at den hurtige HardIRQ-fase forbliver meget kort, og at den faktiske logik flyttes til den rigtige kontekst, s\u00e5 <strong>CPU-tid<\/strong> ikke g\u00e5r i st\u00e5. Ksoftirqd-tr\u00e5dene tr\u00e6der kun til, hvis direkte behandling ikke er mulig, hvilket hurtigt f\u00f8rer til k\u00f8er under kontinuerlig belastning. Det er netop her, der opst\u00e5r ventetid, hvilket afspejles i \u00f8get TTFB og svingende gennemstr\u00f8mning. Hvis du vil dykke dybere ned, kan du finde praktisk viden om IRQ-behandling i denne artikel om <a href=\"https:\/\/webhosting.de\/da\/optimering-af-server-interrupt-handtering-af-cpu-ydelse-7342\/\">Interrupt-h\u00e5ndtering og CPU-ydelse<\/a>, som jeg bruger til kategoriseringen.<\/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\/06\/serverperformance-netzwerk-4861.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>NAPI, SoftIRQs og ksoftirqd: Kontrol af latenstid i stedet for styring af den<\/h2>\n<p>NAPI reducerer afbrydelsesstorme ved at hente flere pakker pr. k\u00f8rsel inden for et defineret budget og dermed minimere afbrydelsestiden. <strong>Overhead<\/strong> s\u00e6nker. Hvis budgettet er utilstr\u00e6kkeligt, hober pakkerne sig op, ksoftirqd bliver varm og <strong>Forsinkelse<\/strong> stiger m\u00e5lbart. I s\u00e5danne situationer tjekker jeg systematisk \/proc\/softirqs og \/proc\/net\/softnet_stat for at visualisere drops, time_squeeze eller overfyldte k\u00f8er. Derefter \u00f8ger jeg gradvist net.core.netdev_budget eller net.core.netdev_budget_usecs og overv\u00e5ger CPU-belastning, p95\/p99-fordeling og pakketab parallelt. Tricket er at f\u00e5 udf\u00f8rt nok arbejde pr. poll uden at fortr\u00e6nge den interaktive udf\u00f8relse af userland-tr\u00e5de.<\/p>\n\n<h2>IRQ-balancering og -affinitet: undg\u00e5 hotspots, \u00f8g cache-hits<\/h2>\n<p>En enkelt kerne med alle NIC-IRQ'er bliver en flaskehals, fordi den skal betjene afbrydelser, bl\u00f8de IRQ'er og app-tr\u00e5de; jeg distribuerer derfor <strong>IRQ'er<\/strong> m\u00e5lrettet. Irqbalance-tjenesten hj\u00e6lper, men til h\u00f8je pps-hastigheder kortl\u00e6gger jeg eksplicit RX\/TX-k\u00f8er via affinitet til passende <strong>Kerner<\/strong>. P\u00e5 NUMA-systemer binder jeg k\u00f8er til kerner i samme node for at undg\u00e5 fjernadgang til hukommelsen. Applikationstr\u00e5dene k\u00f8rer p\u00e5 n\u00e6rliggende, men separate kerner, hvilket forbedrer cache-lokaliteten og planl\u00e6gningsmulighederne. Denne guide til strategisk distribution giver et godt overblik over <a href=\"https:\/\/webhosting.de\/da\/server-irq-balancering-optimering-af-netvaerkspraestation-datacenter\/\">IRQ-balancering i datacentret<\/a>, som jeg bruger som reference til finjustering.<\/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\/06\/serverperformance3942.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Multi-queue, RSS\/RPS\/XPS: brug af parallelisering korrekt<\/h2>\n<p>Moderne NIC'er kommer med flere RX\/TX-k\u00f8er, som jeg kan styre via <strong>RSS<\/strong> til flows og dermed opn\u00e5 reel parallelitet. Hvis kortet har for f\u00e5 k\u00f8er, bruger jeg RPS\/XPS til at foretage justeringer p\u00e5 softwaresiden for at fordele pakkerne fornuftigt p\u00e5 tv\u00e6rs af flows. <strong>Kerner<\/strong> til at skubbe. Ren hash-distribution er vigtig, s\u00e5 et flow altid forbliver p\u00e5 den samme CPU, og der ikke opst\u00e5r dyre cache-forvridninger. Samtidig holder jeg TX- og RX-stierne t\u00e6t sammen for at undg\u00e5 lock contention og un\u00f8dvendige adgange p\u00e5 tv\u00e6rs af noder. Det \u00f8ger pps-gennemstr\u00f8mningen, uden at en enkelt kerne tr\u00e6kker i bremsen.<\/p>\n\n<h2>CPU-affinitet lige ind i brugerrummet: end-to-end-t\u00e6nkning<\/h2>\n<p>Jeg planl\u00e6gger datastien fra NIC-IRQ via NAPI-k\u00f8er til appens arbejdstr\u00e5de, s\u00e5 pakkerne n\u00e5r frem til deres destination uden un\u00f8dvendige hooks, og <strong>Svartid<\/strong> forbliver konstant. For at opn\u00e5 dette adskiller jeg konsekvent kerner til afbrydelser\/softIRQ'er fra app-kerner og opretter klare <strong>Affinitet<\/strong>-regler. Webservere, reverse proxies og databaser f\u00e5r faste CPU-s\u00e6t, der ligger t\u00e6t p\u00e5 IRQ-kernerne for at holde stierne korte. Derudover s\u00e6tter jeg CPU-guvern\u00f8ren til performance, s\u00e5 clock-\u00e6ndringer ikke skubber jitter ind i p99. Denne konsekvente tildeling g\u00f8r adf\u00e6rden forudsigelig og hj\u00e6lper med at diagnosticere flaskehalse rent.<\/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\/06\/server-performance-optimization-8321.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Offloads, GRO\/LRO, firewall og eBPF: Spar p\u00e5 belastningen uden at flyve i blinde<\/h2>\n<p>Gem checksum offload, TSO og coalescing <strong>CPU-tid<\/strong>, De kan dog \u00e6ndre pakkest\u00f8rrelser, burst-adf\u00e6rd og jitter, hvilket er grunden til, at jeg m\u00e5ler effekterne specifikt. GRO\/LRO bundter frames og reducerer belastningen p\u00e5 stakken, men til realtidskrav beslutter jeg p\u00e5 situationsbasis om <strong>Deaktivering<\/strong> eller begr\u00e6nset brug. Conntrack-tabeller og dybe nftables\/iptables-k\u00e6der koster tid, s\u00e5 jeg rydder op i overfl\u00f8dige regler og forenkler stierne. Hvis det er n\u00f8dvendigt, bruger jeg eBPF (XDP, tc-BPF) til at tr\u00e6ffe tidlige beslutninger p\u00e5 NIC'en og undg\u00e5 dyre stier. Et godt udgangspunkt for at finjustere praksis er denne oversigt over <a href=\"https:\/\/webhosting.de\/da\/interrupt-coalescing-netvaerksoptimering-serverflux\/\">Sammenl\u00e6gning af afbrydelser<\/a>, hvilket jeg tager h\u00f8jde for i forbindelse med f\u00f8lsomme latency-budgetter.<\/p>\n\n<h2>Busy polling og CPU-isolering: Fastl\u00e5sning af svartider<\/h2>\n<p>Til m\u00e5l med h\u00e5rd latenstid bruger jeg busy polling, s\u00e5 userspace-sockets henter pakker endnu tidligere og <strong>Ventetider<\/strong> forkortes. Det \u00f8ger belastningen, men giver mig meget smalle p99-distributioner til API- eller handelsarbejdsbelastninger p\u00e5 dedikerede <strong>Kerner<\/strong>. Derudover isolerer jeg kerner med isolcpus=, nohz_full= og rcu_nocbs=, s\u00e5 timere, RCU og systemtjenester kun k\u00f8rer p\u00e5 husholdnings-CPU'er. Denne adskillelse forhindrer interferens p\u00e5 latency-kernerne og g\u00f8r adf\u00e6rden reproducerbar. Resultatet er en klar k\u00f8replan: dedikerede kerner, tidlig pakkeindsamling, definerede budgetter.<\/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\/06\/softirq_cpu_hosting_4321.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Overv\u00e5gning og fejlfinding: fra symptom til \u00e5rsag<\/h2>\n<p>Jeg starter med pps, throughput og core load, tjekker derefter drops og aktiviteten i <strong>ksoftirqd<\/strong>-tr\u00e5de over tid for at kunne genkende m\u00f8nstre. V\u00e6rkt\u00f8jer som sar, htop, ss, nload og ethtool viser mig, hvorn\u00e5r og hvor der opst\u00e5r overbelastning, og om <strong>Stikord<\/strong> n\u00e5r deres gr\u00e6nser. Fordelinger er vigtige i stedet for gennemsnitsv\u00e6rdier, s\u00e5 aftentoppe, cron-vinduer eller kampagner ikke g\u00e5r tabt. Jeg korrelerer TTFB-peaks med IRQ-distribution, NAPI-budget og offload-indstillinger for at kunne foretage m\u00e5lrettede justeringer. En justeret IRQ-affinitet eller et nyt skr\u00e6ddersyet NAPI-budget er ofte nok til at reducere timeouts m\u00e6rkbart.<\/p>\n\n<h2>Et overblik over indstillingsparametrene<\/h2>\n<p>F\u00f8lgende oversigt hj\u00e6lper mig med at bruge \u00e6ndringer med omtanke og tildele effekter tydeligt, f\u00f8r jeg foretager permanente \u00e6ndringer. <strong>udrulninger<\/strong> plan. Jeg tester hver justering iterativt, m\u00e5ler ventetidsfordelinger og observerer bivirkninger p\u00e5 <strong>CPU<\/strong> og hukommelse. Jeg \u00e6ndrer altid kun \u00e9t punkt pr. testvindue, s\u00e5 \u00e5rsag og virkning forbliver tydelige. Derefter dokumenterer jeg resultaterne og s\u00e6tter t\u00e6rskelv\u00e6rdier for alarmer. P\u00e5 den m\u00e5de opn\u00e5r jeg reproducerbare forbedringer uden at risikere overraskelser i den produktive trafik.<\/p>\n<table>\n  <thead>\n    <tr>\n      <th>Parameter\/Funktion<\/th>\n      <th>Effekt i datastien<\/th>\n      <th>Hvorn\u00e5r skal man rejse\/aktivere<\/th>\n      <th>Risici\/bivirkninger<\/th>\n    <\/tr>\n  <\/thead>\n  <tbody>\n    <tr>\n      <td><strong>net.core.netdev_budget<\/strong><\/td>\n      <td>Flere pakker per NAPI-unders\u00f8gelse<\/td>\n      <td>For dr\u00e5ber i softnet_stat<\/td>\n      <td>L\u00e6ngere afstemninger fortr\u00e6nger brugertr\u00e5de<\/td>\n    <\/tr>\n    <tr>\n      <td><strong>net.core.netdev_budget_usecs<\/strong><\/td>\n      <td>Begr\u00e6ns tidsvinduet pr. afstemning<\/td>\n      <td>For jitter p\u00e5 grund af store bursts<\/td>\n      <td>For lille: flere kontekst\u00e6ndringer<\/td>\n    <\/tr>\n    <tr>\n      <td><strong>RSS\/RPS\/XPS<\/strong><\/td>\n      <td>Fordel flows p\u00e5 tv\u00e6rs af kerner<\/td>\n      <td>For hotspots p\u00e5 en kerne<\/td>\n      <td>Forkerte hashes: cache-forvr\u00e6ngninger<\/td>\n    <\/tr>\n    <tr>\n      <td><strong>IRQ-affinitet<\/strong><\/td>\n      <td>Bind IRQ'er t\u00e6t p\u00e5 kernen<\/td>\n      <td>Med NUMA-Missmatch<\/td>\n      <td>Fejlallokering skaber nye hotspots<\/td>\n    <\/tr>\n    <tr>\n      <td><strong>GRO\/LRO\/TSO<\/strong><\/td>\n      <td>Reducerer antallet af pakker<\/td>\n      <td>Til CPU-flaskehals<\/td>\n      <td>Jitter, st\u00f8rre bursts<\/td>\n    <\/tr>\n    <tr>\n      <td><strong>Optaget polling<\/strong><\/td>\n      <td>Tidlig afhentning af pakker<\/td>\n      <td>Til h\u00e5rde p99-m\u00e5l<\/td>\n      <td>Mere CPU-forbrug<\/td>\n    <\/tr>\n  <\/tbody>\n<\/table>\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\/06\/developer_desk_focus_optimization_3748.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>RX\/TX-ringe og cue-dybde: korrekt dimensionering af buffere<\/h2>\n<p>Selv med korrekt fordelte IRQ'er og passende budgetter kan NIC-ringe, der er for sm\u00e5 eller for store, neds\u00e6tte ydelsen. Jeg tjekker derfor kortets RX\/TX-ringst\u00f8rrelser og tilpasser dem til burst-karakteren og latency-m\u00e5lene. For sm\u00e5 ringe f\u00f8rer til udfald i NIC'en under trafikspidser, hvilket ses som rx_missed_errors eller fifo_errors i driverstatistikken. Ringe, der er for store, skjuler overbelastning, \u00f8ger ventetiden og skaber lange trailing edges i p95\/p99. Jeg leder efter en mellemvej: nok buffer til at absorbere korte udbrud, men ikke s\u00e5 meget, at pakkerne \u201c\u00e6ldes\u201d i k\u00f8erne.<\/p>\n<p>Derudover ser jeg p\u00e5 host-side <strong>tx_k\u00f8_len<\/strong> og den anvendte Qdisc. Med sch_fq eller fq_codel kan jeg udj\u00e6vne burst-adf\u00e6rd og distribuere store TSO-pakker via pacing. Det reducerer microbursts ved switchporten og g\u00f8r latency-kurven mere j\u00e6vn - vigtigt for blandede arbejdsbelastninger, hvor sm\u00e5 RPC'er k\u00f8rer sammen med store uploads. Jeg overv\u00e5ger ethtool-statistikker og sammenholder dem med softnet_stat for at finde ud af, om overbelastningen opst\u00e5r i NIC-ringen, i netdev-backloggen eller i Qdisc.<\/p>\n\n<h2>MTU, jumbo frames og segmentering<\/h2>\n<p>Die <strong>MTU<\/strong> er en klassisk l\u00f8ftestang, som ofte undervurderes. Jumbo frames reducerer antallet af pakker pr. Gbit\/s og reducerer belastningen p\u00e5 CPU'en - men kun hvis stien virkelig er end-to-end jumbo-kompatibel. Jeg validerer derfor systematisk de eksterne stationer, switche og tunneler. S\u00e5 snart der er fragmentering tilbage til 1500 et eller andet sted, er der risiko for MTU-problemer p\u00e5 stien, retransmissioner og un\u00f8dvendige <strong>Jitter<\/strong>. I datacentre med dominerende \u00f8st\/vest-kommunikation kan en homogen 9k-strategi betale sig, mens 1500 ofte er det mere stabile valg til internetvendte arbejdsbelastninger.<\/p>\n<p>Jeg vurderer altid MTU'en i forbindelse med <strong>TSO\/GSO\/GRO<\/strong>Alt for aggressiv bundtning kan f\u00f8re til store bursts i TX, der fylder upstream-buffere og genererer latenstidstoppe. M\u00e5let er en konsekvent vej: fornuftig segmentering ved senderen, tilstr\u00e6kkelige pacing-mekanismer og GRO, der sparer arbejde p\u00e5 modtagersiden uden at modarbejde realtidskrav.<\/p>\n\n<h2>UDP, QUIC og streaming-arbejdsbelastninger: overvej detaljerne<\/h2>\n<p>Ikke al trafik er TCP. <strong>UDP<\/strong>-tunge profiler (DNS, VoIP, QUIC, telemetri) opf\u00f8rer sig forskelligt i RSS\/RPS og GRO. Moderne stakke underst\u00f8tter UDP-GRO\/GSO, som kan reducere belastningen p\u00e5 CPU'en - jeg bruger det selektivt og m\u00e5ler, om risikoen for omorganisering eller jitter stiger. For QUIC\/HTTP3-belastninger er ren flowfordeling afg\u00f8rende: RPS kan hj\u00e6lpe, hvis NIC'en tilbyder for f\u00e5 RSS-k\u00f8er, men m\u00e5 ikke \u201ckaste rundt\u201d med varme cache-str\u00f8mme. P\u00e5 TX-siden indstiller jeg <strong>XPS<\/strong> for at samle transmissionsstier og reducere l\u00e5sekonflikter. I praksis betaler en stille, kerneaffin allokering sig, is\u00e6r med mange mellemstore UDP-str\u00f8mme, hvor hvert cache-hit t\u00e6ller.<\/p>\n\n<h2>Virtualisering og containere: ren integration af host, guest og vhost<\/h2>\n<p>I virtualiserede milj\u00f8er skifter arbejdet mellem host, vhost-tr\u00e5de og g\u00e6ste-IRQ'er. Jeg s\u00f8rger for, at <strong>vhost-net<\/strong>-tr\u00e5de f\u00e5r deres egne kerner og kolliderer ikke med app-arbejdere. Deres affiniteter skal matche de fysiske RX\/TX-k\u00f8er, ellers vil der v\u00e6re un\u00f8dvendig migration p\u00e5 tv\u00e6rs af CPU'er. I g\u00e6sten tjekker jeg virtio-net k\u00f8er, aktiverer multi-queue og ops\u00e6tter RSS\/RPS analogt til bare metal. Hvor latency og pps er i forgrunden <strong>SR-IOV<\/strong> reducere overhead yderligere - foruds\u00e6tningen er en konsistent NUMA-topologi: VF, vCPU og hukommelse h\u00f8rer til p\u00e5 samme node.<\/p>\n<p>I containerstakken for\u00e5rsager overlay-netv\u00e6rk, dybe NAT-k\u00e6der og komplekse CNI-topologier ekstra hop. Til latency-kritiske tjenester foretr\u00e6kker jeg hostNetwork eller magre netv\u00e6rk (macvlan\/ipvlan), udligner NAT-stier og holder <strong>Conntrack<\/strong> s\u00e5 lille som muligt. En konsekvent CPU-strategi er vigtig: IRQ- og NAPI-kerner p\u00e5 v\u00e6rten skal v\u00e6re placeret i n\u00e6rheden af de kerner, som vhost\/container-arbejdere k\u00f8rer p\u00e5 - det er den eneste m\u00e5de at holde datastien kort og forudsigelig p\u00e5.<\/p>\n\n<h2>Planl\u00e6gning, C-states og IRQ-threading<\/h2>\n<p>Fordi ventetid ikke kun er beregningstid, men ogs\u00e5 <strong>Tidspunkt for opv\u00e5gning<\/strong> Jeg minimerer dybe C-states p\u00e5 latency-kernerne. En aggressiv powersave kan koste millisekunder, f\u00f8r en SoftIRQ rent faktisk k\u00f8rer. Jeg s\u00e6tter derfor min lid til performance governors, begr\u00e6nser dybe C-states og holder turboen konsistent for at g\u00f8re frekvensspring forudsigelige. Lige s\u00e5 vigtigt er det <strong>IRQ-tr\u00e5dning<\/strong>Hvor driverne tillader det, flytter jeg arbejdet til IRQ-tr\u00e5de og prioriterer, s\u00e5 RX starter f\u00f8r downstream-arbejde uden helt at fortr\u00e6nge userland. Samspillet mellem skemapolitikker, affiniteter og budgetter er vanskeligt; jeg tester trin for trin, logger p99 og holder \u00f8je med interferens med ksoftirqd, som ellers bliver en hemmelig flaskehals.<\/p>\n\n<h2>Observation i dybden: tracepoints, t\u00e6llere, histos<\/h2>\n<p>Hvis m\u00e5lingerne forbliver vage, g\u00e5r jeg et niveau dybere: Jeg bruger kernel tracepoints omkring <strong>netif_receive_skb<\/strong>, <strong>napi_poll<\/strong> og <strong>net_dev_queue<\/strong>, for at se poll-varigheder, pakkem\u00e6ngder og ventetider som histogrammer. S\u00e5danne fordelinger viser, om 1 % af afstemningerne tager for lang tid, eller om individuelle k\u00f8er er ved at l\u00f8be t\u00f8r. Derudover kan ethtool-<strong>rx\/tx<\/strong>-t\u00e6llere, TCP retransmits, busy poll hits og softnet_stat giver en klar indikation af, hvor pakker g\u00e5r tabt. Jeg bruger drop-analyse til at se, om NIC'en dropper (ringen er fuld), netdev-backloggen kollapser (time_squeeze), eller Qdisc\/firewall'en bliver langsommere. F\u00f8rst n\u00e5r disse brikker i puslespillet passer sammen, justerer jeg ringe, budgetter eller offloads.<\/p>\n\n<h2>Str\u00f8mlin sikkerhed og filtreringsveje<\/h2>\n<p>Komplekse ACL'er, dybe nftables\/iptables-k\u00e6der og brede conntrack-tabeller tilf\u00f8jer konstant latenstid pr. pakke. Jeg konsoliderer regler, arbejder med sets\/maps og flytter generiske drops s\u00e5 langt frem i stien som muligt - ideelt set s\u00e5 tidligt som muligt ved NIC'en (XDP\/clsact), hvis latency er kritisk. Statsl\u00f8se flows, telemetri eller kendte \u201csikre\u201d porte kan bruges p\u00e5 en m\u00e5lrettet m\u00e5de. <strong>uden sporing<\/strong> for at eliminere behovet for dyre opslag. Samtidig holder jeg tilstandstabellerne friske, justerer hashst\u00f8rrelser til belastningstoppe og rydder aggressivt op i for\u00e6ldrel\u00f8se poster. M\u00e5let er en ren, sporbar policy-sti, som ikke kan ses i profilen som en permanent belastning.<\/p>\n\n<h2>Typiske anti-m\u00f8nstre og hvordan jeg undg\u00e5r dem<\/h2>\n<ul>\n  <li><strong>Alle IRQ'er p\u00e5 \u00e9n kerne:<\/strong> f\u00f8rer til overbelastning og hot ksoftirqd. Modgift: m\u00e5lrettede affiniteter pr. cue, NUMA-koh\u00e6rent.<\/li>\n  <li><strong>Blind maksimering af ringe\/budgetter:<\/strong> Skjuler overbelastning, \u00f8ger forsinkelseshalerne. Modgift: \u00f8g gradvist, m\u00e5l fordelinger.<\/li>\n  <li><strong>Forkert konfiguration af flow-hashing:<\/strong> Str\u00f8mmene springer mellem kernerne, cachen g\u00e5r i st\u00e5. Modgift: stabile RSS-n\u00f8gler, RPS\/XPS kun med et klart m\u00e5l.<\/li>\n  <li><strong>App-tr\u00e5de p\u00e5 de samme kerner som SoftIRQs:<\/strong> Interferens og jitter. Modgift: h\u00e5rd adskillelse, nabotildeling.<\/li>\n  <li><strong>Overlays\/NAT uden budget:<\/strong> tilf\u00f8jet til hvert hop. Afhj\u00e6lpning: Str\u00f8mlin stier, v\u00e6rtsnetv\u00e6rk til latente arbejdsbelastninger.<\/li>\n  <li><strong>Str\u00f8mbesparelse p\u00e5 latency-kerner:<\/strong> Dybe C-tilstande bremser reaktionen. Modgift: pr\u00e6stationsregulator, begr\u00e6nsning af C-tilstand.<\/li>\n  <li><strong>Afl\u00e6sning uden m\u00e5ling:<\/strong> TSO\/GRO kan forv\u00e6rre bursts og jitter. Afhj\u00e6lpning: Aktiv\u00e9r arbejdsbelastningsspecifik, overv\u00e5g p99.<\/li>\n<\/ul>\n\n<h2>Praktisk hosting: trin, der virker<\/h2>\n<p>Jeg starter med en ren m\u00e5lefase, s\u00e6tter baseline og holder alle \u00e6ndringer sm\u00e5 i korte tidsvinduer, s\u00e5 jeg kan <strong>\u00c5rsager<\/strong> kan adskilles. Derefter aktiverer jeg irqbalance, kontrollerer den automatiske fordeling og indstiller om n\u00f8dvendigt manuelle affiniteter, indtil ingen <strong>Hotspots<\/strong> er ikke l\u00e6ngere synlige. Derefter s\u00e6tter jeg Multi-Queue, RSS og - om n\u00f8dvendigt - RPS\/XPS op, synkroniseret med NUMA. Jeg binder app-arbejderne til kerner i n\u00e6rheden af deres IRQ-kerner, men uden direkte kollision. Til sidst renser jeg firewall-stier, tjekker conntrack-tabeller og tr\u00e6ffer bevidste beslutninger om offloads baseret p\u00e5 latency-m\u00e5l.<\/p>\n\n<h2>Eksempel p\u00e5 playbook til p99-latenstider<\/h2>\n<p>F\u00f8rst m\u00e5ler jeg p95\/p99 via repr\u00e6sentativ belastning og sikre logfiler fra \/proc\/softirqs og \/proc\/net\/softnet_stat for at <strong>Dr\u00e5ber<\/strong> og time_squeeze er tydeligt synlige. Derefter \u00f8ger jeg netdev_budget eller netdev_budget_usecs trin for trin og holder p99 nede efter hver \u00e6ndring, s\u00e5 jeg kan se \u00e6gte <strong>Tendenser<\/strong> genkende. Parallelt hermed binder jeg IRQ'er til kerner i en NUMA-node og flytter app-arbejdere til passende naboer. Hvis p99 forts\u00e6tter med at hoppe, tester jeg GRO\/LRO-varianter og interrupt coalescing-profiler, hver med en kort m\u00e5lesti. F\u00f8rst n\u00e5r distributionen forbliver stabil, overf\u00f8rer jeg konfigurationen til Ansible-roller eller systemd-dropins.<\/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\/06\/serverraum-performance-1947.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Kort version til administratorer<\/h2>\n<p>Jeg opn\u00e5r den st\u00f8rste indflydelse ved at <strong>SoftIRQs<\/strong>, NAPI-budget, IRQ-affiniteter og app-tr\u00e5de som en sammenh\u00e6ngende datasti. Jeg fordeler netv\u00e6rksarbejde p\u00e5 tv\u00e6rs af kerner, holder NUMA-k\u00f8er sammenh\u00e6ngende og forbinder arbejdere fornuftigt, s\u00e5 <strong>Ruter<\/strong> G\u00f8r det kort. Jeg indstiller offloads bevidst og m\u00e5ler jitter i stedet for blindt at optimere til throughput. Til h\u00e5rde latency-m\u00e5l bruger jeg busy polling og CPU-isolering, mens housekeeping-CPU'er opfanger interferens. Hvis du implementerer disse trin p\u00e5 en disciplineret m\u00e5de, f\u00e5r du konstant throughput, smallere latency-distributioner og et hostingmilj\u00f8, der reagerer forudsigeligt p\u00e5 belastningstoppe.<\/p>","protected":false},"excerpt":{"rendered":"<p>L\u00e6r, hvordan softirq cpu-hosting med optimerede linux-interrupts, NAPI og IRQ-balancering \u00f8ger din netv\u00e6rksgennemstr\u00f8mning og reducerer ventetiden i serverdriften.<\/p>","protected":false},"author":1,"featured_media":19562,"comment_status":"","ping_status":"","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"inline_featured_image":false,"footnotes":""},"categories":[676],"tags":[],"class_list":["post-19569","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":"77","_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":"softirq cpu","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":"19562","footnotes":null,"_links":{"self":[{"href":"https:\/\/webhosting.de\/da\/wp-json\/wp\/v2\/posts\/19569","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=19569"}],"version-history":[{"count":0,"href":"https:\/\/webhosting.de\/da\/wp-json\/wp\/v2\/posts\/19569\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/webhosting.de\/da\/wp-json\/wp\/v2\/media\/19562"}],"wp:attachment":[{"href":"https:\/\/webhosting.de\/da\/wp-json\/wp\/v2\/media?parent=19569"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/webhosting.de\/da\/wp-json\/wp\/v2\/categories?post=19569"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/webhosting.de\/da\/wp-json\/wp\/v2\/tags?post=19569"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}