{"id":19745,"date":"2026-06-06T15:03:33","date_gmt":"2026-06-06T13:03:33","guid":{"rendered":"https:\/\/webhosting.de\/server-irq-affinity-multicore-netzwerkoptimierung-performance\/"},"modified":"2026-06-06T15:03:33","modified_gmt":"2026-06-06T13:03:33","slug":"server-irq-affinitet-multicore-netvaerksoptimering-ydelse","status":"publish","type":"post","link":"https:\/\/webhosting.de\/da\/server-irq-affinity-multicore-netzwerkoptimierung-performance\/","title":{"rendered":"Server IRQ Affinity og multi-core netv\u00e6rksoptimering for maksimal ydelse"},"content":{"rendered":"<p>Jeg optimerer en servers netv\u00e6rksstier ved at <strong>IRQ-affinitet<\/strong> og kortl\u00e6gge RX\/TX-k\u00f8er til kerner for at kontrollere latenstid, genneml\u00f8b og p99-jitter. De, der bruger multi-core CPU'er, orkestrerer konsekvent interrupts, SoftIRQs, NAPI og NUMA p\u00e5 en s\u00e5dan m\u00e5de, at flows forbliver kerne-affine, context switches reduceres, og applikationen reagerer m\u00e5lbart hurtigere.<\/p>\n\n<h2>Centrale punkter<\/h2>\n<ul>\n  <li><strong>IRQ-fordeling<\/strong> bestemmer, hvilke kerner der har hardwareafbrydelser og forhindrer hotspots.<\/li>\n  <li><strong>NUMA-n\u00e6rhed<\/strong> reducerer fjernadgang og s\u00e6nker ventetidsspidser.<\/li>\n  <li><strong>SoftIRQs og NAPI<\/strong> styrer batchbehandling og reducerer belastningen p\u00e5 kernerne.<\/li>\n  <li><strong>RPS\/RFS<\/strong> holder str\u00f8mmen t\u00e6t p\u00e5 de forbrugende tr\u00e5de.<\/li>\n  <li><strong>M\u00e5ling og fastg\u00f8relse<\/strong> g\u00f8r ydelsen mere deterministisk.<\/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\/06\/serverraum-optimierung-4761.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Hvorfor IRQ-affinitet t\u00e6ller i serverdrift<\/h2>\n\n<p>H\u00f8je pakkehastigheder belaster hurtigt de enkelte kerner, hvis alle afbrydelser lander p\u00e5 et par CPU'er, s\u00e5 jeg fordeler belastningen selektivt for at <strong>Hotspots<\/strong> for at undg\u00e5 dette. Jeg tildeler RX\/TX-k\u00f8er til de relevante kerner for at holde datastierne korte og cacherne varme. Det reducerer p95\/p99-latency, fordi jeg undg\u00e5r un\u00f8dvendige migreringer og holder behandlingstrinnene p\u00e5 de samme kerner. Jeg tager h\u00f8jde for den fysiske n\u00e6rhed af NIC, hukommelseskanaler og CPU-sokler, s\u00e5 vejen fra pakken til applikationsarbejderen forbliver konsekvent hurtig. Denne kerneaffinitet skaber m\u00e5lbar stabilitet under trafiktoppe uden at skulle opgradere hardwaren med det samme.<\/p>\n\n<h2>IRQ-balancering vs. fast affinitet<\/h2>\n\n<p>Den almindelige service <strong>irqbalance<\/strong> distribuerer interrupts automatisk, men den kender ikke min applikationslogik, NUMA-m\u00e5l og latency-budgetter. Jeg binder kritiske netv\u00e6rks-IRQ'er til udvalgte kerner, mens st\u00f8jende eller mindre vigtige afbrydelser flyttes til andre kerner. Denne binding harmonerer med pinningen af applikationsprocesserne, s\u00e5 pipelinen pr. flow forbliver konsistent. Med tung trafik undg\u00e5r jeg omfordelinger, der genererer ekstra overhead og sv\u00e6kker cache-effekten. Hvis du vil dykke dybere ned, kan du finde praktiske baggrundsoplysninger i denne vejledning: <a href=\"https:\/\/webhosting.de\/da\/server-irq-balancering-optimering-af-netvaerkspraestation-datacenter\/\">IRQ-balancering i datacentret<\/a>.<\/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\/netzwerkoptimierung_meeting_4827.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>CPU-affinitet, NUMA og den korte datasti<\/h2>\n\n<p>Jeg foretr\u00e6kker at s\u00e6tte applikationsarbejdere og netv\u00e6rks-IRQ'er p\u00e5 den samme <strong>NUMA<\/strong>-noder, s\u00e5 hukommelsesadgange forbliver lokale. Hvis et NIC h\u00e6nger p\u00e5 node 0, s\u00e6tter jeg ogs\u00e5 de tilh\u00f8rende RX-k\u00f8er der og binder de relevante processer til disse kerner. P\u00e5 den m\u00e5de undg\u00e5r jeg dyre fjernhukommelsesadgange, som har stor indflydelse p\u00e5 latenstiden ved h\u00f8je pakkehastigheder. Jeg inkluderer ogs\u00e5 hyper-threading-par, s\u00e5 s\u00f8stertr\u00e5de ikke forstyrrer hinanden. Denne trekant af processpinning, IRQ-affinitet og NUMA-topologi g\u00f8r netv\u00e6rksstierne mere forudsigelige og \u00f8ger gennemstr\u00f8mningen.<\/p>\n\n<h2>Forst\u00e5else af SoftIRQs, NAPI og k\u00f8-design<\/h2>\n\n<p>Efter hardwareafbrydelsen overtager kernen behandlingen i <strong>SoftIRQs<\/strong>, ofte p\u00e5 den samme kerne, som modtog IRQ'en. N\u00e5r belastningen er h\u00f8j, fordeler jeg bevidst SoftIRQ-belastningen for at afhj\u00e6lpe flaskehalse uden at fragmentere datastien un\u00f8digt. Multi-queue NIC'er hj\u00e6lper, fordi jeg kan tildele klart definerede kerner til hver k\u00f8 og dermed opn\u00e5 \u00e6gte parallelisering. Jeg bruger NAPI til at behandle pakker i batches, s\u00e5 der ikke opst\u00e5r afbrydelsesstorme, og CPU-tiden udnyttes effektivt. Denne artikel giver baggrundsviden om denne vej: <a href=\"https:\/\/webhosting.de\/da\/softirq-cpu-hosting-optimering-af-netvaerksgennemstromning-datacenter\/\">SoftIRQ og netv\u00e6rksgennemstr\u00f8mning<\/a>.<\/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\/maxperformance-network-optimization-6742.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>RPS\/RFS og flowlokalitet<\/h2>\n\n<p>Jeg bruger RPS til en bredere distribution af pakkerne og bruger <strong>RFS<\/strong> s\u00e5 flows ender i de forbrugende tr\u00e5de. P\u00e5 den m\u00e5de forbliver cache-adgange effektive, og applikationen nyder godt af ensartede svartider. Jeg harmoniserer hash-strategien for NIC, antallet af k\u00f8er og RPS-CPU-s\u00e6ttene, s\u00e5 ingen kernek\u00f8er overfyldes. Flowaffiniteten er s\u00e6rlig effektiv til mange korte foresp\u00f8rgsler, som dem, der genereres af API'er og mikrotjenester. P\u00e5 den m\u00e5de bygger jeg en pipeline, hvor hvert flow ber\u00f8rer den samme kerne s\u00e5 ofte som muligt og undg\u00e5r un\u00f8dvendige migreringer.<\/p>\n\n<h2>RSS, indirekte tabel og XPS: m\u00e5lrettet kontrol af hashing<\/h2>\n\n<p>For at sikre, at distributionen starter rent p\u00e5 NIC'en, justerer jeg <strong>RSS<\/strong> (Receive Side Scaling) og indirektionstabellen, s\u00e5 RX-k\u00f8erne tildeles n\u00f8jagtigt til de kerner, der senere skal b\u00e6re app-tr\u00e5dene. Jeg s\u00f8rger for, at antallet af k\u00f8er matcher antallet af kerner, der bruges, og at hash-n\u00f8glerne forbliver stabile, s\u00e5 flows ikke vandrer uventet. Hvis hash-algoritmen \u00e6ndres, eller indirektionstabellen overskrives dynamisk, \u00f8del\u00e6gger det ellers flowets lokalitet og fremmer cache-misses.<\/p>\n\n<p>P\u00e5 TX-stien aktiverer jeg desuden <strong>XPS<\/strong> (Transmit Packet Steering), s\u00e5 udg\u00e5ende pakker sendes af den kerne, der behandler programmet. Det holder ogs\u00e5 TX-cachen t\u00e6t p\u00e5 workeren, og vejen fra socket-k\u00f8en til NIC-k\u00f8en forbliver kort. Jeg holder RX- og TX-mappingerne konsistente, dokumenterer dem pr. interface og definerer dem i opstartsscripts, s\u00e5 en genstart ikke sl\u00f8rer arkitekturen.<\/p>\n\n<h2>Interrupt coalescing: afvejning af latenstid mod gennemstr\u00f8mning<\/h2>\n\n<p>Med <strong>Sammensmeltning<\/strong> Jeg opsummerer afbrydelser for at reducere overhead, men er opm\u00e6rksom p\u00e5 min applikations latency-gr\u00e6nser. Til streaming og VoIP har jeg en tendens til at holde intervallerne korte, mens bulkoverf\u00f8rsler godt t\u00e5ler l\u00e6ngere batches. Jeg tester trin for trin, m\u00e5ler p95\/p99 og tjekker drops, retransmissioner og CPU-udnyttelse pr. kerne. F\u00f8rst derefter skriver jeg indstillingerne ned og dokumenterer dem for hver host og NIC. Denne praktiske artikel giver en dybere indsigt i afvejningen: <a href=\"https:\/\/webhosting.de\/da\/interrupt-coalescing-netvaerksoptimering-serverflux\/\">Sammenl\u00e6gning af afbrydelser forklaret<\/a>.<\/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\/tech_office_multi_core_optimierung_4729.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Korrekt dosering af offloads og aggregering<\/h2>\n\n<p>Jeg s\u00e6tter <strong>GRO\/LRO<\/strong> for at reducere CPU-overhead, men tjek, om min arbejdsbyrde har gavn af st\u00f8rre batches. Latency-f\u00f8lsomme API'er reagerer ofte bedre, n\u00e5r GRO er moderat, og LRO er sl\u00e5et fra, fordi store superpakker kan forv\u00e6rre head-of-line-blokeringseffekter. Til masseoverf\u00f8rsler, replikering eller backup bruger jeg GRO\/GSO\/TSO mere aggressivt, s\u00e5 l\u00e6nge modtagersiden forbliver stabil, og CPU-udnyttelsen falder.<\/p>\n\n<p><strong>Kontrolsum offloads<\/strong> og <strong>TSO\/GSO<\/strong> reducere belastningen p\u00e5 CPU'en betydeligt, men jeg s\u00f8rger for, at middleboxe, tunneler eller offload-inkompatibiliteter (f.eks. med visse indkapslinger) fungerer korrekt. Hvis der opst\u00e5r uregelm\u00e6ssigheder, reducerer jeg gradvist de enkelte offloads og m\u00e5ler effekten p\u00e5 throughput, retransmissioner og CPU-tid. M\u00e5let er et s\u00e6t, der forbliver stabilt over hele linjen og forudsigeligt i spidsbelastningsperioder.<\/p>\n\n<h2>CPU-isolering, scheduler og energitilstande<\/h2>\n\n<p>Ved h\u00e5rde latency-budgetter isolerer jeg kerner til netv\u00e6rksstier og app-arbejdere. Med <strong>CPU-isolering<\/strong> og lean housekeeping-strategi forhindrer jeg systemopgaver, Kthreads eller timerinterrupts i at komme ind p\u00e5 de \u201evarme\u201c kerner. Jeg fikser ogs\u00e5 <strong>CPU-guvern\u00f8r<\/strong> til \u201eperformance\u201c og begr\u00e6nse dyb <strong>C-tilstande<\/strong>, hvis disse for\u00e5rsager opv\u00e5gningsforsinkelser. Jeg holder \u00f8je med kernetemperaturerne, da termisk r\u00e5ddenskab ellers kan \u00f8del\u00e6gge enhver finish.<\/p>\n\n<p>Valget af <strong>Planl\u00e6gning af undervisning<\/strong> p\u00e5virker forudsigeligheden. Jeg prioriterer netv\u00e6rksrelaterede tr\u00e5de, men k\u00f8rer dem ikke aggressivt og udelukkende, s\u00e5 de ikke konkurrerer med ksoftirqd om CPU-tid. Jeg tjekker j\u00e6vnligt, om ksoftirqd starter p\u00e5 enkelte kerner - et tydeligt tegn p\u00e5, at SoftIRQ-belastningen er for h\u00f8j eller forkert fordelt.<\/p>\n\n<h2>Optaget polling og stier med lav latenstid<\/h2>\n\n<p>N\u00e5r mikrosekunder t\u00e6ller, indstiller jeg <strong>Optaget polling<\/strong> p\u00e5 en m\u00e5lrettet m\u00e5de. Programmer kan definere polling-vinduer for udvalgte sockets, s\u00e5 de tr\u00e6kker pakker direkte fra NAPI-budgetter uden at vente p\u00e5 afbrydelser. Jeg v\u00e6lger korte poll-intervaller for at undg\u00e5 at br\u00e6nde CPU-tid af og begr\u00e6nser denne teknik til varme stier med konstant trafik. Parallelt hermed tilpasser jeg <strong>netdev-budgetter<\/strong> moderat, s\u00e5 batches er store nok uden at udsulte resten af systemet.<\/p>\n\n<h2>K\u00f8-disciplin og pacing i netv\u00e6rket<\/h2>\n\n<p>Jeg satte den op <strong>qdisc<\/strong> per gr\u00e6nseflade for at matche arbejdsbyrden. Jeg bruger moderne discipliner som fq\/fq_codel til at regulere pacing og k\u00f8-l\u00e6ngder for at udj\u00e6vne bursts og undg\u00e5 bufferbloat. I ops\u00e6tninger med flere k\u00f8er kombinerer jeg dette med <strong>mqprio<\/strong>, s\u00e5 trafikklasser forbliver konsekvent tildelt de korrekte HW-k\u00f8er. Sammen med <strong>BQL<\/strong> (Byte Queue Limits) p\u00e5 driveren reducerer ventetiden under fuld belastning, fordi k\u00f8en ikke vokser ukontrolleret.<\/p>\n\n<p>Det er vigtigt at interagere med <strong>XPS<\/strong> p\u00e5 TX-stien: Jeg mapper send-k\u00f8erne til de kerner, hvor de tilsvarende RX-str\u00f8mme ogs\u00e5 lander. P\u00e5 den m\u00e5de forbliver begge retninger af et flow t\u00e6t p\u00e5 CPU'en, og jeg opn\u00e5r mere stabile svartider med tovejsprotokoller (f.eks. HTTP\/2, gRPC).<\/p>\n\n<h2>Praktisk arbejdsgang under Linux<\/h2>\n\n<p>Jeg starter med en belastningsoptagelse, tjekker CPU-fordelingen i top\/htop, ser p\u00e5 \/proc\/interrupts og \/proc\/softirqs og l\u00e6ser ethtool-statistikker for at genkende flaskehalse og forberede det n\u00e6ste skridt. <strong>Arbejdsgang<\/strong>-trin. Derefter bestemmer jeg IRQ-ID'erne for de relevante NIC-k\u00f8er og indstiller passende CPU-masker, der optager kernerne j\u00e6vnt og tager h\u00f8jde for NUMA. Derefter binder jeg applikationsarbejderne via taskset eller systemd-CPUAffinity til de samme kerner, som ogs\u00e5 betjener de tilh\u00f8rende k\u00f8er. Jeg aktiverer kun RPS\/RFS, hvor det styrker flowlokaliteten, og holder konfigurationen konsistent pr. interface. Til sidst m\u00e5ler jeg throughput, latency og jitter igen, f\u00f8r jeg ruller \u00e6ndringerne ud p\u00e5 tv\u00e6rs af flere hosts.<\/p>\n\n<h2>M\u00e5ling, undg\u00e5 p95\/p99 og regressioner<\/h2>\n\n<p>Jeg stoler ikke p\u00e5 min mavefornemmelse, men m\u00e5ler ventetider, fejlrater og kerneudnyttelse f\u00f8r og efter hver tuningsrunde, s\u00e5 <strong>p99<\/strong> forbliver stabil. Jeg sporer ogs\u00e5 kontekst\u00e6ndringer, migrationshastigheder og belastning pr. softIRQ-type for at identificere skjulte bivirkninger tidligt. Jeg holder testene reproducerbare, bruger de samme datas\u00e6t og faste versioner, s\u00e5 resultaterne forbliver sammenlignelige. Jeg afd\u00e6kker regressioner med krydstjek under spidsbelastning og inaktivitet samt med lange udholdenhedsk\u00f8rsler. Kun n\u00e5r m\u00e5linger, logfiler og programspor stemmer overens, erkl\u00e6rer jeg konfigurationen som den nye baseline-status.<\/p>\n\n<h2>Virtualisering, containere og SR-IOV<\/h2>\n\n<p>I virtualiserede milj\u00f8er sikrer jeg, at <strong>vCPU'er<\/strong>, VM'ens hukommelse og vNIC'er er placeret p\u00e5 den samme NUMA-node, som det tilh\u00f8rende fysiske NIC ender p\u00e5. Hvor det er muligt, bruger jeg <strong>SR-IOV<\/strong>, s\u00e5 datastien er kort, og IRQ'erne kan bindes direkte til g\u00e6stekernerne. Jeg knytter vCPU'erne i de kritiske VM'er til dedikerede v\u00e6rtskerner og s\u00f8rger for, at v\u00e6rts-IRQ'er og g\u00e6ste-IRQ'er ikke overlapper hinanden. I containerops\u00e6tninger indstiller jeg <strong>cpusets<\/strong> og \u201egaranterede\u201c QoS-klasser, s\u00e5 worker-containere og deres netv\u00e6rks-IRQ'er f\u00e5r CPU-tid p\u00e5 en forudsigelig m\u00e5de.<\/p>\n\n<p>Jeg tjekker, om irqbalance skal have f\u00f8ringen i g\u00e6sten eller p\u00e5 v\u00e6rten - ellers giver dobbelt \u201eautomatisk\u201c sl\u00f8ring. Med virtio indstiller jeg flere k\u00f8er og mapper dem rent til vCPU'er for at muligg\u00f8re parallelt arbejde. Hvis vhost-net bruger individuelle host-kerner, omfordeler jeg backends og holder vhost-tr\u00e5de NUMA-t\u00e6t p\u00e5 det fysiske NIC.<\/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\/servernetzwerkoptmierung-9473.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Fejlfinding: genkend hurtigt m\u00f8nstre<\/h2>\n\n<ul>\n  <li><strong>Kernerne er m\u00e6ttede, ksoftirqd er aktiv:<\/strong> S\u00e6t RX-k\u00f8erne t\u00e6ttere sammen, tjek antallet af k\u00f8er, juster RPS\/RFS eller \u00f8g coalescingen en smule.<\/li>\n  <li><strong>Uj\u00e6vn p99-jitter:<\/strong> Tjek NUMA-drift, verificer C-states\/governor, juster offloads og GRO-st\u00f8rrelser trin for trin.<\/li>\n  <li><strong>Mange genudsendelser\/udfald:<\/strong> Tjek RX\/TX-ringst\u00f8rrelser, qdisc og BQL, tjek indirekte tabel og XPS for konsistens.<\/li>\n  <li><strong>Uj\u00e6vnt fordelte str\u00f8mme:<\/strong> Afbalancer RSS-hash og indirekte tabel, overvej hot flow pinning, hold hash seed stabilt.<\/li>\n  <li><strong>Kun VM-problem:<\/strong> Placer vhost\/virtio-backends t\u00e6t p\u00e5 NUMA, evaluer SR-IOV, adskill IRQ'er mellem host og guest.<\/li>\n<\/ul>\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\/entwicklerschreibtisch_4312.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Inkluder applikationer og databaser<\/h2>\n\n<p>En ren netv\u00e6rkssti er ikke til megen nytte, hvis app-servere eller databaser ikke arbejder parallelt, hvilket er grunden til, at jeg opsatte <strong>Arbejder<\/strong>-antal, tr\u00e5dpuljer og forbindelsesgr\u00e6nser til de tilg\u00e6ngelige kerner. Jeg knytter NGINX- eller HAProxy-arbejdere til de relevante kerner, s\u00e5 de matcher RX-k\u00f8erne. Jeg skalerer PHP-FPM, Node.js, Java eller Go, s\u00e5 de favoriserer det lokale NUMA-dom\u00e6ne og bruger flere instanser, hvis det er n\u00f8dvendigt. Jeg integrerer cacher som Redis eller Memcached t\u00e6t p\u00e5 CPU'en og er opm\u00e6rksom p\u00e5 deres egne netv\u00e6rks- og tr\u00e5dparametre. Kun samspillet mellem IRQ-affinitet, proces-pinning og app-skalering giver det m\u00e6rkbare l\u00f8ft i latency og throughput.<\/p>\n\n<h2>Hosting-scenarier med store fordele<\/h2>\n\n<p>Jeg investerer prim\u00e6rt i deep tuning, n\u00e5r API'er genererer mange korte anmodninger, eller n\u00e5r <strong>I realtid<\/strong>-kommunikation som VoIP og chats kr\u00e6ver lave jitter-v\u00e6rdier. E-handelsops\u00e6tninger med spidsbelastninger har gavn af det, fordi checkout-flowet er f\u00f8lsomt over for latenstid. Multi-tenant hosts med h\u00f8j t\u00e6thed har fordel af, at dedikerede kerner pr. k\u00f8 reducerer naboeffekter. Streamingtjenester kan ogs\u00e5 opn\u00e5 mere gennemstr\u00f8mning pr. euro uden straks at k\u00f8be ny hardware. Omkostningerne kan beregnes, s\u00e5 l\u00e6nge jeg holder \u00e6ndringerne m\u00e5lbare og udruller dem pr\u00e6cist.<\/p>\n\n<h2>Hurtig referencetabel: Kerner, k\u00f8er, v\u00e6rkt\u00f8jer<\/h2>\n\n<p>Jeg bruger f\u00f8lgende <strong>Bord<\/strong> som en p\u00e5mindelse, n\u00e5r jeg s\u00e6tter nye hosts op eller rekalibrerer eksisterende ops\u00e6tninger. Den viser typiske m\u00e5l, passende foranstaltninger, almindelige Linux-v\u00e6rkt\u00f8jer og den tilsigtede effekt p\u00e5 latency og throughput. Jeg bruger den ikke dogmatisk, men som udgangspunkt for en r\u00e6kke m\u00e5linger med reel trafik. Hvis NIC-arkitekturen eller NUMA-topologien varierer, tilpasser jeg kernevalget. Det er fortsat vigtigt at opbevare dokumentationen for hver host og at holde \u00e6ndringer sporbare.<\/p>\n\n<table>\n  <thead>\n    <tr>\n      <th>M\u00e5l<\/th>\n      <th>M\u00e5l<\/th>\n      <th>Linux-v\u00e6rkt\u00f8j\/placering<\/th>\n      <th>Forventet effekt<\/th>\n    <\/tr>\n  <\/thead>\n  <tbody>\n    <tr>\n      <td>Fordel IRQ-belastning<\/td>\n      <td>Bind signaler til kerner<\/td>\n      <td>\/proc\/irq\/*\/smp_affinity<\/td>\n      <td>F\u00e6rre hotspots, mere konstant latenstid<\/td>\n    <\/tr>\n    <tr>\n      <td>\u00d8g flowets lokalitet<\/td>\n      <td>Indstil RPS\/RFS CPU-s\u00e6t<\/td>\n      <td>\/sys\/class\/net\/*\/queues\/*\/rps_cpus<\/td>\n      <td>F\u00e6rre migreringer, bedre cacher<\/td>\n    <\/tr>\n    <tr>\n      <td>Kontroller batch-behandling<\/td>\n      <td>Finjuster NAPI\/sammensmeltning<\/td>\n      <td>ethtool -C \/ driverens standardindstillinger<\/td>\n      <td>Lavere overhead, kontrolleret jitter<\/td>\n    <\/tr>\n    <tr>\n      <td>Par app og IRQ<\/td>\n      <td>Pin-arbejder<\/td>\n      <td>taskset, systemd CPUAffinity<\/td>\n      <td>Kortere vej, lavere p99<\/td>\n    <\/tr>\n    <tr>\n      <td>Undg\u00e5 NUMA<\/td>\n      <td>Samlokaliser enheder og kerner<\/td>\n      <td>numactl, lscpu, lspci -vv<\/td>\n      <td>Mindre fjernadgang, mere gennemstr\u00f8mning<\/td>\n    <\/tr>\n  <\/tbody>\n<\/table>\n\n<h2>Bedste praksis, der virker p\u00e5 lang sigt<\/h2>\n\n<p>Jeg \u00e6ndrer kun et kontrolh\u00e5ndtag pr. testrunde, dokumenterer m\u00e5lingerne og gemmer resultaterne. <strong>Dokumentation<\/strong> i v\u00e6rtens repo. Jeg holder konfigurationerne konsistente ved klart at beskrive k\u00f8-til-kerne-mappinger og bruge scripts til replikering. Jeg overv\u00e5ger logfiler for drops, retransmissioner og timeouts og korrelerer dem med kernemetrikker. Jeg inkluderer hypervisor- og lagringsniveauet i analysen, s\u00e5 der ikke er nogen skyggeflaskehalse tilbage. Jeg har rollbacks klar, hvis test viser negative effekter, eller arbejdsbelastningen \u00e6ndrer sig.<\/p>\n\n<h2>Kort opsummeret<\/h2>\n\n<p>Jeg opn\u00e5r maksimal netv\u00e6rksydelse ved at bruge interrupts, <strong>Stikord<\/strong> og arbejdere og holder dermed datastien pr. flow stabil. IRQ Affinity fordeler hardwarebelastningen fornuftigt, mens SoftIRQs, NAPI og RPS\/RFS g\u00f8r behandlingen effektiv. NUMA-n\u00e6rhed beskytter mod undg\u00e5elige hukommelsesomveje og reducerer jitter. Trin-for-trin-tuning med reproducerbare m\u00e5linger forhindrer fejlkonfigurationer og viser reelle fremskridt. Hvis du t\u00e6nker p\u00e5 disse byggesten sammen, kan du trygt udnytte mulighederne i moderne multi-core servere til latency-kritiske tjenester.<\/p>","protected":false},"excerpt":{"rendered":"<p>Opdag, hvordan Server IRQ Affinity og multi-core netv\u00e6rksoptimering accelererer din pakkebehandling og udnytter multicore-netv\u00e6rk maksimalt i hosting.<\/p>","protected":false},"author":1,"featured_media":19738,"comment_status":"","ping_status":"","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"inline_featured_image":false,"footnotes":""},"categories":[676],"tags":[],"class_list":["post-19745","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":"101","_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":"IRQ Affinity","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":"19738","footnotes":null,"_links":{"self":[{"href":"https:\/\/webhosting.de\/da\/wp-json\/wp\/v2\/posts\/19745","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=19745"}],"version-history":[{"count":0,"href":"https:\/\/webhosting.de\/da\/wp-json\/wp\/v2\/posts\/19745\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/webhosting.de\/da\/wp-json\/wp\/v2\/media\/19738"}],"wp:attachment":[{"href":"https:\/\/webhosting.de\/da\/wp-json\/wp\/v2\/media?parent=19745"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/webhosting.de\/da\/wp-json\/wp\/v2\/categories?post=19745"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/webhosting.de\/da\/wp-json\/wp\/v2\/tags?post=19745"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}