{"id":21057,"date":"2026-08-27T11:49:04","date_gmt":"2026-08-27T09:49:04","guid":{"rendered":"https:\/\/webhosting.de\/receive-side-scaling-rss-10g-25g-linux-server-optimierung-bitrate\/"},"modified":"2026-08-27T11:49:04","modified_gmt":"2026-08-27T09:49:04","slug":"receive-side-scaling-rss-10-g-25-g-linux-serveroptimering-bithastighed","status":"publish","type":"post","link":"https:\/\/webhosting.de\/da\/receive-side-scaling-rss-10g-25g-linux-server-optimierung-bitrate\/","title":{"rendered":"Receive Side Scaling ved 10 og 25 Gbit\/s: Ydelsesoptimering til moderne Linux-servernetv\u00e6rk"},"content":{"rendered":"<p><strong>Receive Side Scaling<\/strong> fordeler netv\u00e6rkstrafikken m\u00e5lrettet p\u00e5 flere kerner via 10- og 25-Gbit\/s-forbindelser, s\u00e5 Linux-servere kan h\u00e5ndtere h\u00f8je gennemstr\u00f8mningshastigheder med lav latenstid. Jeg viser i praksis, hvordan jeg aktiverer RSS, som <strong>Stikord<\/strong> p\u00e5 Cores mappe og dermed undg\u00e5r flaskehalse ved interrupts og cache-hits.<\/p>\n\n<h2>Centrale punkter<\/h2>\n\n<p>Jeg vil kort opsummere de vigtigste punkter, s\u00e5 du hurtigt kan planl\u00e6gge de n\u00e6ste skridt.<\/p>\n<ul>\n  <li><strong>Fordeling af belastning<\/strong>: Pakker fordeles via flere k\u00f8er til flere kerner.<\/li>\n  <li><strong>Cache-placering<\/strong>: En flow forbliver konsekvent p\u00e5 den samme k\u00f8.<\/li>\n  <li><strong>Hashing<\/strong>: 4-tupel-hash fordeler flows j\u00e6vnt over k\u00f8erne.<\/li>\n  <li><strong>affinitet<\/strong>: M\u00e5lrettet IRQ-mapping reducerer ventetiderne.<\/li>\n  <li><strong>Skalering<\/strong>: Fra 10\/25 Gbit\/s sikrer RSS en h\u00f8j gennemstr\u00f8mning.<\/li>\n<\/ul>\n<p>Disse punkter h\u00e6nger sammen og underst\u00f8tter <strong>Ydelse<\/strong> om reelle arbejdsbelastninger. Jeg prioriterer f\u00f8rst det korrekte antal k\u00f8er, derefter <strong>CPU<\/strong>-affinitet. Derefter tjekker jeg hash-parametre og finjusteringer.<\/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\/08\/servernetzwerk-performance-2947.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Hvad Receive Side Scaling kan<\/h2>\n\n<p>RSS opdeler modtagelsen af pakker i flere <strong>Modtagelsesk\u00f8er<\/strong>, som jeg tildeler specifikke CPU-kerner, s\u00e5 ingen enkelt kerne bliver en flaskehals. Det mindsker kraftige interrupt-spidser og udj\u00e6vner behandlingen via SoftIRQ\u2019er, hvilket reducerer latenstidsspidser og \u00f8ger gennemstr\u00f8mningen. Hver k\u00f8 udl\u00f8ser sine egne interrupts, som jeg binder fast til bestemte kerner for at holde dataveje konsistente. Denne konsistens fremmer <strong>Cache<\/strong>-Lokalitet, fordi en str\u00f8m altid rammer den samme kerne. Netop dette samspil bidrager direkte til m\u00e5lbar effektivitet ved h\u00f8je PPS-hastigheder.<\/p>\n\n<h2>S\u00e5dan fungerer RSS rent teknisk<\/h2>\n\n<p>NIC danner ud fra kilde-\/destinations-IP samt kilde-\/destinationsport en <strong>Hash<\/strong> og bruger den som indeks for indirektionstabellen, der peger p\u00e5 k\u00f8er. P\u00e5 denne m\u00e5de ender pakker fra en str\u00f8m altid i den samme k\u00f8 og forbliver dermed knyttet til den samme kerne. Forskellige str\u00f8mme fordeles j\u00e6vnt, forudsat at hash-n\u00f8gler og protokolfelter er konfigureret korrekt. Arbejdet flyttes dermed t\u00e6t p\u00e5 <strong>Hardware<\/strong>, hvilket betyder, at kernen skal udf\u00f8re f\u00e6rre afvejninger, og at overheadet reduceres. Det er netop det, jeg \u00f8nsker, for at holde pakkeforarbejdningen pr. kerne lav ved 10G\/25G.<\/p>\n\n\n<figure class=\"wp-block-image size-full is-resized\">\n  <img decoding=\"async\" src=\"https:\/\/webhosting.de\/wp-content\/uploads\/2026\/08\/linuxnetzwerke_tuning4683.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Hvorfor RSS fra 10 og 25 Gbit\/s er vigtigt<\/h2>\n\n<p>Ved 1 Gbit\/s er det ofte en enkelt <strong>Kerne<\/strong> pakkebelastningen, men fra 10 Gbit\/s \u00e6ndrer balancen sig hurtigt. Sm\u00e5 pakker f\u00e5r PPS-tallet til at stige, hvilket betyder, at en kerne hurtigt n\u00e5r 100 procent belastning, og der opst\u00e5r tab. Netop da fungerer RSS som en multiplikator for den anvendelige b\u00e5ndbredde. Jeg fordeler belastningen p\u00e5 flere <strong>Kerner<\/strong>, mindsker kontekstskift og holder latenstidskurverne mere stabile. Resultatet: Den reelle gennemstr\u00f8mning n\u00e6rmer sig f\u00f8rst linkhastigheden, n\u00e5r RSS fungerer korrekt.<\/p>\n\n<h2>Ops\u00e6tning af RSS p\u00e5 Linux-serveren<\/h2>\n\n<p>Under Linux styrer jeg RSS prim\u00e6rt via <strong>ethtool<\/strong>, driverindstillinger og sysfs, s\u00e5 NIC-funktionerne virkelig kommer til deres ret. F\u00f8rst l\u00e6ser jeg de maksimale RX-kanaler ud, derefter indstiller jeg et antal k\u00f8er, der passer til CPU\u2019en. Derefter tjekker jeg RSS-hash for TCP\/UDP og eventuelt for VLAN eller tunneling, s\u00e5 belastningsprofilerne forbliver j\u00e6vnt fordelt. Til at h\u00e5ndtere st\u00f8j i interrupt-fordelingen hj\u00e6lper mig <a href=\"https:\/\/webhosting.de\/da\/konfigurere-irq-balance-pa-linux-server\/\">IRQ-balancering<\/a>, selvom jeg foretr\u00e6kker at fasts\u00e6tte kritiske k\u00f8er manuelt. S\u00e5dan kobler jeg <strong>Stikord<\/strong> t\u00e6t p\u00e5 v\u00e6rtsens topologi og forhindrer forstyrrende vandringer.<\/p>\n\n<h2>Indirection-Table, RSS-Key og finjustering af hash: konkrete kommandoer<\/h2>\n\n<p>F\u00f8rst tjekker jeg den aktuelle fordeling og n\u00f8glen for NIC\u2019en:<\/p>\n<pre><code>ethtool -x eth0 # Vis indirektionstabel (RX-k\u00f8er) og RSS-n\u00f8gle\nethtool -n eth0 rx-flow-hash tcp4\nethtool -n eth0 rx-flow-hash udp4\n<\/code><\/pre>\n<p>For at sikre en j\u00e6vn fordeling indstiller jeg Indirection-Table til det \u00f8nskede antal k\u00f8er. Ved 16 k\u00f8er v\u00e6lger jeg en j\u00e6vn fordeling:<\/p>\n<pre><code>ethtool -X eth0 equal 16  # Fordeling j\u00e6vnt p\u00e5 16 k\u00f8er\n<\/code><\/pre>\n<p>Hvis det er n\u00f8dvendigt, tilpasser jeg hash-felterne. For TCP4 med 4-tupler (s=src-ip, d=dst-ip, f=src-port, n=dst-port):<\/p>\n<pre><code>ethtool -N eth0 rx-flow-hash tcp4 sdfn\nethtool -N eth0 rx-flow-hash udp4 sdfn\nethtool -N eth0 rx-flow-hash tcp6 sdfn\nethtool -N eth0 rx-flow-hash udp6 sdfn\n<\/code><\/pre>\n<p>Nogle drivere giver ogs\u00e5 mulighed for at angive en egen RSS-n\u00f8gle (f.eks. for at opn\u00e5 en bedre spredning i s\u00e6rlige tilf\u00e6lde):<\/p>\n<pre><code>ethtool -X eth0 hkey   # kun hvis driveren\/NIC'en underst\u00f8tter det\n<\/code><\/pre>\n\n<h2>Indstil CPU-affinitet og NUMA korrekt<\/h2>\n\n<p>Jeg kortl\u00e6gger hver RX-k\u00f8 ved hj\u00e6lp af <strong>IRQ-affinitet<\/strong> til dedikerede kerner og tag h\u00f8jde for NUMA, s\u00e5 data kun k\u00f8rer en kort vej gennem hukommelseskontrolleren. Hvis netv\u00e6rkskortet k\u00f8rer p\u00e5 node 0, knytter jeg ogs\u00e5 hovedk\u00f8erne til kerner p\u00e5 node 0 og placerer arbejdsbelastninger i n\u00e6rheden. Denne n\u00e6rhed reducerer fjernadgang og s\u00e6nker hukommelseslatensen markant. Her er det nyttigt at have en profil til produktive k\u00f8er samt separate kerner til administrations- og offload-opgaver. Hvis du vil g\u00e5 mere i dybden, finder du vejledning til finjustering under <a href=\"https:\/\/webhosting.de\/da\/server-irq-affinitet-multicore-netvaerksoptimering-ydelse\/\">IRQ-affinitet<\/a>, hvad ang\u00e5r planl\u00e6gningen pr. <strong>Kerne<\/strong> forenklet.<\/p>\n\n\n<figure class=\"wp-block-image size-full is-resized\">\n  <img decoding=\"async\" src=\"https:\/\/webhosting.de\/wp-content\/uploads\/2026\/08\/linux-server-network-tuning-2478.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>IRQ-affinitet-vejledning: fra IRQ\u2019er til stabil kernebinding<\/h2>\n\n<p>F\u00f8rst finder jeg ud af, hvilke IRQ'er der h\u00f8rer til RX-k\u00f8erne, og derefter binder jeg dem fast:<\/p>\n<pre><code>grep -E \"eth0.*Rx\" \/proc\/interrupts\ncat \/sys\/class\/net\/eth0\/device\/numa_node\n<\/code><\/pre>\n<p>Jeg foretager tildelingen via <code>smp_affinity_list<\/code>, s\u00e5 jeg ikke beh\u00f8ver at regne med Hex-masker. Eksempel: RX-k\u00f8er 0\u20137 p\u00e5 kerner 2\u20139:<\/p>\n<pre><code># Eksempel: Tildel IRQ\u2019er til kerner 2\u20139 (\u00e9n linje pr. IRQ)\necho 2  &gt; \/proc\/irq\/\/smp_affinity_list\necho 3  &gt; \/proc\/irq\/\/smp_affinity_list\necho 4  &gt; \/proc\/irq\/\/smp_affinity_list\n...\necho 9  &gt; \/proc\/irq\/\/smp_affinity_list\n<\/code><\/pre>\n<p>Vigtigt: MSI-X skal v\u00e6re aktiveret, for at hver k\u00f8 kan have sine egne interrupts. Hvis jeg bruger manuel pinning, blokerer jeg <code>irqbalance<\/code> for disse IRQ\u2019er (f.eks. via en sortliste) eller deaktiverer tjenesten m\u00e5lrettet p\u00e5 v\u00e6rter med statisk layout. NUMA tjekker jeg desuden med <code>lscpu<\/code> og PCIe-tildelingen, s\u00e5 jeg ikke opretter tv\u00e6rg\u00e5ende stier mellem noder.<\/p>\n\n<h2>Hash-konfiguration og protokoller<\/h2>\n\n<p>Jeg definerer hash-felterne p\u00e5 en s\u00e5dan m\u00e5de, at \u00e6gte <strong>Trafik<\/strong>-Fordel m\u00f8nstrene j\u00e6vnt i stedet for at de ender i f\u00e5 k\u00f8er. Til TCP\/UDP bruger jeg 4-tuplen, til IPv6 g\u00f8r jeg det p\u00e5 samme m\u00e5de, mens jeg ved VXLAN eller GRE tager h\u00f8jde for yderligere felter i indkapslingen. Nogle NIC'er tilbyder konfigurerbare hash-n\u00f8gler, som jeg tilpasser til den dominerende arbejdsbelastning. S\u00e5 snart jeg ser belastningskluster p\u00e5 enkelte k\u00f8er, justerer jeg hash-valget. Dette trin tager kun lidt tid, men forhindrer en <strong>Ubalance<\/strong> ved et h\u00f8jt antal forbindelser.<\/p>\n\n<h2>Interrupt-Coalescing og PPS<\/h2>\n\n<p>Jeg kombinerer RSS med moderat <strong>Sammenl\u00e6gning af afbrydelser<\/strong>, for at samle PPS-intensiv trafik i h\u00e5ndterbare batcher. Det reducerer interrupt-overhead, men m\u00e5 ikke forringe latenstiden for f\u00f8lsomme tjenester. Derfor m\u00e5ler jeg round-trip-tider og justerer coalescing-v\u00e6rdierne trinvist. Hvis man k\u00f8rer storage- eller backup-belastning, kan man samle i st\u00f8rre omfang end ved L7-API\u2019er eller VoIP. Alt i alt afbalancerer jeg <strong>Forsinkelse<\/strong> mod gennemstr\u00f8mningen, indtil begge dele stemmer overens.<\/p>\n\n\n<figure class=\"wp-block-image size-full is-resized\">\n  <img loading=\"lazy\" decoding=\"async\" src=\"https:\/\/webhosting.de\/wp-content\/uploads\/2026\/08\/performance_tuning_linux_1234.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Coalescing i praksis: Profiler og m\u00e5lepunkter<\/h2>\n\n<p>Jeg starter med moderate standardindstillinger og arbejder mig frem mod det optimale for hver enkelt arbejdsopgave. Tre gennempr\u00f8vede startprofiler:<\/p>\n<ul>\n  <li>API\/lav latenstid: <code>rx-usecs 2\u20136<\/code>, <code>rx-rammer 16\u201332<\/code>, adaptiv fra<\/li>\n  <li>Allround: <code>rx-usecs 8\u201316<\/code>, <code>rx-rammer 32\u201364<\/code>, adaptiv til<\/li>\n  <li>Bulk\/Opbevaring: <code>24\u201348 rx-usecs<\/code>, <code>rx-rammer 128\u2013256<\/code>, adaptiv til<\/li>\n<\/ul>\n<pre><code>ethtool -c eth0\nethtool -C eth0 rx-usecs 12 rx-frames 64 adaptive-rx on\n<\/code><\/pre>\n<p>Til det form\u00e5l m\u00e5ler jeg p95\/p99-latenser, PPS, CPU-belastning pr. kerne og genudsendelser. S\u00e5 snart jeg ser en stigende varians ved API\/VoIP, g\u00e5r jeg videre med <code>rx-usecs<\/code> ned igen. N\u00e5r det g\u00e6lder lagring, foretr\u00e6kker jeg at skalere op via frames for at spare p\u00e5 interrupts.<\/p>\n\n<h2>RSS i 10-Gbit-milj\u00f8er<\/h2>\n\n<p>P\u00e5 10G-NIC\u2019er arbejder jeg som regel med 8 til 16 <strong>Stikord<\/strong> pr. port, forudsat at CPU\u2019en stiller tilstr\u00e6kkeligt med kerner til r\u00e5dighed. Webservere, lagringsgateways og virtualiseringsv\u00e6rter kan dermed skaleres problemfrit over mange parallelle forbindelser. Jeg knytter hovedk\u00f8erne til ledige kerner og m\u00e5ler derefter PPS, latenstid og retransmissioner. Hvis der opst\u00e5r tab, tjekker jeg coalescing, hash og udnyttelsen pr. k\u00f8. Derefter finjusterer jeg <strong>affinitet<\/strong>, indtil belastningen ser j\u00e6vn ud.<\/p>\n\n<h2>RSS i 25-Gbit- og Multi-25G-konfigurationer<\/h2>\n\n<p>Med 25 Gbit\/s stiger PPS og busbelastningen, og derfor vil jeg <strong>NUMA<\/strong>-V\u00e6r mere opm\u00e6rksom p\u00e5 bevidsthed, tilstr\u00e6kkelige k\u00f8er og offloads. Large Receive Offload (LRO) eller RSC kan mindske pakketrykket p\u00e5 stakken, forudsat at applikationerne kan t\u00e5le det. Derudover tjekker jeg PCIe-baner for at udelukke flaskehalse uden for netv\u00e6rket. P\u00e5 v\u00e6rter med flere 25G-forbindelser adskiller jeg k\u00f8er og affinitet strengt efter opgaver og noder. S\u00e5ledes bruger jeg <strong>B\u00e5ndbredde<\/strong> og kerner effektivt, uden at det udvikler sig til trafik p\u00e5 tv\u00e6rs af noder.<\/p>\n\n\n<figure class=\"wp-block-image size-full is-resized\">\n  <img loading=\"lazy\" decoding=\"async\" src=\"https:\/\/webhosting.de\/wp-content\/uploads\/2026\/08\/linuxnetztuning_7234.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Detaljer om hardware og drivere: hvad jeg l\u00e6gger m\u00e6rke til<\/h2>\n\n<p>Ikke alle netv\u00e6rkskort fungerer p\u00e5 samme m\u00e5de. Intel-generationer (f.eks. ixgbe, i40e, ice) tilbyder funktioner som Flow Director\/ATR, der m\u00e5lrettet knytter datastr\u00f8mme til k\u00f8er \u2013 hvilket er nyttigt, n\u00e5r jeg \u00f8nsker at udj\u00e6vne hotspots. Mellanox mlx5 kan underst\u00f8tte aRFS i hardware, hvilket reducerer CPU-belastningen, n\u00e5r stakken betjener mange sockets. Jeg beslutter fra sag til sag, om jeg vil aktivere disse funktioner, og m\u00e5ler, om de forbedrer fordelingen. P\u00e5 routing-\/NAT-systemer deaktiverer jeg ofte LRO og bruger i stedet GRO for at opretholde header-konsistens; p\u00e5 rene server-workloads kan LRO\/GRO hj\u00e6lpe med at d\u00e6mpe PPS-presset. Det er desuden vigtigt at have tilstr\u00e6kkeligt med MSI-X-vektorer pr. k\u00f8 og korrekte firmwareversioner.<\/p>\n\n<h2>RSS inden for virtualisering og containere<\/h2>\n\n<p>I hypervisoren kombinerer jeg fysiske <strong>RSS<\/strong>-K\u00f8er med vNIC\u2019er, der underst\u00f8tter flere k\u00f8er, f.eks. virtio-net, s\u00e5 g\u00e6sterne ikke oplever kunstige flaskehalse. Jeg s\u00f8rger for CPU-pinning af de virtuelle maskiner og fastl\u00e6gger deres vCPU-NUMA-n\u00e6rhed til det fysiske netv\u00e6rkskort. P\u00e5 den m\u00e5de forbliver dataene lokalt, og v\u00e6rten betaler mindre for hukommelsesadgang. For containere binder jeg kritiske pods til passende kerner og holder v\u00e6rtsk\u00f8erne fri for st\u00f8jbelastning. Denne orden \u00f8ger <strong>Effektivitet<\/strong> i forbindelse med mikrotjenester, hvor der opst\u00e5r mange sm\u00e5 processer.<\/p>\n\n<h2>S\u00e5dan bruger du SR-IOV og VF-RSS korrekt<\/h2>\n\n<p>Med SR-IOV tildeler jeg VM\u2019er deres egne VF\u2019er, som igen kan stille flere k\u00f8er og RSS\u2019er til r\u00e5dighed. Jeg planl\u00e6gger et tilstr\u00e6kkeligt antal VF'er pr. port, holder \u00f8je med MSI-X-kapaciteten og tildeler VF-IRQ'erne i den virtuelle maskine i overensstemmelse med dens vCPU'er. I Linux-g\u00e6ster aktiverer jeg eksplicit Multi-Queue, ellers forbliver vNIC'en ofte et-trins:<\/p>\n<pre><code># som g\u00e6st (virtio-net-eksempel)\nethtool -l eth0\nethtool -L eth0 combined 4\n<\/code><\/pre>\n<p>Jeg fordeler v\u00e6rter med flere virtuelle maskiner strengt efter NUMA-node og arbejdsbelastning, s\u00e5 de virtuelle maskiner ikke forstyrrer hinanden i de samme fysiske RX-stier.<\/p>\n\n<h2>Overv\u00e5gning og fejlfinding<\/h2>\n\n<p>Jeg overv\u00e5ger udnyttelsesgraden pr. <strong>K\u00f8<\/strong>, enkelte kerner, pakketab og retransmissioner for at opdage uregelm\u00e6ssigheder i tide. Hvis en kerne tager over, mens andre forbliver ledige, er affiniteten eller antallet af k\u00f8er ofte ikke korrekt. I s\u00e5danne tilf\u00e6lde tjekker jeg hashfelter, IRQ-masker og coalescing-v\u00e6rdier \u00e9n efter \u00e9n. Derudover kigger jeg p\u00e5 <a href=\"https:\/\/webhosting.de\/da\/softirq-cpu-hosting-optimering-af-netvaerksgennemstromning-datacenter\/\">SoftIRQ-belastning<\/a>, fordi den giver tegn p\u00e5 fortr\u00e6ngningseffekter. F\u00f8rst n\u00e5r disse signaler ser stabile ud, \u00f8ger jeg trafikken eller udvider <strong>Stikord<\/strong> Forts\u00e6t.<\/p>\n\n\n<figure class=\"wp-block-image size-full is-resized\">\n  <img loading=\"lazy\" decoding=\"async\" src=\"https:\/\/webhosting.de\/wp-content\/uploads\/2026\/08\/servernetzwerk-optimierung-4721.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>RPS, RFS og XPS: Softwareudvidelser til RSS<\/h2>\n\n<p>Hvis et netv\u00e6rkskort kun har f\u00e5 k\u00f8er, eller hvis jeg bruger bonding\/tunneling, supplerer jeg RSS med <strong>RPS<\/strong> (Receive Packet Steering) og <strong>RFS<\/strong> (Receive Flow Steering). RPS fordeler SoftIRQ\u2019er p\u00e5 kernerne, mens RFS knytter datastr\u00f8mme til den kerne, hvor den tilh\u00f8rende socket er aktiv. Jeg aktiverer begge funktioner m\u00e5lrettet:<\/p>\n<pre><code># \u00d8g antallet af globale flow-poster (RFS)\necho 32768 &gt; \/proc\/sys\/net\/core\/rps_sock_flow_entries\n\n# Indstil CPU'er pr. RX-k\u00f8 til RPS (eksempelmaske, tilpas!)\nfor f in \/sys\/class\/net\/eth0\/queues\/rx-*\/rps_cpus; do echo ffff &gt; \"$f\"; done\n\nIndstil # pr. RX-k\u00f8 flow-tabel for RFS\nfor f in \/sys\/class\/net\/eth0\/queues\/rx-*\/rps_flow_cnt; do echo 4096 &gt; \"$f\"; done\n<\/code><\/pre>\n<p>P\u00e5 TX-siden bruger jeg <strong>XPS<\/strong> (Transmit Packet Steering), s\u00e5 udg\u00e5ende pakker sendes fra den kerne, der har genereret dem:<\/p>\n<pre><code>for f in \/sys\/class\/net\/eth0\/queues\/tx-*\/xps_cpus; do echo ffff &gt; \"$f\"; done\n<\/code><\/pre>\n<p>RPS\/RFS\/XPS belaster CPU\u2019en en smule, men er nyttige, hvis jeg mangler k\u00f8er p\u00e5 hardwaresiden, eller hvis jeg vil sikre en streng socket-lokalitet.<\/p>\n\n<h2>Single-Flow-kapacitet, GRO\/TSO og Busy-Polling<\/h2>\n\n<p>En enkelt datastr\u00f8m forbliver af gode grunde bundet til en kerne. Hvis jeg \u00f8nsker at \u00f8ge b\u00e5ndbredden for en enkelt datastr\u00f8m, satser jeg p\u00e5 offloads (GRO\/TSO), en h\u00f8j kernefrekvens og harmonisk coalescing. For latenstidsf\u00f8lsomme stier kan <strong>Optaget polling<\/strong> hj\u00e6lpe:<\/p>\n<pre><code>Indstil # til en lav v\u00e6rdi og m\u00e5l\nsysctl -w net.core.busy_read=25\nsysctl -w net.core.busy_poll=25\n<\/code><\/pre>\n<p>Busy-polling reducerer kontekstskift, men optager CPU-tid. Jeg aktiverer det kun der, hvor p99-latenser er afg\u00f8rende, og jeg vurderer altid virkningerne p\u00e5 den samlede belastning og tail-latensen. GRO holder jeg som regel sl\u00e5et til p\u00e5 servere, mens jeg anvender LRO afh\u00e6ngigt af rollen; p\u00e5 middleboxes forholder jeg mig konservativt for ikke at forstyrre header-behandlingen og hash-konsistensen.<\/p>\n\n<h2>Anbefalinger og eksempler: K\u00f8er, affinitet, kommandoer<\/h2>\n\n<p>Som udgangspunkt v\u00e6lger jeg et antal k\u00f8er, der passer til <strong>CPU<\/strong> Juster, overv\u00e5g derefter belastningen pr. k\u00f8 og juster trinvist. Ved 10G er 8\u201316 k\u00f8er ofte tilstr\u00e6kkelige, ved 25G s\u00e6tter jeg ofte antallet h\u00f8jere, forudsat at der er kerner til r\u00e5dighed. Til affinitet bruger jeg klare masker pr. IRQ, s\u00e5 jeg senere lettere kan analysere stierne. Den f\u00f8lgende tabel giver overskuelige retningslinjer, som jeg derefter verificerer ved hj\u00e6lp af m\u00e5linger. F\u00f8rst m\u00e5lingerne afg\u00f8r, om jeg <strong>mere<\/strong> forh\u00f8j eller reducer.<\/p>\n\n<table>\n  <thead>\n    <tr>\n      <th>Linkhastighed<\/th>\n      <th>Typiske RX-k\u00f8er<\/th>\n      <th>Eksempelkommandoer<\/th>\n      <th>Noter<\/th>\n    <\/tr>\n  <\/thead>\n  <tbody>\n    <tr>\n      <td>10 Gbit\/s<\/td>\n      <td>8-16<\/td>\n      <td><code>ethtool -l eth0<\/code> | <code>ethtool -L eth0 rx 16<\/code><\/td>\n      <td><strong>Sammensmeltning<\/strong> Hold det p\u00e5 et moderat niveau, kontroller L7-latens<\/td>\n    <\/tr>\n    <tr>\n      <td>25 Gbit\/s<\/td>\n      <td>16\u201332+<\/td>\n      <td><code>grep . \/proc\/interrupts<\/code> | IRQ-masker via <code>ekko<\/code><\/td>\n      <td><strong>NUMA<\/strong> V\u00e6r opm\u00e6rksom p\u00e5 dette, kontroller PCIe-baner<\/td>\n    <\/tr>\n    <tr>\n      <td>Multi-25G<\/td>\n      <td>Separat pr. portion<\/td>\n      <td>Aktiv\u00e9r vNIC Multi-Queue (f.eks. virtio)<\/td>\n      <td>K\u00f8er p\u00e5 kerner og <strong>Arbejdsbyrder<\/strong> dele sig<\/td>\n    <\/tr>\n  <\/tbody>\n<\/table>\n\n<p>Disse retningslinjer udg\u00f8r kun udgangspunktet, ikke m\u00e5let, da arbejdsbelastningerne varierer meget. Jeg logger \u00e6ndringer, foretager m\u00e5linger f\u00f8r og efter justeringen og holder ellers milj\u00f8et u\u00e6ndret. S\u00e5 snart systemet forbliver stabilt under produktionsbelastning, l\u00e5ser jeg konfigurationen fast. Senere gentager jeg m\u00e5lingerne efter opdateringer af kernen eller driverne. P\u00e5 den m\u00e5de holder jeg mig til <strong>RSS<\/strong> Pr\u00e6cis kurs og sikre, reproducerbare resultater.<\/p>\n\n<h2>Typiske forhindringer og modforanstaltninger<\/h2>\n\n<p>For f\u00e5 <strong>Stikord<\/strong> Overbelaster enkelte kerner, mens for mange \u00f8ger administrationsbyrden og forringer cache-hitraten. En uheldig affinitet flytter interrupts til kerner, der allerede er belastede, eller til forkerte NUMA-noder. Ogs\u00e5 en uhensigtsm\u00e6ssig hash f\u00f8rer til, at dominerende flows tilstopper k\u00f8erne. Jeg l\u00f8ser dette trin for trin: justere antallet af k\u00f8er, korrigere affinitet, udvide hash-felter, finjustere coalescing. Hver \u00e6ndring dokumenterer jeg med <strong>Metrikker<\/strong>, f\u00f8r jeg g\u00e5r videre til den n\u00e6ste h\u00e5ndtag.<\/p>\n\n<h2>Praksisn\u00e6re scenarier<\/h2>\n\n<p>En lagringsserver med 10G f\u00e5r hurtigt fordel af 8\u201312 <strong>Stikord<\/strong> samt moderat coalescing for at sikre, at bulk-overf\u00f8rsler forl\u00f8ber problemfrit. En API-server med et stort antal forbindelser har ofte brug for finere hash-felter og lavere latenstid ved interrupts. Virtualiseringsv\u00e6rter opn\u00e5r betydelige fordele, n\u00e5r vNIC-Multi-Queue er aktiveret p\u00e5 g\u00e6stesiden og passer til v\u00e6rtslayoutet. Container-workloads fungerer bedre, n\u00e5r kritiske pods k\u00f8rer t\u00e6t p\u00e5 NIC og NUMA-hukommelse. Jeg udvider disse m\u00f8nstre efter situationen ved at <strong>PPS<\/strong>, sammenlign retransmissioner og k\u00f8fordeling.<\/p>\n\n<h2>Effektive platforme som en fordel<\/h2>\n\n<p>Hosting-ops\u00e6tninger med konsekvent konfigureret <strong>RSS<\/strong>, Multi-Queue-NIC'er og pr\u00e6cis affinitet giver m\u00e6rkbare reserver ved spidsbelastning. N\u00e5r man vurderer serverl\u00f8sninger, b\u00f8r man specifikt sp\u00f8rge ind til Multi-Queue-funktion, NUMA-pinning og overv\u00e5gning. En udbyder, der tydeligt implementerer disse punkter, opn\u00e5r ofte markant bedre gennemstr\u00f8mningskurver. N\u00e5r det g\u00e6lder h\u00f8jtydende server- og hostingl\u00f8sninger, vil jeg her klart anbefale webhoster.de. Denne fokusering betaler sig i <strong>Ydelse<\/strong> og stabilitet, is\u00e6r n\u00e5r der k\u00f8rer mange parallelle flows.<\/p>\n\n<h2>Resum\u00e9 til brug i praksis<\/h2>\n\n<p>Jeg aktiverer <strong>Modtag<\/strong> Side-scaling: Indstil et rimeligt antal k\u00f8er, tildel IRQ\u2019er til passende kerner, og kontroller hash-konfigurationen. Derefter optimerer jeg coalescing med henblik p\u00e5 at minimere latenstiden, sikrer NUMA-n\u00e6rhed og fordeler arbejdsbelastningen ensartet. I virtualisering bruger jeg multi-k\u00f8 helt ind i g\u00e6sterne og holder pinning og affinitet synkroniseret. M\u00e5linger af PPS, k\u00f8belastning, retransmissioner og latenstid afg\u00f8r det n\u00e6ste skridt. Hvis man g\u00e5r frem p\u00e5 denne m\u00e5de, udnytter man 10G og 25G fuldt ud og holder <strong>Forsinkelse<\/strong> inden for rammerne og opn\u00e5r p\u00e5lideligt afkast fra netv\u00e6rket.<\/p>","protected":false},"excerpt":{"rendered":"<p>Receive Side Scaling optimerer 10G- og 25G-netv\u00e6rk ved at fordele pakker p\u00e5 flere CPU-kerner. L\u00e6r, hvordan du konfigurerer RSS p\u00e5 Linux-serveren og dermed f\u00e5r den maksimale ydeevne ud af dit setup. Fokus: Receive Side Scaling i h\u00f8jhastighedsmilj\u00f8er.<\/p>","protected":false},"author":1,"featured_media":21050,"comment_status":"","ping_status":"","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"inline_featured_image":false,"footnotes":""},"categories":[676],"tags":[],"class_list":["post-21057","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":"136","_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":"receive side scaling","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":"21050","footnotes":null,"_links":{"self":[{"href":"https:\/\/webhosting.de\/da\/wp-json\/wp\/v2\/posts\/21057","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=21057"}],"version-history":[{"count":0,"href":"https:\/\/webhosting.de\/da\/wp-json\/wp\/v2\/posts\/21057\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/webhosting.de\/da\/wp-json\/wp\/v2\/media\/21050"}],"wp:attachment":[{"href":"https:\/\/webhosting.de\/da\/wp-json\/wp\/v2\/media?parent=21057"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/webhosting.de\/da\/wp-json\/wp\/v2\/categories?post=21057"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/webhosting.de\/da\/wp-json\/wp\/v2\/tags?post=21057"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}