{"id":19369,"date":"2026-05-15T11:51:18","date_gmt":"2026-05-15T09:51:18","guid":{"rendered":"https:\/\/webhosting.de\/server-irq-balancing-netzwerk-performance-optimierung-datacenter\/"},"modified":"2026-05-15T11:51:18","modified_gmt":"2026-05-15T09:51:18","slug":"server-irq-balancering-optimering-af-netvaerkspraestation-datacenter","status":"publish","type":"post","link":"https:\/\/webhosting.de\/da\/server-irq-balancing-netzwerk-performance-optimierung-datacenter\/","title":{"rendered":"Server-IRQ-balancering og netv\u00e6rksydelse til hosting med h\u00f8j belastning"},"content":{"rendered":"<p>H\u00f8j netv\u00e6rksbelastning bestemmes af den effektive behandling af <strong>Server-IRQ<\/strong> signaler: Hvis du fordeler interrupts klogt p\u00e5 tv\u00e6rs af CPU-kerner, reducerer du latency og forhindrer drops. I denne vejledning vil jeg vise dig, hvordan du kombinerer IRQ-balancering, RSS\/RPS og CPU-affinitet p\u00e5 en praktisk m\u00e5de for at g\u00f8re hosting med h\u00f8j belastning b\u00e6redygtig. <strong>performant<\/strong> til at fungere.<\/p>\n\n<h2>Centrale punkter<\/h2>\n\n<ul>\n  <li><strong>IRQ-fordeling<\/strong> forhindrer hotspots p\u00e5 individuelle CPU-kerner.<\/li>\n  <li><strong>Multi-k\u00f8<\/strong> plus RSS\/RPS paralleliserer pakkebehandlingen.<\/li>\n  <li><strong>NUMA-opm\u00e6rksomhed<\/strong> reducerer adgang og ventetid p\u00e5 tv\u00e6rs af noder.<\/li>\n  <li><strong>CPU-guvern\u00f8r<\/strong> og thread pinning udj\u00e6vner svartiderne.<\/li>\n  <li><strong>Overv\u00e5gning<\/strong> Kontrollerer pps, latency, drops og kerneudnyttelse.<\/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\/05\/serverraum-hosting-0382.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>IRQ'er kort forklaret: Hvorfor de styrer netv\u00e6rksbelastningen<\/h2>\n\n<p>For hver indg\u00e5ende pakke rapporterer netv\u00e6rkskortet via <strong>IRQ<\/strong>, at der er arbejde i vente, ellers ville kernen v\u00e6re n\u00f8dt til at sp\u00f8rge aktivt. Hvis opgaven forbliver p\u00e5 en kerne, \u00f8ges dens udnyttelse, mens andre kerner <strong>Ubrugt<\/strong> forbliver. Det er pr\u00e6cis p\u00e5 dette tidspunkt, at ventetiden vokser, RX-ringbufferne fyldes op, og driverne begynder at kassere pakker. Jeg fordeler interrupts p\u00e5 tv\u00e6rs af passende kerner for at holde pakkebehandlingen j\u00e6vn og forudsigelig. Det afhj\u00e6lper flaskehalse, udj\u00e6vner svartider og holder pakketab p\u00e5 et minimum.<\/p>\n\n<h2>IRQ-balancering og CPU-affinitet under Linux<\/h2>\n\n<p>Tjenesten <strong>irqbalance<\/strong> distribuerer afbrydelser dynamisk, analyserer belastning og skifter affiniteter automatisk over tid. For ekstreme belastningsprofiler definerer jeg affiniteter manuelt via <code>\/proc\/irq\/\/smp_affinity<\/code> og binde signaler specifikt til kerner af samme <strong>NUMA<\/strong>-knudepunkter. Denne kombination af automatik og finjustering hj\u00e6lper mig med at behandle b\u00e5de grundbelastninger og spidsbelastninger rent. En dybdeg\u00e5ende introduktion til <a href=\"https:\/\/webhosting.de\/da\/optimering-af-server-interrupt-handtering-af-cpu-ydelse-7342\/\">Interrupt-h\u00e5ndtering og CPU-optimering<\/a> Jeg bruger dem til at hj\u00e6lpe mig med min planl\u00e6gning. Det er stadig vigtigt: Jeg forbinder konsekvent hardwaretopologi, IRQ-fordeling og programtr\u00e5de med hinanden.<\/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\/05\/server_irq_balance_performance_4821.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Praktisk brug af NIC'er med flere k\u00f8er, RSS og RPS<\/h2>\n\n<p>Moderne NIC'er har flere RX\/TX-k\u00f8er, og hver k\u00f8 udl\u00f8ser sin egen <strong>IRQ'er<\/strong>, og Receive Side Scaling (RSS) distribuerer flows til kerner. Hvis der ikke er nok hardwarek\u00f8er, tilf\u00f8jer jeg Receive Packet Steering (RPS) og Transmit Packet Steering (XPS) til kernen for yderligere <strong>Parallelisme<\/strong>. Med <code>ethtool -L ethX kombineret N<\/code> Jeg justerer k\u00f8-nummeret til kernenummeret p\u00e5 den tilknyttede NUMA-node. Jeg tjekker med <code>ethtool -S<\/code> og <code>nstat<\/code>, om der forekommer drops, busy polls eller h\u00f8je pps-peaks. Til finere belastningsudj\u00e6vning bruger jeg ogs\u00e5 <a href=\"https:\/\/webhosting.de\/da\/interrupt-coalescing-netvaerksoptimering-serverflux\/\">Sammenl\u00e6gning af afbrydelser<\/a> i planl\u00e6gningen, s\u00e5 NIC'et ikke genererer for mange individuelle IRQ'er.<\/p>\n\n<p>F\u00f8lgende tabel viser centrale komponenter og typiske kommandoer, som jeg bruger til en sammenh\u00e6ngende ops\u00e6tning:<\/p>\n\n<table>\n  <thead>\n    <tr>\n      <th>Byggeklods<\/th>\n      <th>M\u00e5l<\/th>\n      <th>Eksempel<\/th>\n      <th>Hint<\/th>\n    <\/tr>\n  <\/thead>\n  <tbody>\n    <tr>\n      <td><strong>irqbalance<\/strong><\/td>\n      <td>Automatisk distribution<\/td>\n      <td><code>systemctl enable --now irqbalance<\/code><\/td>\n      <td>Udgangspunkt for blandede arbejdsbelastninger<\/td>\n    <\/tr>\n    <tr>\n      <td><strong>Affinitet<\/strong><\/td>\n      <td>L\u00f8ser problemer med fastg\u00f8relse<\/td>\n      <td><code>echo mask &gt; \/proc\/irq\/XX\/smp_affinity<\/code><\/td>\n      <td>Overhold NUMA-tildeling<\/td>\n    <\/tr>\n    <tr>\n      <td><strong>Stikord<\/strong><\/td>\n      <td>Mere parallelitet<\/td>\n      <td><code>ethtool -L ethX kombineret N<\/code><\/td>\n      <td>Match til node-kerner<\/td>\n    <\/tr>\n    <tr>\n      <td><strong>RSS\/RPS<\/strong><\/td>\n      <td>Fordeling af flow<\/td>\n      <td><code>sysfs: rps_cpus\/rps_flow_cnt<\/code><\/td>\n      <td>Nyttigt til et lille antal NIC-k\u00f8er<\/td>\n    <\/tr>\n    <tr>\n      <td><strong>XPS<\/strong><\/td>\n      <td>Bestilte TX-stikerner<\/td>\n      <td><code>sysfs: xps_cpus<\/code><\/td>\n      <td>Undg\u00e5r cache-thrash<\/td>\n    <\/tr>\n  <\/tbody>\n<\/table>\n\n<h2>Fornuftig brug af automatisk IRQ-balancering<\/h2>\n\n<p>For blandede hosting-servere er det ofte tilstr\u00e6kkeligt at aktivere <strong>irqbalance<\/strong>, fordi d\u00e6monen hele tiden registrerer belastningsskift. Jeg tjekker status via <code>systemctl status irqbalance<\/code> og tag et kig p\u00e5 <code>\/proc\/afbrydelser<\/code>, for at se fordelingen pr. k\u00f8 og kerne. Hvis ventetiden stiger i spidsbelastninger, definerer jeg testkerner, der prim\u00e6rt behandler afbrydelser, og sammenligner m\u00e5lte v\u00e6rdier f\u00f8r og efter \u00e6ndringen. Jeg beholder konfigurationen <strong>simpel<\/strong>, s\u00e5 senere revisioner og rollbacks er hurtige. F\u00f8rst n\u00e5r m\u00f8nstrene er tydelige, g\u00e5r jeg dybere ind i pinning.<\/p>\n\n<h2>Manuel CPU-affinitet for maksimal kontrol<\/h2>\n\n<p>Ved meget h\u00f8je pps-hastigheder s\u00e6tter jeg RX-k\u00f8er til udvalgte kerner i samme <strong>NUMA<\/strong>-noder og adskiller bevidst applikationstr\u00e5de fra dem. Jeg isolerer individuelle kerner for afbrydelser, k\u00f8rer workers p\u00e5 nabokerner og er meget opm\u00e6rksom p\u00e5 cache-lokalitet. P\u00e5 den m\u00e5de reducerer jeg adgangen p\u00e5 tv\u00e6rs af noder og minimerer dyre kontekstskift i den varme vej. For at f\u00e5 reproducerbare resultater dokumenterer jeg tydeligt IRQ-maskerne, k\u00f8tildelingen og tjenesternes tr\u00e5daffinitet. Denne klarhed holder pakkens runtimes <strong>konstant<\/strong> og reducerer afvigelser.<\/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\/05\/server-performance-optimization-9876.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Ren koordinering af CPU-optimering og applikationer<\/h2>\n\n<p>Jeg indstillede <strong>CPU-guvern\u00f8r<\/strong> ofte sat til \u201eperformance\u201c, fordi clock-\u00e6ndringer \u00f8ger latency-springene. Jeg binder kritiske processer som Nginx, HAProxy eller databaser til kerner, der ligger t\u00e6t p\u00e5 IRQ-kernerne, eller jeg adskiller dem bevidst, hvis cache-profilen kr\u00e6ver det. Det er stadig vigtigt at begr\u00e6nse kontekst\u00e6ndringer og holde kernen opdateret, s\u00e5 optimeringer i netstakken tr\u00e6der i kraft. Jeg m\u00e5ler effekten af hver \u00e6ndring i stedet for at g\u00f8re antagelser og tilpasser trin for trin. Det resulterer i en ops\u00e6tning, der fungerer under belastning <strong>forudsigelig<\/strong> reagerer.<\/p>\n\n<h2>Ops\u00e6t overv\u00e5gning og m\u00e5ling korrekt<\/h2>\n\n<p>Uden m\u00e5lte v\u00e6rdier forbliver tuning en g\u00e6tteleg, s\u00e5 jeg starter med <strong>sar<\/strong>, <strong>mpstat<\/strong>, <strong>vmstat<\/strong>, <strong>nstat<\/strong>, <strong>ss<\/strong> og <code>ethtool -S<\/code>. Til strukturerede belastningstests bruger jeg <code>iperf3<\/code> og ser p\u00e5 throughput, pps, latency, retransmissioner og kerneudnyttelse. Jeg registrerer langsigtede tendenser ved hj\u00e6lp af standardoverv\u00e5gningssystemer for at kunne genkende m\u00f8nstre som f.eks. aftenspidser, backup-vinduer eller kampagner. Hvis du vil forst\u00e5 datastien holistisk, har du gavn af et overblik over <a href=\"https:\/\/webhosting.de\/da\/server-pakkebehandling-pipeline-hosting-netvaerk-router\/\">Pipeline til pakkebehandling<\/a> fra NIC-IRQ'en til brugeromr\u00e5det. Kun kombinationen af disse signaler viser, om IRQ-balancering og -affinitet har opn\u00e5et den \u00f8nskede effekt. <strong>Effekt<\/strong> bringe.<\/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\/05\/server_irq_balancing_4356.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Forst\u00e5else af NAPI, Softirqs og ksoftirqd<\/h2>\n<p>For at h\u00e5ndtere latenstidstoppe med h\u00f8je pps-belastninger tager jeg h\u00f8jde for <strong>NAPI<\/strong>-mekanik og samspillet mellem h\u00e5rde IRQ'er og bl\u00f8de IRQ'er. Efter den f\u00f8rste hardware-IRQ henter NAPI flere pakker fra RX-k\u00f8en i poll-tilstand for at undg\u00e5 IRQ-storme. Hvis bl\u00f8de IRQ'er ikke behandles hurtigt, flyttes de til <code>ksoftirqd\/N<\/code> Tr\u00e5de, der kun k\u00f8rer med normal prioritet - en klassisk \u00e5rsag til stigende tail latencies. Jeg observerer <code>\/proc\/softirqs<\/code> og <code>\/proc\/net\/softnet_stat<\/code>; en h\u00f8j \u201e<code>time_squeeze<\/code>\u201c-v\u00e6rdi eller -fald indikerer, at budgettet er for stramt. Med <code>sysctl -w net.core.netdev_budget_usecs=8000<\/code> og <code>sysctl -w net.core.netdev_budget=600<\/code> Jeg \u00f8ger behandlingstiden pr. NIC-poll og pakkebudgettet som en test. Vigtigt: Jeg \u00f8ger v\u00e6rdierne gradvist, m\u00e5ler og kontrollerer, om der opst\u00e5r CPU-jitter eller interferens med applikationstr\u00e5de.<\/p>\n\n<h2>Finjuster RSS-hash og indirekte tabel<\/h2>\n<p>RSS distribuerer flows til k\u00f8er via indirektionstabellen (RETA). Jeg verificerer hash-n\u00f8glen og tabellen med <code>ethtool -n ethX rx-flow-hash tcp4<\/code> og indstil fordelingen symmetrisk, hvis det er n\u00f8dvendigt. Med <code>ethtool -X ethX equal N<\/code> eller specifikt pr. post (<code>ethtool -X ethX hkey ... hfunc toeplitz indir 0:1 1:3 ...<\/code>), matcher jeg opgaverne med de foretrukne kerner i en NUMA-node. M\u00e5let er at <strong>Flowets kl\u00e6brighed<\/strong>Et flow forbliver p\u00e5 den samme kerne, s\u00e5 cache-lokalitet og fastholdelse af l\u00e5se i stakken forbliver minimal. I milj\u00f8er med mange korte UDP-str\u00f8mme \u00f8ger jeg <code>rps_flow_cnt<\/code> per RX-k\u00f8, s\u00e5 softwaredistributionen har nok buckets og ikke skaber nogen hotspots. Jeg husker, at symmetriske hashes hj\u00e6lper med ECMP-topologier, men i serversammenh\u00e6ng er kernebalancen det, der t\u00e6ller mest.<\/p>\n\n<h2>V\u00e6lg aflastninger, GRO\/LRO og ringst\u00f8rrelser med omtanke<\/h2>\n<p>Hardware-offloads reducerer belastningen p\u00e5 CPU'en, men kan \u00e6ndre latency-profiler. Jeg tjekker med <code>ethtool -k ethX<\/code>, om <strong>TSO\/GSO\/UDP_SEG<\/strong> p\u00e5 TX og <strong>GRO\/LRO<\/strong> er aktive p\u00e5 RX. GRO bundter pakker i kernen og er n\u00e6sten altid nyttigt for gennemstr\u00f8mningen; LRO kan v\u00e6re problematisk i routing- eller filtreringsops\u00e6tninger og er bedre at lade v\u00e6re der. For latency-kritiske API'er tester jeg mindre GRO-aggregering (eller sl\u00e5r den midlertidigt fra), hvis p99-latency dominerer. Jeg justerer ogs\u00e5 ringst\u00f8rrelser via <code>ethtool -G ethX rx 1024 tx 1024<\/code>: St\u00f8rre ringe opfanger bursts, men \u00f8ger ventetiden ved overbelastning; ringe, der er for sm\u00e5, f\u00f8rer til <code>rx_missed_errors<\/code>. Jeg stoler p\u00e5 m\u00e5lte v\u00e6rdier fra <code>ethtool -S<\/code> (f.eks. <code>rx_no_buffer_count<\/code>, <code>rx_dropped<\/code>) og er enig i dette med <strong>BQL<\/strong> (gr\u00e6nser for bytek\u00f8er, automatisk p\u00e5 kernens side), s\u00e5 TX-k\u00f8erne ikke bliver overfyldte.<\/p>\n\n<h2>Virtualisering: IRQ'er i VM'er og p\u00e5 hypervisoren<\/h2>\n\n<p>I virtualiserede ops\u00e6tninger kontrollerer jeg den fysiske NIC-distribution p\u00e5 v\u00e6rten og indstiller <strong>IRQ-balancering<\/strong> helt klart. VM'erne f\u00e5r nok vCPU'er, men jeg undg\u00e5r blind overcommitment, s\u00e5 planl\u00e6gningsforsinkelser ikke \u00f8ger ventetiden. Moderne paravirtualiserede drivere som virtio-net eller vmxnet3 giver mig de bedste veje til h\u00f8je pps-hastigheder. Inden for VM'en tjekker jeg affinitet og k\u00f8antal igen, s\u00e5 g\u00e6sten ikke bliver en flaskehals. Det er afg\u00f8rende at have en konsekvent visning af v\u00e6rten og g\u00e6sten, s\u00e5 hele datastien <strong>\u00e6gte<\/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\/05\/server_irq_balance_net_5678.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Uddybning af virtualisering: SR-IOV, vhost og OVS<\/h2>\n<p>Til meget h\u00f8je pps-hastigheder bruger jeg hypervisoren <strong>SR-IOV<\/strong>Jeg binder virtuelle funktioner (VF'er) af det fysiske NIC direkte til VM'er og knytter dem til kerner i de relevante NUMA-noder. Det omg\u00e5r dele af v\u00e6rtsstakken og reducerer ventetiden. Hvor SR-IOV ikke passer ind, er jeg opm\u00e6rksom p\u00e5 <strong>vhost-net<\/strong> og fastg\u00f8r vhost-tr\u00e5dene som f.eks. applikationsarbejdere og IRQ-kerner, s\u00e5 der ikke sker spring p\u00e5 tv\u00e6rs af NUMA. I overlay- eller switching-ops\u00e6tninger vurderer jeg de ekstra omkostninger ved Linux bridge eller OVS; til ekstreme profiler bruger jeg kun OVS-DPDK, hvis den operationelle indsats retf\u00e6rdigg\u00f8r den m\u00e5lbare fordel. Det samme g\u00e6lder her: Jeg m\u00e5ler pps, latency og CPU-distribution, f\u00f8r jeg tr\u00e6ffer beslutninger, ikke bagefter.<\/p>\n\n<h2>Busy polling og userspace-tuning<\/h2>\n<p>Til latency-kritiske tjenester <strong>Optaget polling<\/strong> reducere jitteren. Jeg aktiverer f\u00f8lgende som en test <code>sysctl -w net.core.busy_read=50<\/code> og <code>net.core.busy_poll=50<\/code> (mikrosekunder) og indstil socket-indstillingen <code>SO_BUSY_POLL<\/code> selektivt for ber\u00f8rte sockets. User space polls derefter kort f\u00f8r blokering og fanger pakker, f\u00f8r de bev\u00e6ger sig dybere ind i k\u00f8erne. Det koster CPU-tid, men giver ofte mere stabile p99-latenstider. Jeg holder v\u00e6rdierne lave, overv\u00e5ger kerneudnyttelsen og kombinerer kun busy polling med klar tr\u00e5daffinitet og en fast CPU-guvern\u00f8r, ellers oph\u00e6ver effekterne hinanden.<\/p>\n\n<h2>Overblik over omkostninger til pakkefilter, Conntrack og eBPF<\/h2>\n<p>Firewall og NAT er en del af datastien. Jeg tjekker derfor <strong>nftables\/iptables<\/strong>-regler og rydder op i d\u00f8de regler eller dybe k\u00e6der. I travle ops\u00e6tninger justerer jeg Conntrack-tabellens st\u00f8rrelse (<code>nf_conntrack_max<\/code>, hash bucket number) eller deaktivere Conntrack specifikt for statsl\u00f8se flows. Hvis der bruges eBPF-programmer (XDP, tc-BPF), m\u00e5ler jeg deres runtime-omkostninger pr. hook og prioriterer \u201eearly drop\/redirect\u201c for at aflaste dyre stier. Det er vigtigt at have et klart ansvar: Enten sker optimeringen i NIC-offloaden, i eBPF-programmet eller i den klassiske stak - dobbeltarbejde \u00f8ger kun ventetiden.<\/p>\n\n<h2>CPU-isolering og housekeeping-kerner<\/h2>\n<p>For absolut deterministisk ventetid gemmer jeg baggrundsarbejde p\u00e5 <strong>Husholdnings-CPU'er<\/strong> af. Kerneparametre som f.eks. <code>nohz_full=<\/code>, <code>rcu_nocbs=<\/code> og <code>irqaffinity=<\/code> hj\u00e6lper med at holde dedikerede kerner stort set fri for tick-h\u00e5ndtering, RCU-callbacks og eksterne IRQ'er. Jeg isolerer et s\u00e6t kerner til applikationsarbejdere og et andet til IRQ'er og softirq'er; systemtjenester og timere k\u00f8rer p\u00e5 separate kerner. Det sikrer rene cache-profiler og reducerer pre-emption-effekter. Hyper-threading kan \u00f8ge jitter i enkelte tilf\u00e6lde; jeg tester, om deaktivering af det pr. kernepar udj\u00e6vner p99-latency, f\u00f8r jeg tager en global beslutning.<\/p>\n\n<h2>Diagnostisk drejebog og typiske anti-m\u00f8nstre<\/h2>\n<p>N\u00e5r der opst\u00e5r udfald eller ventetidsspidser, g\u00e5r jeg struktureret til v\u00e6rks: 1) <code>\/proc\/afbrydelser<\/code> Tjek for uj\u00e6vn fordeling. 2) <code>ethtool -S<\/code> p\u00e5 RX\/TX-drop, FIFO-fejl, <code>rx_no_buffer_count<\/code> Tjek. 3) <code>\/proc\/net\/softnet_stat<\/code> til \u201e<code>time_squeeze<\/code>\" eller \"<code>dr\u00e5ber<\/code>\u201c. 4) <code>mpstat -P ALL<\/code> og <code>top<\/code> for ksoftirqd-aktivitet. 5) Applikationsmetrikker (antal aktive forbindelser, retransmissioner med <code>ss -ti<\/code>). Anti-m\u00f8nstre, som jeg undg\u00e5r: store RX-ringe (skjult overbelastning), vild t\u00e6nding\/slukning af offloads uden m\u00e5ling, blanding af faste affiniteter med aggressiv irq-balance eller RPS og RSS samtidig uden en klar m\u00e5larkitektur. Hver \u00e6ndring f\u00e5r en m\u00e5ling f\u00f8r\/efter-sammenligning og en kort protokol.<\/p>\n\n<h2>Eksempler p\u00e5 koncepter for webhosting og API'er<\/h2>\n\n<h3>Klassisk webhosting-server<\/h3>\n<p>For mange sm\u00e5 hjemmesider aktiverer jeg <strong>irqbalance<\/strong>, Jeg opretter flere k\u00f8er og v\u00e6lger performance governor. Jeg m\u00e5ler L7-latenstider under spidsbelastninger og er opm\u00e6rksom p\u00e5 pps-spidsbelastninger, som prim\u00e6rt forekommer med TLS og HTTP\/2. Hvis hardwarek\u00f8erne ikke er tilstr\u00e6kkelige, tilf\u00f8jer jeg RPS til yderligere distribution p\u00e5 softwareniveau. Denne justering holder svartiderne <strong>konstant<\/strong>, selv om den samlede kapacitetsudnyttelse ser moderat ud. Regelm\u00e6ssig kontrol af <code>\/proc\/afbrydelser<\/code> Vis mig, om enkelte kerner h\u00e6lder.<\/p>\n\n<h3>Reverse proxy eller API-gateway med h\u00f8j belastning<\/h3>\n<p>For frontends med et h\u00f8jt antal forbindelser pinner jeg RX-k\u00f8er fint til definerede kerner og placerer proxy-arbejdere p\u00e5 n\u00e6rliggende kerner. Jeg tager en bevidst beslutning om, hvorvidt irqbalance forbliver aktiv, eller om fast pinning giver klarere resultater. Hvis der ikke er nok k\u00f8er, v\u00e6lger jeg specifikt RPS\/XPS og kalibrerer <strong>Sammensmeltning<\/strong>, for at undg\u00e5 IRQ-storme. Det giver mig mulighed for at opn\u00e5 lav latency ved en meget h\u00f8j pps-hastighed og holde tail latency under kontrol. Dokumentation af alle \u00e6ndringer letter efterf\u00f8lgende revisioner og holder adf\u00e6rden <strong>forudsigelig<\/strong>.<\/p>\n\n<h2>Valg af leverand\u00f8r og hardwarekriterier<\/h2>\n\n<p>Jeg er opm\u00e6rksom p\u00e5 NIC'er med <strong>Multi-k\u00f8<\/strong>, p\u00e5lidelig latenstid i backbone og opdaterede kerneversioner af platformen. Afbalanceret CPU-topologi og klar NUMA-separation forhindrer netv\u00e6rksafbrydelser i at n\u00e5 ind i fjernhukommelseszoner. For projekter med h\u00f8je pps-rater er valget af infrastruktur en \u00e6re for hver times tuning, fordi hardwaren giver reserver. I praktiske sammenligninger har jeg arbejdet godt med udbydere, der afsl\u00f8rer ydelsesprofiler og giver IRQ-venlige standardindstillinger, som f.eks. udbydere som webhoster.de. S\u00e5danne ops\u00e6tninger giver mig mulighed for at bruge IRQ-balancering, RSS og affinitet effektivt og minimere svartiderne. <strong>sn\u00e6vert<\/strong> til at holde.<\/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\/05\/serverraum-performance-2468.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Trin-for-trin-procedure til din egen tuning<\/h2>\n\n<p><strong>Trin 1:<\/strong> Jeg bestemmer den aktuelle status med <code>iperf3<\/code>, <code>sar<\/code>, <code>mpstat<\/code>, <code>nstat<\/code> og <code>ethtool -S<\/code>, s\u00e5 jeg har klare startv\u00e6rdier. <strong>Trin 2:<\/strong> Hvis irqbalance ikke k\u00f8rer, aktiverer jeg tjenesten, venter under belastning og sammenligner latency, pps og drops. <strong>Trin 3:<\/strong> Jeg tilpasser k\u00f8-nummeret og RSS-konfigurationen til kernerne i den tilknyttede NUMA-node. <strong>Trin 4:<\/strong> Jeg s\u00e6tter CPU-guvern\u00f8ren til \u201eperformance\u201c og tildeler centrale tjenester til de relevante kerner. <strong>Trin 5:<\/strong> F\u00f8rst derefter justerer jeg manuel affinitet og NUMA-pinning, hvis de m\u00e5lte v\u00e6rdier stadig viser flaskehalse. <strong>Trin 6:<\/strong> Jeg tjekker tendenser over flere dage for at kunne kategorisere event-peaks, backups eller marketing-peaks p\u00e5 en p\u00e5lidelig m\u00e5de.<\/p>\n\n<h2>Kort opsummeret<\/h2>\n\n<p>Effektiv <strong>IRQ-balancering<\/strong> fordeler netv\u00e6rksarbejdet p\u00e5 passende kerner, reducerer ventetiden og forhindrer udfald ved h\u00f8je pps-hastigheder. I kombination med NIC'er med flere k\u00f8er, RSS\/RPS, en passende CPU-guvern\u00f8r og ren tr\u00e5daffinitet udnytter jeg netstakken p\u00e5lideligt. M\u00e5lte v\u00e6rdier fra <code>ethtool -S<\/code>, <code>nstat<\/code>, <code>sar<\/code> og <code>iperf3<\/code> f\u00f8re mig skridt for skridt til mit m\u00e5l i stedet for at rode rundt i m\u00f8rket. Hvis du t\u00e6nker NUMA-topologi, IRQ-pinning og programplacering sammen, kan du holde svartiderne p\u00e5 et minimum. <strong>lav<\/strong> - selv under spidsbelastninger. Det betyder, at hosting med h\u00f8j belastning forbliver m\u00e6rkbart responsiv uden at br\u00e6nde un\u00f8dvendige CPU-reserver af.<\/p>","protected":false},"excerpt":{"rendered":"<p>L\u00e6r, hvordan du forbedrer dine Linux-serveres netv\u00e6rksydelse og g\u00f8r hostingops\u00e6tninger mere effektive ved at fokusere p\u00e5 server-IRQ-balancering.<\/p>","protected":false},"author":1,"featured_media":19362,"comment_status":"","ping_status":"","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"_crdt_document":"","inline_featured_image":false,"footnotes":""},"categories":[676],"tags":[],"class_list":["post-19369","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":"105","_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":"Server IRQ","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":"19362","footnotes":null,"_links":{"self":[{"href":"https:\/\/webhosting.de\/da\/wp-json\/wp\/v2\/posts\/19369","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=19369"}],"version-history":[{"count":0,"href":"https:\/\/webhosting.de\/da\/wp-json\/wp\/v2\/posts\/19369\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/webhosting.de\/da\/wp-json\/wp\/v2\/media\/19362"}],"wp:attachment":[{"href":"https:\/\/webhosting.de\/da\/wp-json\/wp\/v2\/media?parent=19369"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/webhosting.de\/da\/wp-json\/wp\/v2\/categories?post=19369"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/webhosting.de\/da\/wp-json\/wp\/v2\/tags?post=19369"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}