{"id":19569,"date":"2026-06-01T08:35:01","date_gmt":"2026-06-01T06:35:01","guid":{"rendered":"https:\/\/webhosting.de\/softirq-cpu-hosting-netzwerkdurchsatz-optimierung-datacenter\/"},"modified":"2026-06-01T08:35:01","modified_gmt":"2026-06-01T06:35:01","slug":"softirq-cpu-hosting-naetverk-genomstroemning-optimering-datacenter","status":"publish","type":"post","link":"https:\/\/webhosting.de\/sv\/softirq-cpu-hosting-netzwerkdurchsatz-optimierung-datacenter\/","title":{"rendered":"softirq cpu hosting: optimera serverprestanda och n\u00e4tverksgenomstr\u00f6mning"},"content":{"rendered":"<p>Jag visar hur <strong>softirq cpu<\/strong> tillsammans med NAPI, IRQ-distribution och k\u00f6design begr\u00e4nsar eller frig\u00f6r n\u00e4tverksgenomstr\u00f6mningen i hosting. Med tydliga m\u00e4tpunkter, m\u00e5linriktad tuning och rena affiniteter minskar jag <strong>F\u00f6rdr\u00f6jningar<\/strong> och konsekvent \u00f6ka pps-genomstr\u00f6mningen p\u00e5 produktiva servrar.<\/p>\n\n<h2>Centrala punkter<\/h2>\n<p>Dessa k\u00e4rnid\u00e9er transporterar n\u00e4tverkspaket effektivt via CPU, kernel och NIC - och h\u00e5ller svarstiderna till ett minimum. <strong>konstant<\/strong> l\u00e5g.<\/p>\n<ul>\n  <li><strong>NAPI:s budget<\/strong> finjustering: Fler paket per omr\u00f6stning minskar omkostnaderna och j\u00e4mnar ut <strong>CPU-belastning<\/strong>.<\/li>\n  <li><strong>IRQ-balansering<\/strong> och affinitet: undvik hotspots, \u00f6ka antalet tr\u00e4ffar i cacheminnet, <strong>F\u00f6rdr\u00f6jningstoppar<\/strong> trycka.<\/li>\n  <li><strong>Flera k\u00f6er<\/strong>, RSS\/RPS\/XPS: parallellisera fl\u00f6den, uppr\u00e4tth\u00e5lla NUMA-anpassning, <strong>pps<\/strong> h\u00f6ja.<\/li>\n  <li><strong>Avlastning<\/strong> anv\u00e4nda medvetet: GRO\/LRO, TSO, utv\u00e4rdera sammanslagning, <strong>Jitter<\/strong> i sikte.<\/li>\n  <li><strong>Isolering<\/strong> och Busy Polling: F\u00f6ruts\u00e4gbara svarstider p\u00e5 dedikerade <strong>K\u00e4rnor<\/strong>.<\/li>\n<\/ul>\n\n<h2>Grunderna: Vad som h\u00e4nder i k\u00e4rnan under n\u00e4tverkstrafik<\/h2>\n<p>Ett paket landar f\u00f6rst i ett h\u00e5rdvaruinterrupt, varefter k\u00e4rnan tar \u00f6ver arbetet i <strong>SoftIRQs<\/strong> och NAPI poll-loopar. Jag ser till att den snabba HardIRQ-fasen f\u00f6rblir riktigt kort och att den faktiska logiken flyttas till r\u00e4tt sammanhang s\u00e5 att <strong>CPU-tid<\/strong> inte f\u00f6rsvinner. Ksoftirqd-tr\u00e5darna tr\u00e4der bara in om direktbearbetning inte \u00e4r m\u00f6jlig, vilket snabbt leder till k\u00f6er under kontinuerlig belastning. Det \u00e4r precis h\u00e4r som v\u00e4ntetiden uppst\u00e5r, vilket \u00e5terspeglas i \u00f6kad TTFB och fluktuerande genomstr\u00f6mning. Om du vill f\u00f6rdjupa dig kan du hitta praktisk kunskap om IRQ-bearbetning i den h\u00e4r artikeln om <a href=\"https:\/\/webhosting.de\/sv\/server-avbrottshantering-optimering-av-cpu-prestanda-7342\/\">Interrupthantering och CPU-prestanda<\/a>, som jag anv\u00e4nder f\u00f6r kategoriseringen.<\/p>\n\n\n<figure class=\"wp-block-image size-full is-resized\">\n  <img fetchpriority=\"high\" decoding=\"async\" src=\"https:\/\/webhosting.de\/wp-content\/uploads\/2026\/06\/serverperformance-netzwerk-4861.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>NAPI, SoftIRQs och ksoftirqd: kontrollera f\u00f6rdr\u00f6jning i st\u00e4llet f\u00f6r att hantera den<\/h2>\n<p>NAPI minskar avbrottsstormarna genom att plocka upp flera paket per k\u00f6rning inom en definierad budget och d\u00e4rmed minimera avbrottstiden. <strong>Overhead<\/strong> s\u00e4nker. Om budgeten \u00e4r otillr\u00e4cklig staplas paketen p\u00e5 varandra, ksoftirqd g\u00e5r varm och <strong>F\u00f6rdr\u00f6jning<\/strong> \u00f6kar m\u00e4tbart. I s\u00e5dana situationer kontrollerar jag systematiskt \/proc\/softirqs och \/proc\/net\/softnet_stat f\u00f6r att visualisera droppar, time_squeeze eller \u00f6verfyllda k\u00f6er. Sedan \u00f6kar jag gradvis net.core.netdev_budget eller net.core.netdev_budget_usecs och \u00f6vervakar CPU-belastning, p95\/p99-distribution och paketf\u00f6rluster parallellt. Tricket \u00e4r att f\u00e5 tillr\u00e4ckligt med arbete gjort per poll utan att tr\u00e4nga ut den interaktiva exekveringen av anv\u00e4ndarlandstr\u00e5dar.<\/p>\n\n<h2>IRQ-balansering och -affinitet: undvik hotspots, \u00f6ka antalet tr\u00e4ffar i cacheminnet<\/h2>\n<p>En enda k\u00e4rna med alla NIC IRQ:er blir en flaskhals eftersom den m\u00e5ste hantera avbrott, mjuka IRQ:er och apptr\u00e5dar; jag distribuerar d\u00e4rf\u00f6r <strong>IRQ:er<\/strong> riktade. Tj\u00e4nsten irqbalance hj\u00e4lper till, men f\u00f6r h\u00f6ga pps-hastigheter mappar jag uttryckligen RX\/TX-k\u00f6er via affinitet till l\u00e4mpliga <strong>k\u00e4rnor<\/strong>. P\u00e5 NUMA-system binder jag k\u00f6er till k\u00e4rnor i samma nod f\u00f6r att undvika fj\u00e4rrminnes\u00e5tkomst. Applikationstr\u00e5dar k\u00f6rs p\u00e5 n\u00e4rliggande men separata k\u00e4rnor, vilket f\u00f6rb\u00e4ttrar cachelokaliteten och schemal\u00e4ggningen. Den h\u00e4r guiden till strategisk distribution ger en bra \u00f6versikt \u00f6ver de <a href=\"https:\/\/webhosting.de\/sv\/server-irq-balansering-optimering-av-naetverksprestanda-datacenter\/\">IRQ-balansering i datacentret<\/a>, som jag anv\u00e4nder som referens f\u00f6r att finjustera.<\/p>\n\n\n<figure class=\"wp-block-image size-full is-resized\">\n  <img decoding=\"async\" src=\"https:\/\/webhosting.de\/wp-content\/uploads\/2026\/06\/serverperformance3942.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Multi-queue, RSS\/RPS\/XPS: Anv\u00e4nd parallellisering p\u00e5 r\u00e4tt s\u00e4tt<\/h2>\n<p>Moderna n\u00e4tverkskort levereras med flera RX\/TX-k\u00f6er, som jag kan styra via <strong>RSS<\/strong> till fl\u00f6den och p\u00e5 s\u00e5 s\u00e4tt uppn\u00e5 verklig parallellism. Om kortet erbjuder f\u00f6r f\u00e5 k\u00f6er anv\u00e4nder jag RPS\/XPS f\u00f6r att g\u00f6ra justeringar p\u00e5 mjukvarusidan f\u00f6r att f\u00f6rdela paketen p\u00e5 ett vettigt s\u00e4tt \u00f6ver fl\u00f6dena. <strong>k\u00e4rnor<\/strong> att trycka p\u00e5. Ren hashdistribution \u00e4r viktigt s\u00e5 att ett fl\u00f6de alltid finns kvar p\u00e5 samma CPU och inga dyra cache-f\u00f6rvr\u00e4ngningar uppst\u00e5r. Samtidigt h\u00e5ller jag TX- och RX-v\u00e4garna n\u00e4ra varandra f\u00f6r att undvika l\u00e5skonflikter och on\u00f6diga accesser mellan noderna. Detta \u00f6kar pps-genomstr\u00f6mningen utan att en enda k\u00e4rna drar i bromsen.<\/p>\n\n<h2>CPU-affinitet \u00e4nda in i anv\u00e4ndarutrymmet: end-to-end-t\u00e4nkande<\/h2>\n<p>Jag planerar datav\u00e4gen fr\u00e5n NIC-IRQ via NAPI-k\u00f6er till appens arbetstr\u00e5dar s\u00e5 att paketen n\u00e5r sin destination utan on\u00f6diga krokar och <strong>Svarstid<\/strong> f\u00f6rblir konstant. F\u00f6r att uppn\u00e5 detta separerar jag konsekvent k\u00e4rnor f\u00f6r avbrott\/softIRQ fr\u00e5n app-k\u00e4rnor och skapar tydliga <strong>Affinitet<\/strong>-regler. Webbservrar, omv\u00e4nda proxyer och databaser f\u00e5r fasta CPU-upps\u00e4ttningar som ligger n\u00e4ra IRQ-k\u00e4rnorna f\u00f6r att h\u00e5lla v\u00e4garna korta. Dessutom st\u00e4ller jag in CPU-guvern\u00f6ren p\u00e5 prestanda s\u00e5 att klockf\u00f6r\u00e4ndringar inte driver jitter till p99. Den h\u00e4r konsekventa tilldelningen g\u00f6r beteendet f\u00f6ruts\u00e4gbart och hj\u00e4lper till att diagnostisera flaskhalsar p\u00e5 ett enkelt s\u00e4tt.<\/p>\n\n\n<figure class=\"wp-block-image size-full is-resized\">\n  <img decoding=\"async\" src=\"https:\/\/webhosting.de\/wp-content\/uploads\/2026\/06\/server-performance-optimization-8321.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Avlastning, GRO\/LRO, brandv\u00e4gg och eBPF: Spara belastning utan att flyga i blindo<\/h2>\n<p>Spara avlastning av checksumma, TSO och koalescens <strong>CPU-tid<\/strong>, De kan dock \u00e4ndra paketstorlekar, burstbeteende och jitter, vilket \u00e4r anledningen till att jag m\u00e4ter effekterna specifikt. GRO\/LRO buntar ihop ramar och minskar belastningen p\u00e5 stacken, men f\u00f6r realtidskrav beslutar jag situationsbaserat om <strong>Avaktivering<\/strong> eller begr\u00e4nsad anv\u00e4ndning. Conntrack-tabeller och djupa nftables\/iptables-kedjor kostar tid, s\u00e5 jag rensar upp bland \u00f6verfl\u00f6diga regler och f\u00f6renklar s\u00f6kv\u00e4garna. Om det beh\u00f6vs anv\u00e4nder jag eBPF (XDP, tc-BPF) f\u00f6r att fatta tidiga beslut vid NIC:en och undvika kostsamma v\u00e4gar. En bra utg\u00e5ngspunkt f\u00f6r att finjustera praxis \u00e4r denna \u00f6versikt \u00f6ver <a href=\"https:\/\/webhosting.de\/sv\/avbrott-koalescens-naetverksoptimering-serverflux\/\">Sammanslagning av avbrott<\/a>, vilket jag tar h\u00e4nsyn till f\u00f6r k\u00e4nsliga latensbudgetar.<\/p>\n\n<h2>Busy polling och CPU-isolering: L\u00e5sning av svarstider<\/h2>\n<p>F\u00f6r h\u00e5rda latensm\u00e5l anv\u00e4nder jag busy polling s\u00e5 att userspace-sockets plockar upp paket \u00e4nnu tidigare och <strong>V\u00e4ntetider<\/strong> f\u00f6rkorta. Detta \u00f6kar belastningen, men ger mig mycket smala p99-distributioner f\u00f6r API eller handelsarbetsbelastningar p\u00e5 dedikerade <strong>K\u00e4rnor<\/strong>. Dessutom isolerar jag k\u00e4rnor med isolcpus=, nohz_full= och rcu_nocbs= s\u00e5 att timers, RCU och systemtj\u00e4nster bara k\u00f6rs p\u00e5 hush\u00e5lls-CPU:er. Den h\u00e4r separationen f\u00f6rhindrar st\u00f6rningar p\u00e5 latensprocessorerna och g\u00f6r beteendet reproducerbart. Resultatet \u00e4r en tydlig f\u00e4rdplan: dedikerade k\u00e4rnor, tidig paketinsamling, definierade budgetar.<\/p>\n\n\n<figure class=\"wp-block-image size-full is-resized\">\n  <img loading=\"lazy\" decoding=\"async\" src=\"https:\/\/webhosting.de\/wp-content\/uploads\/2026\/06\/softirq_cpu_hosting_4321.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>\u00d6vervakning och fels\u00f6kning: fr\u00e5n symptom till orsak<\/h2>\n<p>Jag b\u00f6rjar med pps, genomstr\u00f6mning och k\u00e4rnbelastning, sedan kontrollerar jag droppar och aktiviteten hos <strong>ksoftirqd<\/strong>-tr\u00e5dar \u00f6ver tid f\u00f6r att p\u00e5 ett tillf\u00f6rlitligt s\u00e4tt k\u00e4nna igen m\u00f6nster. Verktyg som sar, htop, ss, nload och ethtool visar mig n\u00e4r och var \u00f6verbelastning uppst\u00e5r och om <strong>Ledtr\u00e5dar<\/strong> n\u00e5r sina gr\u00e4nser. F\u00f6rdelningar \u00e4r viktiga i st\u00e4llet f\u00f6r medelv\u00e4rden s\u00e5 att kv\u00e4llstoppar, cron-f\u00f6nster eller kampanjer inte g\u00e5r f\u00f6rlorade. Jag korrelerar TTFB-toppar med IRQ-distribution, NAPI-budget och offload-inst\u00e4llningar f\u00f6r att kunna g\u00f6ra riktade justeringar. En justerad IRQ-affinitet eller en ny skr\u00e4ddarsydd NAPI-budget \u00e4r ofta tillr\u00e4ckligt f\u00f6r att m\u00e4rkbart minska timeouts.<\/p>\n\n<h2>Tuningparametrar i en \u00f6verblick<\/h2>\n<p>F\u00f6ljande \u00f6versikt hj\u00e4lper mig att anv\u00e4nda \u00e4ndringar p\u00e5 ett klokt s\u00e4tt och att tydligt ange effekterna innan jag g\u00f6r permanenta \u00e4ndringar. <strong>Rollouts<\/strong> planera. Jag testar varje justering iterativt, m\u00e4ter latensf\u00f6rdelningar och observerar bieffekter p\u00e5 <strong>CPU<\/strong> och minne. Jag \u00e4ndrar alltid bara en punkt per testf\u00f6nster s\u00e5 att orsak och verkan f\u00f6rblir tydliga. Sedan dokumenterar jag resultaten och fastst\u00e4ller tr\u00f6skelv\u00e4rden f\u00f6r varningar. P\u00e5 s\u00e5 s\u00e4tt uppn\u00e5r jag reproducerbara f\u00f6rb\u00e4ttringar utan att riskera \u00f6verraskningar i den produktiva trafiken.<\/p>\n<table>\n  <thead>\n    <tr>\n      <th>Parameter\/Funktion<\/th>\n      <th>Effekt i datav\u00e4gen<\/th>\n      <th>N\u00e4r ska man samla in pengar\/aktivera<\/th>\n      <th>Risker\/biverkningar<\/th>\n    <\/tr>\n  <\/thead>\n  <tbody>\n    <tr>\n      <td><strong>net.core.netdev_budget<\/strong><\/td>\n      <td>Fler paket per NAPI-unders\u00f6kning<\/td>\n      <td>F\u00f6r droppar i softnet_stat<\/td>\n      <td>L\u00e4ngre omr\u00f6stningar tr\u00e4nger undan anv\u00e4ndartr\u00e5dar<\/td>\n    <\/tr>\n    <tr>\n      <td><strong>net.core.netdev_budget_usecs<\/strong><\/td>\n      <td>Begr\u00e4nsa tidsf\u00f6nstret per omr\u00f6stning<\/td>\n      <td>F\u00f6r jitter p\u00e5 grund av stora bursts<\/td>\n      <td>F\u00f6r liten: fler kontextf\u00f6r\u00e4ndringar<\/td>\n    <\/tr>\n    <tr>\n      <td><strong>RSS\/RPS\/XPS<\/strong><\/td>\n      <td>F\u00f6rdela fl\u00f6den \u00f6ver k\u00e4rnor<\/td>\n      <td>F\u00f6r hotspots p\u00e5 en k\u00e4rna<\/td>\n      <td>Felaktiga hashes: cache-f\u00f6rvr\u00e4ngningar<\/td>\n    <\/tr>\n    <tr>\n      <td><strong>IRQ-affinitet<\/strong><\/td>\n      <td>Bind IRQ:er n\u00e4ra k\u00e4rnan<\/td>\n      <td>Med NUMA-Missmatch<\/td>\n      <td>Felallokering skapar nya hotspots<\/td>\n    <\/tr>\n    <tr>\n      <td><strong>GRO\/LRO\/TSO<\/strong><\/td>\n      <td>Minskar antalet f\u00f6rpackningar<\/td>\n      <td>F\u00f6r CPU-flaskhals<\/td>\n      <td>Jitter, st\u00f6rre bursts<\/td>\n    <\/tr>\n    <tr>\n      <td><strong>Upptagen polling<\/strong><\/td>\n      <td>Tidig paketinsamling<\/td>\n      <td>F\u00f6r tuffa p99-m\u00e5l<\/td>\n      <td>Mer CPU-f\u00f6rbrukning<\/td>\n    <\/tr>\n  <\/tbody>\n<\/table>\n\n\n<figure class=\"wp-block-image size-full is-resized\">\n  <img loading=\"lazy\" decoding=\"async\" src=\"https:\/\/webhosting.de\/wp-content\/uploads\/2026\/06\/developer_desk_focus_optimization_3748.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>RX\/TX-ringar och cue-djup: dimensionera buffertar korrekt<\/h2>\n<p>\u00c4ven med korrekt f\u00f6rdelade IRQ:er och l\u00e4mpliga budgetar kan NIC-ringar som \u00e4r f\u00f6r sm\u00e5 eller f\u00f6r stora f\u00f6rs\u00e4mra prestandan. Jag kontrollerar d\u00e4rf\u00f6r kortets RX\/TX-ringstorlekar och anpassar dem till burstkarakt\u00e4ren och latensm\u00e5len. F\u00f6r sm\u00e5 ringar leder till avbrott i NIC:en under trafiktoppar, vilket syns som rx_missed_errors eller fifo_errors i drivrutinens statistik. Ringar som \u00e4r f\u00f6r stora d\u00f6ljer \u00f6verbelastning, \u00f6kar latensen och skapar l\u00e5nga trailing edges i p95\/p99. Jag letar efter en medelv\u00e4g: tillr\u00e4ckligt med buffert f\u00f6r att absorbera korta utbrott, men inte s\u00e5 mycket att paketen \u201c\u00e5ldras\u201d i k\u00f6erna.<\/p>\n<p>Dessutom tittar jag p\u00e5 v\u00e4rdsidan <strong>tx_k\u00f6_len<\/strong> och den Qdisc som anv\u00e4nds. Med sch_fq eller fq_codel kan jag j\u00e4mna ut burstbeteendet och f\u00f6rdela stora TSO-paket via pacing. Detta minskar mikroburst p\u00e5 switchporten och g\u00f6r latensf\u00f6rloppet j\u00e4mnare - viktigt f\u00f6r blandade arbetsbelastningar d\u00e4r sm\u00e5 RPC:er k\u00f6rs parallellt med stora uppladdningar. Jag \u00f6vervakar ethtool-statistiken och korrelerar den med softnet_stat f\u00f6r att se om \u00f6verbelastningen uppst\u00e5r i NIC-ringen, i netdev-backloggen eller i Qdisc.<\/p>\n\n<h2>MTU, jumboramar och segmentering<\/h2>\n<p>Die <strong>MTU<\/strong> \u00e4r en klassisk h\u00e4vst\u00e5ng som ofta underskattas. Jumboramar minskar antalet paket per Gbit\/s och minskar belastningen p\u00e5 processorn - men bara om v\u00e4gen verkligen \u00e4r jumbokapabel fr\u00e5n b\u00f6rjan till slut. Jag validerar d\u00e4rf\u00f6r systematiskt fj\u00e4rrstationerna, switcharna och tunnlarna. S\u00e5 snart det sker en fragmentering tillbaka till 1500 n\u00e5gonstans finns det risk f\u00f6r MTU-problem p\u00e5 v\u00e4gen, \u00e5ters\u00e4ndningar och on\u00f6diga <strong>Jitter<\/strong>. I datacenter med dominerande \u00f6st-v\u00e4stlig kommunikation l\u00f6nar det sig att anv\u00e4nda en homogen 9k-strategi, medan 1500 ofta \u00e4r det stabilare valet f\u00f6r arbetsbelastningar som vetter mot Internet.<\/p>\n<p>Jag utv\u00e4rderar alltid MTU i samband med <strong>TSO\/GSO\/GRO<\/strong>Alltf\u00f6r aggressiv buntning kan leda till stora bursts i TX som fyller uppstr\u00f6ms buffertar och genererar latens\u00f6kningar. M\u00e5let \u00e4r en konsekvent v\u00e4g: f\u00f6rnuftig segmentering i s\u00e4ndaren, tillr\u00e4ckliga pacing-mekanismer och GRO som sparar arbete p\u00e5 mottagarsidan utan att motverka realtidskraven.<\/p>\n\n<h2>UDP, QUIC och str\u00f6mmande arbetsbelastningar: t\u00e4nk p\u00e5 detaljerna<\/h2>\n<p>All trafik \u00e4r inte TCP. <strong>UDP<\/strong>-tunga profiler (DNS, VoIP, QUIC, telemetri) beter sig annorlunda i RSS\/RPS och GRO. Moderna stackar st\u00f6der UDP-GRO\/GSO, vilket kan minska belastningen p\u00e5 processorn - jag anv\u00e4nder detta selektivt och m\u00e4ter om omordningsrisker eller jitter \u00f6kar. F\u00f6r QUIC\/HTTP3-belastningar \u00e4r ren fl\u00f6desf\u00f6rdelning avg\u00f6rande: RPS kan hj\u00e4lpa till om NIC:en erbjuder f\u00f6r f\u00e5 RSS-k\u00f6er, men f\u00e5r inte \u201ckasta runt\u201d n\u00e5gra heta cache-fl\u00f6den. P\u00e5 TX-sidan st\u00e4ller jag in <strong>XPS<\/strong> f\u00f6r att samla \u00f6verf\u00f6ringsv\u00e4gar och minska l\u00e5skonflikter. I praktiken l\u00f6nar det sig med en tyst, k\u00e4rnaffin allokering, s\u00e4rskilt med m\u00e5nga medelstora UDP-fl\u00f6den d\u00e4r varje cache-tr\u00e4ff r\u00e4knas.<\/p>\n\n<h2>Virtualisering och containrar: ren integration av host, guest och vhost<\/h2>\n<p>I virtualiserade milj\u00f6er skiftar arbetet mellan IRQ:er f\u00f6r host, vhost-tr\u00e5dar och guest. Jag ser till att <strong>vhost-n\u00e4t<\/strong>-tr\u00e5dar f\u00e5r sina egna k\u00e4rnor och kolliderar inte med app-arbetare. Deras affiniteter m\u00e5ste matcha de fysiska RX\/TX-k\u00f6erna, annars blir det on\u00f6dig migration mellan olika CPU:er. I g\u00e4sten kontrollerar jag virtio-net-k\u00f6er, aktiverar multi-queue och s\u00e4tter upp RSS\/RPS analogt med bare metal. D\u00e4r latency och pps \u00e4r i f\u00f6rgrunden <strong>SR-IOV<\/strong> ytterligare minska overheadkostnader - f\u00f6ruts\u00e4ttningen \u00e4r en konsekvent NUMA-topologi: VF, vCPU och minne h\u00f6r hemma p\u00e5 samma nod.<\/p>\n<p>I containerstacken orsakar \u00f6verlagrade n\u00e4tverk, djupa NAT-kedjor och komplexa CNI-topologier ytterligare hopp. F\u00f6r latenskritiska tj\u00e4nster f\u00f6redrar jag hostNetwork eller magra n\u00e4tverk (macvlan\/ipvlan), utj\u00e4mnar NAT-v\u00e4gar och h\u00e5ller <strong>Conntrack<\/strong> s\u00e5 liten som m\u00f6jligt. En konsekvent CPU-strategi \u00e4r viktig: IRQ- och NAPI-k\u00e4rnor i v\u00e4rden b\u00f6r placeras i n\u00e4rheten av de k\u00e4rnor som vhost\/container-arbetare k\u00f6rs p\u00e5 - detta \u00e4r det enda s\u00e4ttet att h\u00e5lla datav\u00e4gen kort och f\u00f6ruts\u00e4gbar.<\/p>\n\n<h2>Schemal\u00e4ggning, C-status och IRQ-threading<\/h2>\n<p>Eftersom latens inte bara \u00e4r ber\u00e4kningstid utan ocks\u00e5 <strong>Tid f\u00f6r uppvaknande<\/strong> Jag minimerar djupa C-status p\u00e5 latens-k\u00e4rnorna. En aggressiv powersave kan kosta millisekunder innan en SoftIRQ faktiskt k\u00f6rs. D\u00e4rf\u00f6r f\u00f6rlitar jag mig p\u00e5 prestandastyrningen, begr\u00e4nsar djupa C-states och h\u00e5ller turbon konsekvent f\u00f6r att g\u00f6ra frekvenshopp f\u00f6ruts\u00e4gbara. Lika viktigt \u00e4r <strong>IRQ-tr\u00e5dning<\/strong>D\u00e4r drivrutinerna till\u00e5ter det flyttar jag arbetet till IRQ-tr\u00e5dar och prioriterar s\u00e5 att RX startar f\u00f6re nedstr\u00f6msarbete utan att helt f\u00f6rskjuta anv\u00e4ndarland. Samspelet mellan schemapolicyer, affiniteter och budgetar \u00e4r knepigt; jag testar steg f\u00f6r steg, loggar p99 och ser upp f\u00f6r st\u00f6rningar med ksoftirqd, som annars blir en hemlig flaskhals.<\/p>\n\n<h2>Observation p\u00e5 djupet: tracepoints, counters, histos<\/h2>\n<p>Om m\u00e4tv\u00e4rdena f\u00f6rblir vaga g\u00e5r jag en niv\u00e5 djupare: jag anv\u00e4nder kernel tracepoints runt <strong>netif_mottagning_skb<\/strong>, <strong>napi_poll<\/strong> och <strong>net_dev_queue<\/strong>, f\u00f6r att visa polltider, paketvolymer och v\u00e4ntetider som histogram. S\u00e5dana f\u00f6rdelningar visar om 1 % av unders\u00f6kningarna tar f\u00f6r l\u00e5ng tid eller om enskilda k\u00f6er h\u00e5ller p\u00e5 att ta slut. Dessutom kan ethtool-<strong>rx\/tx<\/strong>-r\u00e4knare, TCP retransmits, busy poll hits och softnet_stat visar tydligt var paket g\u00e5r f\u00f6rlorade. Jag anv\u00e4nder drop-analys f\u00f6r att se om NIC:en sl\u00e4pper paket (ringen full), om netdev-backloggen kollapsar (time_squeeze) eller om Qdisc\/firewall saktar ned. Det \u00e4r f\u00f6rst n\u00e4r dessa pusselbitar passar ihop som jag justerar ringar, budgetar eller avlastningar.<\/p>\n\n<h2>Effektivisera s\u00e4kerhets- och filtreringsv\u00e4garna<\/h2>\n<p>Komplexa ACL:er, djupa nftables\/iptables-kedjor och breda conntrack-tabeller ger konstant latens per paket. Jag konsoliderar regler, arbetar med set\/maps och flyttar generiska drops s\u00e5 l\u00e5ngt fram i v\u00e4gen som m\u00f6jligt - helst s\u00e5 tidigt som m\u00f6jligt vid NIC:en (XDP\/clsact) om latensen \u00e4r kritisk. Statl\u00f6sa fl\u00f6den, telemetri eller k\u00e4nda \u201cs\u00e4kra\u201d portar kan anv\u00e4ndas p\u00e5 ett m\u00e5linriktat s\u00e4tt. <strong>utan sp\u00e5rning<\/strong> f\u00f6r att eliminera behovet av kostsamma uppslagningar. Samtidigt h\u00e5ller jag statstabellerna uppdaterade, anpassar hashstorlekar till belastningstoppar och rensar aggressivt bort f\u00f6r\u00e4ldral\u00f6sa poster. M\u00e5let \u00e4r en ren, sp\u00e5rbar policyv\u00e4g som inte m\u00e4rks i profilen som en permanent belastning.<\/p>\n\n<h2>Typiska anti-m\u00f6nster och hur jag undviker dem<\/h2>\n<ul>\n  <li><strong>Alla IRQ:er p\u00e5 en k\u00e4rna:<\/strong> leder till \u00f6verbelastning och heta ksoftirqd. Motgift: riktade affiniteter per cue, NUMA-koherent.<\/li>\n  <li><strong>Blind maximering av ringar\/budgets:<\/strong> d\u00f6ljer tr\u00e4ngsel, \u00f6kar latenstiderna. Motgift: \u00f6ka stegvis, m\u00e4t distributioner.<\/li>\n  <li><strong>Felaktig konfiguration av fl\u00f6deshastighet:<\/strong> Fl\u00f6dena hoppar mellan k\u00e4rnorna, cacheminnet f\u00f6rsvinner. Motgift: stabila RSS-nycklar, RPS\/XPS endast med ett tydligt m\u00e5l.<\/li>\n  <li><strong>App-tr\u00e5dar p\u00e5 samma k\u00e4rnor som SoftIRQs:<\/strong> Interferens och jitter. Motgift: h\u00e5rd separation, granntilldelning.<\/li>\n  <li><strong>Overlays\/NAT utan budget:<\/strong> l\u00e4ggs till varje hopp. \u00c5tg\u00e4rd: Str\u00f6mlinjeforma v\u00e4gar, v\u00e4rdn\u00e4tverk f\u00f6r latenta arbetsbelastningar.<\/li>\n  <li><strong>Energibesparing p\u00e5 latensk\u00e4rnor:<\/strong> Djupa C-tillst\u00e5nd saktar ner reaktionen. Motgift: prestandareglering, begr\u00e4nsning av C-tillst\u00e5nd.<\/li>\n  <li><strong>Avlastning utan m\u00e4tning:<\/strong> TSO\/GRO kan f\u00f6rv\u00e4rra bursts och jitter. \u00c5tg\u00e4rd: Aktivera arbetsbelastningsspecifik, \u00f6vervaka p99.<\/li>\n<\/ul>\n\n<h2>Praktisk hosting: steg som fungerar<\/h2>\n<p>Jag b\u00f6rjar med en ren m\u00e4tfas, s\u00e4tter baslinjer och h\u00e5ller alla f\u00f6r\u00e4ndringar sm\u00e5 i korta tidsf\u00f6nster s\u00e5 att jag kan <strong>Orsaker<\/strong> kan separeras. Jag aktiverar sedan irqbalance, kontrollerar den automatiska f\u00f6rdelningen och st\u00e4ller vid behov in manuella affiniteter tills ingen <strong>Hotspots<\/strong> \u00e4r inte l\u00e4ngre synliga. Sedan konfigurerar jag Multi-Queue, RSS och - om det beh\u00f6vs - RPS\/XPS, synkroniserat med NUMA. Jag binder app-arbetarna till k\u00e4rnor i n\u00e4rheten av deras IRQ-k\u00e4rnor, men utan direkt kollision. Slutligen rensar jag brandv\u00e4ggsv\u00e4gar, kontrollerar conntrack-tabeller och fattar medvetna beslut om avlastning baserat p\u00e5 latensm\u00e5l.<\/p>\n\n<h2>Exempel p\u00e5 spelbok f\u00f6r p99-latenstider<\/h2>\n<p>F\u00f6rst m\u00e4ter jag p95\/p99 via representativ belastning och s\u00e4kra loggar fr\u00e5n \/proc\/softirqs och \/proc\/net\/softnet_stat f\u00f6r att <strong>Droppar<\/strong> och time_squeeze \u00e4r tydligt synliga. Sedan \u00f6kar jag netdev_budget eller netdev_budget_usecs steg f\u00f6r steg och h\u00e5ller p99 efter varje \u00e4ndring s\u00e5 att jag kan se verkliga <strong>Trender<\/strong> k\u00e4nner igen. Parallellt binder jag IRQ:er till k\u00e4rnor i en NUMA-nod och flyttar apparbetare till l\u00e4mpliga grannar. Om p99 forts\u00e4tter att hoppa testar jag GRO\/LRO-varianter och avbryter sammanfogningsprofiler, var och en med en kort m\u00e4tv\u00e4g. F\u00f6rst n\u00e4r distributionen f\u00f6rblir stabil \u00f6verf\u00f6r jag konfigurationen till Ansible-roller eller systemd-dropins.<\/p>\n\n\n<figure class=\"wp-block-image size-full is-resized\">\n  <img loading=\"lazy\" decoding=\"async\" src=\"https:\/\/webhosting.de\/wp-content\/uploads\/2026\/06\/serverraum-performance-1947.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Kort version f\u00f6r administrat\u00f6rer<\/h2>\n<p>Jag uppn\u00e5r st\u00f6rst h\u00e4vst\u00e5ngseffekt genom att <strong>SoftIRQs<\/strong>, NAPI-budget, IRQ-affiniteter och apptr\u00e5dar som en sammanh\u00e4ngande datav\u00e4g. Jag f\u00f6rdelar n\u00e4tverksarbete \u00f6ver k\u00e4rnor, h\u00e5ller NUMA-k\u00f6er sammanh\u00e4ngande och kopplar ihop arbetare p\u00e5 ett f\u00f6rnuftigt s\u00e4tt s\u00e5 att <strong>Rutter<\/strong> h\u00e5ll dig kort. Jag st\u00e4ller in avlastningar medvetet och m\u00e4ter jitter i st\u00e4llet f\u00f6r att blint optimera f\u00f6r genomstr\u00f6mning. F\u00f6r h\u00e5rda latensm\u00e5l f\u00f6rlitar jag mig p\u00e5 upptagen polling och CPU-isolering, medan hush\u00e5lls-CPU:er f\u00e5ngar upp st\u00f6rningar. Om du implementerar dessa steg p\u00e5 ett disciplinerat s\u00e4tt f\u00e5r du konstant genomstr\u00f6mning, smalare latensf\u00f6rdelningar och en hostingmilj\u00f6 som reagerar f\u00f6ruts\u00e4gbart p\u00e5 belastningstoppar.<\/p>","protected":false},"excerpt":{"rendered":"<p>L\u00e4r dig hur softirq cpu-hosting med optimerade linuxavbrott, NAPI och IRQ-balansering \u00f6kar din n\u00e4tverksgenomstr\u00f6mning och minskar latenserna i serverdriften.<\/p>","protected":false},"author":1,"featured_media":19562,"comment_status":"","ping_status":"","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"inline_featured_image":false,"footnotes":""},"categories":[676],"tags":[],"class_list":["post-19569","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-server_vm"],"acf":[],"_wp_attached_file":null,"_wp_attachment_metadata":null,"litespeed-optimize-size":null,"litespeed-optimize-set":null,"_elementor_source_image_hash":null,"_wp_attachment_image_alt":null,"stockpack_author_name":null,"stockpack_author_url":null,"stockpack_provider":null,"stockpack_image_url":null,"stockpack_license":null,"stockpack_license_url":null,"stockpack_modification":null,"color":null,"original_id":null,"original_url":null,"original_link":null,"unsplash_location":null,"unsplash_sponsor":null,"unsplash_exif":null,"unsplash_attachment_metadata":null,"_elementor_is_screenshot":null,"surfer_file_name":null,"surfer_file_original_url":null,"envato_tk_source_kit":null,"envato_tk_source_index":null,"envato_tk_manifest":null,"envato_tk_folder_name":null,"envato_tk_builder":null,"envato_elements_download_event":null,"_menu_item_type":null,"_menu_item_menu_item_parent":null,"_menu_item_object_id":null,"_menu_item_object":null,"_menu_item_target":null,"_menu_item_classes":null,"_menu_item_xfn":null,"_menu_item_url":null,"_trp_menu_languages":null,"rank_math_primary_category":null,"rank_math_title":null,"inline_featured_image":null,"_yoast_wpseo_primary_category":null,"rank_math_schema_blogposting":null,"rank_math_schema_videoobject":null,"_oembed_049c719bc4a9f89deaead66a7da9fddc":null,"_oembed_time_049c719bc4a9f89deaead66a7da9fddc":null,"_yoast_wpseo_focuskw":null,"_yoast_wpseo_linkdex":null,"_oembed_27e3473bf8bec795fbeb3a9d38489348":null,"_oembed_c3b0f6959478faf92a1f343d8f96b19e":null,"_trp_translated_slug_en_us":null,"_wp_desired_post_slug":null,"_yoast_wpseo_title":null,"tldname":null,"tldpreis":null,"tldrubrik":null,"tldpolicylink":null,"tldsize":null,"tldregistrierungsdauer":null,"tldtransfer":null,"tldwhoisprivacy":null,"tldregistrarchange":null,"tldregistrantchange":null,"tldwhoisupdate":null,"tldnameserverupdate":null,"tlddeletesofort":null,"tlddeleteexpire":null,"tldumlaute":null,"tldrestore":null,"tldsubcategory":null,"tldbildname":null,"tldbildurl":null,"tldclean":null,"tldcategory":null,"tldpolicy":null,"tldbesonderheiten":null,"tld_bedeutung":null,"_oembed_d167040d816d8f94c072940c8009f5f8":null,"_oembed_b0a0fa59ef14f8870da2c63f2027d064":null,"_oembed_4792fa4dfb2a8f09ab950a73b7f313ba":null,"_oembed_33ceb1fe54a8ab775d9410abf699878d":null,"_oembed_fd7014d14d919b45ec004937c0db9335":null,"_oembed_21a029d076783ec3e8042698c351bd7e":null,"_oembed_be5ea8a0c7b18e658f08cc571a909452":null,"_oembed_a9ca7a298b19f9b48ec5914e010294d2":null,"_oembed_f8db6b27d08a2bb1f920e7647808899a":null,"_oembed_168ebde5096e77d8a89326519af9e022":null,"_oembed_cdb76f1b345b42743edfe25481b6f98f":null,"_oembed_87b0613611ae54e86e8864265404b0a1":null,"_oembed_27aa0e5cf3f1bb4bc416a4641a5ac273":null,"_oembed_time_27aa0e5cf3f1bb4bc416a4641a5ac273":null,"_tldname":null,"_tldclean":null,"_tldpreis":null,"_tldcategory":null,"_tldsubcategory":null,"_tldpolicy":null,"_tldpolicylink":null,"_tldsize":null,"_tldregistrierungsdauer":null,"_tldtransfer":null,"_tldwhoisprivacy":null,"_tldregistrarchange":null,"_tldregistrantchange":null,"_tldwhoisupdate":null,"_tldnameserverupdate":null,"_tlddeletesofort":null,"_tlddeleteexpire":null,"_tldumlaute":null,"_tldrestore":null,"_tldbildname":null,"_tldbildurl":null,"_tld_bedeutung":null,"_tldbesonderheiten":null,"_oembed_ad96e4112edb9f8ffa35731d4098bc6b":null,"_oembed_8357e2b8a2575c74ed5978f262a10126":null,"_oembed_3d5fea5103dd0d22ec5d6a33eff7f863":null,"_eael_widget_elements":null,"_oembed_0d8a206f09633e3d62b95a15a4dd0487":null,"_oembed_time_0d8a206f09633e3d62b95a15a4dd0487":null,"_aioseo_description":null,"_eb_attr":null,"_eb_data_table":null,"_oembed_819a879e7da16dd629cfd15a97334c8a":null,"_oembed_time_819a879e7da16dd629cfd15a97334c8a":null,"_acf_changed":null,"_wpcode_auto_insert":null,"_edit_last":null,"_edit_lock":null,"_oembed_e7b913c6c84084ed9702cb4feb012ddd":null,"_oembed_bfde9e10f59a17b85fc8917fa7edf782":null,"_oembed_time_bfde9e10f59a17b85fc8917fa7edf782":null,"_oembed_03514b67990db061d7c4672de26dc514":null,"_oembed_time_03514b67990db061d7c4672de26dc514":null,"rank_math_news_sitemap_robots":null,"rank_math_robots":null,"_eael_post_view_count":"76","_trp_automatically_translated_slug_ru_ru":null,"_trp_automatically_translated_slug_et":null,"_trp_automatically_translated_slug_lv":null,"_trp_automatically_translated_slug_fr_fr":null,"_trp_automatically_translated_slug_en_us":null,"_wp_old_slug":null,"_trp_automatically_translated_slug_da_dk":null,"_trp_automatically_translated_slug_pl_pl":null,"_trp_automatically_translated_slug_es_es":null,"_trp_automatically_translated_slug_hu_hu":null,"_trp_automatically_translated_slug_fi":null,"_trp_automatically_translated_slug_ja":null,"_trp_automatically_translated_slug_lt_lt":null,"_elementor_edit_mode":null,"_elementor_template_type":null,"_elementor_version":null,"_elementor_pro_version":null,"_wp_page_template":null,"_elementor_page_settings":null,"_elementor_data":null,"_elementor_css":null,"_elementor_conditions":null,"_happyaddons_elements_cache":null,"_oembed_75446120c39305f0da0ccd147f6de9cb":null,"_oembed_time_75446120c39305f0da0ccd147f6de9cb":null,"_oembed_3efb2c3e76a18143e7207993a2a6939a":null,"_oembed_time_3efb2c3e76a18143e7207993a2a6939a":null,"_oembed_59808117857ddf57e478a31d79f76e4d":null,"_oembed_time_59808117857ddf57e478a31d79f76e4d":null,"_oembed_965c5b49aa8d22ce37dfb3bde0268600":null,"_oembed_time_965c5b49aa8d22ce37dfb3bde0268600":null,"_oembed_81002f7ee3604f645db4ebcfd1912acf":null,"_oembed_time_81002f7ee3604f645db4ebcfd1912acf":null,"_elementor_screenshot":null,"_oembed_7ea3429961cf98fa85da9747683af827":null,"_oembed_time_7ea3429961cf98fa85da9747683af827":null,"_elementor_controls_usage":null,"_elementor_page_assets":[],"_elementor_screenshot_failed":null,"theplus_transient_widgets":null,"_eael_custom_js":null,"_wp_old_date":null,"_trp_automatically_translated_slug_it_it":null,"_trp_automatically_translated_slug_pt_pt":null,"_trp_automatically_translated_slug_zh_cn":null,"_trp_automatically_translated_slug_nl_nl":null,"_trp_automatically_translated_slug_pt_br":null,"_trp_automatically_translated_slug_sv_se":null,"rank_math_analytic_object_id":null,"rank_math_internal_links_processed":"1","_trp_automatically_translated_slug_ro_ro":null,"_trp_automatically_translated_slug_sk_sk":null,"_trp_automatically_translated_slug_bg_bg":null,"_trp_automatically_translated_slug_sl_si":null,"litespeed_vpi_list":null,"litespeed_vpi_list_mobile":null,"rank_math_seo_score":null,"rank_math_contentai_score":null,"ilj_limitincominglinks":null,"ilj_maxincominglinks":null,"ilj_limitoutgoinglinks":null,"ilj_maxoutgoinglinks":null,"ilj_limitlinksperparagraph":null,"ilj_linksperparagraph":null,"ilj_blacklistdefinition":null,"ilj_linkdefinition":null,"_eb_reusable_block_ids":null,"rank_math_focus_keyword":"softirq cpu","rank_math_og_content_image":null,"_yoast_wpseo_metadesc":null,"_yoast_wpseo_content_score":null,"_yoast_wpseo_focuskeywords":null,"_yoast_wpseo_keywordsynonyms":null,"_yoast_wpseo_estimated-reading-time-minutes":null,"rank_math_description":null,"surfer_last_post_update":null,"surfer_last_post_update_direction":null,"surfer_keywords":null,"surfer_location":null,"surfer_draft_id":null,"surfer_permalink_hash":null,"surfer_scrape_ready":null,"_thumbnail_id":"19562","footnotes":null,"_links":{"self":[{"href":"https:\/\/webhosting.de\/sv\/wp-json\/wp\/v2\/posts\/19569","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/webhosting.de\/sv\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/webhosting.de\/sv\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/webhosting.de\/sv\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/webhosting.de\/sv\/wp-json\/wp\/v2\/comments?post=19569"}],"version-history":[{"count":0,"href":"https:\/\/webhosting.de\/sv\/wp-json\/wp\/v2\/posts\/19569\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/webhosting.de\/sv\/wp-json\/wp\/v2\/media\/19562"}],"wp:attachment":[{"href":"https:\/\/webhosting.de\/sv\/wp-json\/wp\/v2\/media?parent=19569"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/webhosting.de\/sv\/wp-json\/wp\/v2\/categories?post=19569"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/webhosting.de\/sv\/wp-json\/wp\/v2\/tags?post=19569"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}