{"id":21347,"date":"2026-09-13T08:35:03","date_gmt":"2026-09-13T06:35:03","guid":{"rendered":"https:\/\/webhosting.de\/linux-softirq-auslastung-analysieren-performance-tuning-datacenter\/"},"modified":"2026-09-13T08:35:03","modified_gmt":"2026-09-13T06:35:03","slug":"analysera-belastningen-pa-linux-softirq-prestandajustering-datacenter","status":"publish","type":"post","link":"https:\/\/webhosting.de\/sv\/linux-softirq-auslastung-analysieren-performance-tuning-datacenter\/","title":{"rendered":"Analysera och optimera SoftIRQ-belastningen i Linux"},"content":{"rendered":"<p>Jag visar steg f\u00f6r steg hur jag <strong>Linux SoftIRQ<\/strong>-m\u00e4tar belastningen, synligg\u00f6r flaskhalsar och \u00e5terf\u00e5r kontrollen med n\u00e5gra f\u00e5 justeringar i k\u00e4rnan. D\u00e4rvid prioriterar jag m\u00e4tbara effekter: kortare <strong>F\u00f6rdr\u00f6jningar<\/strong>, balanserade CPU-k\u00e4rnor och stabil paketbehandling vid h\u00f6g n\u00e4tverksbelastning.<\/p>\n\n<h2>Centrala punkter<\/h2>\n<ul>\n  <li><strong>M\u00e4tpunkter<\/strong> f\u00f6rst\u00e5: \/proc\/softirqs, softnet_stat, interrupts<\/li>\n  <li><strong>Symptom<\/strong> identifiera: belastning p\u00e5 ksoftirqd, paketf\u00f6rluster, latensspikar<\/li>\n  <li><strong>Tuning<\/strong> styr: netdev_budget och netdev_budget_usecs<\/li>\n  <li><strong>Distribution<\/strong> spara: IRQ-affinitet, RSS, k\u00f6-mappning<\/li>\n  <li><strong>\u00d6vervakning<\/strong> genomf\u00f6ra: mpstat, perf, sp\u00e5rning<\/li>\n<\/ul>\n\n<h2>\u00d6versikt \u00f6ver SoftIRQ: Hur k\u00e4rnan fungerar<\/h2>\n<p>Efter ett h\u00e5rdvaruavbrott flyttar k\u00e4rnan delar av arbetet till s\u00e5 kallade <strong>SoftIRQs<\/strong>, s\u00e5 att kritiska v\u00e4gar snabbt frig\u00f6rs och bearbetningen f\u00f6rblir planerbar. S\u00e4rskilt i n\u00e4tverksv\u00e4gen samlar NAPI-hanterare in paket fr\u00e5n NIC-ringarna, initierar protokollbearbetning och \u00f6verl\u00e4mnar data till <strong>N\u00e4tverksstack<\/strong>. Om antalet h\u00e4ndelser \u00f6kar tr\u00e4der tr\u00e5dar per CPU, s\u00e5som ksoftirqd\/cpuN, in och tar \u00f6ver avfr\u00e5gningen samt efterbearbetningen. Denna avkoppling f\u00f6rb\u00e4ttrar den totala genomstr\u00f6mningskapaciteten, men kan vid \u00f6verbelastning leda till l\u00e5nga SoftIRQ-k\u00f6rtider p\u00e5 enskilda <strong>K\u00e4rnor<\/strong> leder till. Jag h\u00e5ller d\u00e4rf\u00f6r ett \u00f6ga p\u00e5 om NET_RX- och NET_TX-v\u00e4garna dominerar och om ksoftirqd synligt slukar CPU-tid. P\u00e5 s\u00e5 s\u00e4tt kan jag uppt\u00e4cka n\u00e4r SoftIRQ:er blir en flaskhals och ytterligare <strong>Optimeringar<\/strong> \u00e4r n\u00f6dv\u00e4ndiga.<\/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\/09\/linux-analyse-optimierung-5893.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Identifiera typiska symptom p\u00e5 h\u00f6g SoftIRQ-belastning<\/h2>\n<p>En betydande SoftIRQ-belastning m\u00e4rker jag f\u00f6rst genom en konstant h\u00f6g <strong>K\u00e4rn-CPU<\/strong> och ksoftirqd-processer som h\u00e5ller toppv\u00e4rden under flera sekunder. Samtidigt \u00f6kar latensen f\u00f6r n\u00e4tverks- och block-I\/O, vilket m\u00e4rks i tr\u00f6ga TLS-handskakningar eller sega <strong>API:er<\/strong> uttrycks. Ofta uppst\u00e5r paketf\u00f6rluster samtidigt som n\u00e4tverkskortets ringar \u00f6verbelastas och eftersl\u00e4pningarna v\u00e4xer. Om avbrott f\u00f6rdelas d\u00e5ligt drabbas ofta CPU 0 h\u00e5rt, eftersom m\u00e5nga IRQ-linjer tillsammans med efterf\u00f6ljande bearbetning hamnar p\u00e5 en <strong>K\u00e4rnan<\/strong> . Denna bindning till en enda k\u00e4rna \u00f6kar v\u00e4ntetiderna f\u00f6r tj\u00e4nsterna och minskar den effektiva genomstr\u00f6mningen. Jag unders\u00f6ker d\u00e4rf\u00f6r om detta m\u00f6nster \u00e4r systematiskt eller om det bara beror p\u00e5 <strong>Toppar<\/strong> leder till.<\/p>\n\n<h2>Viktiga m\u00e4tpunkter: Att tolka \/proc och verktygen p\u00e5 r\u00e4tt s\u00e4tt<\/h2>\n<p>Jag b\u00f6rjar med \/proc\/softirqs, eftersom jag d\u00e4r kan se, per CPU och typ, hur mycket ungef\u00e4r <strong>NET_RX<\/strong>, NET_TX, TIMER eller BLOCK \u00f6kar. I \/proc\/net\/softnet_stat granskar jag raderna med fokus p\u00e5 f\u00e4lt som indikerar \u00f6verskridna budgetar eller bortkastade paket, vilket vid en stadig \u00f6kning tydligt tyder p\u00e5 att <strong>Avst\u00e4mningscykler<\/strong> tyder p\u00e5. \/proc\/interrupts visar sedan om h\u00e5rdvaruavbrott f\u00f6rdelas oj\u00e4mnt mellan processorerna och vilka IRQ:er som \u00e4r mest aktiva. Verktyg som mpstat, top eller htop hj\u00e4lper mig att identifiera ksoftirqd\/cpuN och f\u00f6rdelningen av <strong>Softirq-tider<\/strong> bed\u00f6mas per k\u00e4rna. Vid behov visar perf var det finns flaskhalsar i stacken, s\u00e5 att jag kan hitta hanterare och drivrutinsv\u00e4gar som tar mycket tid. Tabellen nedan sammanfattar de viktigaste m\u00e4tpunkterna, indikatorerna och typiska <strong>\u00c5tg\u00e4rder<\/strong> tillsammans.<\/p>\n<table>\n  <thead>\n    <tr>\n      <th>M\u00e4tpunkt<\/th>\n      <th>Viktigaste omr\u00e5den\/indikatorer<\/th>\n      <th>tolkning<\/th>\n      <th>\u00c5tg\u00e4rd<\/th>\n    <\/tr>\n  <\/thead>\n  <tbody>\n    <tr>\n      <td>\/proc\/softirqs<\/td>\n      <td>NET_RX, NET_TX, BLOCK vardera <strong>CPU<\/strong><\/td>\n      <td>Oj\u00e4mn lastf\u00f6rdelning kan konstateras<\/td>\n      <td>Justera IRQ-affinitet, aktivera RSS<\/td>\n    <\/tr>\n    <tr>\n      <td>\/proc\/net\/softnet_stat<\/td>\n      <td>Budget-\/drop-r\u00e4knare, tredje <strong>Kolumn<\/strong><\/td>\n      <td>Budgeten \u00e4r f\u00f6r liten, paketen blir liggande<\/td>\n      <td>\u00d6ka netdev_budget\/usecs, kontrollera RPS<\/td>\n    <\/tr>\n    <tr>\n      <td>\/proc\/avbrott<\/td>\n      <td>IRQ-Lines pro <strong>CPU<\/strong>, k\u00f6mappning<\/td>\n      <td>F\u00f6r m\u00e5nga IRQ:er p\u00e5 f\u00f6r f\u00e5 k\u00e4rnor<\/td>\n      <td>Kontrollera irqbalance, st\u00e4lla in smp_affinity<\/td>\n    <\/tr>\n    <tr>\n      <td>mpstat \/ perf<\/td>\n      <td>%soft, Hotspots, <strong>Staplar<\/strong><\/td>\n      <td>Dominerande handtag och k\u00e4rnor synliga<\/td>\n      <td>Prioritera optimering av drivrutiner och stackar<\/td>\n    <\/tr>\n  <\/tbody>\n<\/table>\n\n<h2>Orsaker och m\u00f6nster bakom h\u00f6g belastning<\/h2>\n<p>Spetsar uppst\u00e5r ofta p\u00e5 grund av mycket h\u00f6g <strong>Genomstr\u00f6mning<\/strong>, m\u00e5nga parallella anslutningar eller UDP-bursts som dominerar NET_RX. Ibland \u00e4r standardinst\u00e4llningarna i drivrutinerna inst\u00e4llda p\u00e5 sm\u00e5 batcher, vilket leder till f\u00f6r m\u00e5nga avbrott och \u00f6verbelastar ksoftirqd, medan GRO\/LRO f\u00f6rblir outnyttjade <strong>kvarlevor<\/strong>. Ogynnsamma affiniteter koncentrerar belastningen till CPU 0, trots att flera k\u00f6er skulle vara tillg\u00e4ngliga och RSS skulle kunna underl\u00e4tta f\u00f6rdelningen. I virtuella maskiner belastar vNIC:er v\u00e4rdk\u00e4rnan, vilket \u00f6kar SoftIRQ-tiderna i v\u00e4rden p\u00e5 bekostnad av g\u00e4sterna <strong>\u00f6kar<\/strong>. Container-overlays l\u00e4gger till ytterligare paket i stacken, vilket g\u00f6r att enkla fl\u00f6den pl\u00f6tsligt blir mer kr\u00e4vande v\u00e4gar. Det \u00e4r f\u00f6rst kombinationen av f\u00f6rdelning, budget och <strong>Batchning<\/strong> ger en helhetsbild.<\/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\/09\/linux_softirq_meeting_8593.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>M\u00e5lmedveten \u00f6vervakning: synligg\u00f6ra SoftIRQ:er<\/h2>\n<p>F\u00f6r att kunna bedriva en h\u00e5llbar \u00f6vervakning l\u00e4ser jag regelbundet <strong>\/proc<\/strong>-gr\u00e4nssnitt och kopplar dem till v\u00e4rdmetriker som belastning och schemal\u00e4ggningsf\u00f6rdr\u00f6jningar. Jag korrelerar \u00f6kningar i NET_RX med antalet tappade paket f\u00f6r att avg\u00f6ra om det bara \u00e4r genomstr\u00f6mningen som \u00f6kar eller om paket g\u00e5r f\u00f6rlorade l\u00e4ngs v\u00e4gen <strong>stanna<\/strong>. mpstat visar tidsf\u00f6rdelningen f\u00f6r SoftIRQ:er per CPU, medan top\/htop visar de i\u00f6gonfallande ksoftirqd\/cpuN-tr\u00e5darna. Med perf record\/perf top identifierar jag resurskr\u00e4vande processer, till exempel avlastning av kontrollsummor, GRO-sammanslagning eller <strong>qdisc<\/strong>-Arbete. eBPF- eller ftrace-baserade sp\u00e5rningar visar n\u00e4r hanterarna startar och avslutas, vilket g\u00f6r att jag kan utv\u00e4rdera hanterarnas k\u00f6rtider och schemal\u00e4ggningseffekter. P\u00e5 s\u00e5 s\u00e4tt f\u00e5r jag en tydlig \u00f6verblick utifr\u00e5n m\u00e4tv\u00e4rden, tidsf\u00f6rlopp och <strong>Hotspots<\/strong>.<\/p>\n\n<h2>Justering med netdev_budget och netdev_budget_usecs<\/h2>\n<p>Om NAPI-v\u00e4gen inte r\u00e4cker till \u00f6kar jag stegvis <strong>net.core.netdev_budget<\/strong> och net.core.netdev_budget_usecs, f\u00f6r att kunna bearbeta fler paket per avfr\u00e5gningscykel. Jag h\u00e5ller d\u00e5 koll p\u00e5 den tredje kolumnen i \/proc\/net\/softnet_stat; om \u00f6kningen avtar inneb\u00e4r det att \u00e4ndringarna har gett \u00f6nskad effekt och att latenserna blir <strong>kortare<\/strong>. Jag h\u00f6jer v\u00e4rdena m\u00e5ttligt, till exempel fr\u00e5n 300 till 600 paket och fr\u00e5n 2000 till 4000 mikrosekunder, och kontrollerar om andra uppgifter fortfarande f\u00e5r tillr\u00e4ckligt med CPU-tid. F\u00f6r mycket blockerar schemal\u00e4ggaren, varf\u00f6r jag noggrant \u00f6vervakar belastningstoppar, kontextbyten och l\u00e4ngden p\u00e5 k\u00f6rk\u00f6n <strong>f\u00f6lj med<\/strong>. Dessutom \u00e4r det v\u00e4rt att kontrollera RPS\/RFS, GRO\/LRO och MTU f\u00f6r att kunna utnyttja batchning och paketstorlekar p\u00e5 ett effektivt s\u00e4tt. F\u00f6r att minska antalet avbrott tar jag h\u00e4nsyn till <a href=\"https:\/\/webhosting.de\/sv\/avbrott-koalescens-naetverksoptimering-serverflux\/\">Sammanslagning av avbrott<\/a> och justera motsvarande inst\u00e4llningar med NIC-drivrutinerna, om den h\u00e4r reglaget \u00e4r tillg\u00e4ngligt <strong>\u00e4r<\/strong>.<\/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\/09\/linux-softirq-analyse-optimierung-4738.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Optimera f\u00f6rdelningen av avbrott och IRQ-affinitet<\/h2>\n<p>F\u00f6r att undvika flaskhalsar i en enda k\u00e4rna f\u00f6rdelar jag IRQ:er p\u00e5 flera <strong>Processorer<\/strong>, antingen via irqbalance eller med manuella smp_affinity-masker. D\u00e5 utg\u00e5r jag fr\u00e5n de befintliga NIC-k\u00f6erna och aktiverar RSS, s\u00e5 att h\u00e5rdvaran f\u00f6rdelar inkommande fl\u00f6den j\u00e4mnt och varje k\u00e4rna f\u00e5r arbetsunderl\u00e4ttande <strong>Batcher<\/strong> f\u00e5r. Jag ser till att inte blanda ihop styr-IRQ:er med kritiska datav\u00e4gar f\u00f6r att uppr\u00e4tth\u00e5lla cache-lokalitet och planerbarhet. Korrekt inst\u00e4llda affiniteter minskar latenser och minskar bortfall, eftersom efterbearbetningen av SoftIRQ inte l\u00e4ngre fastnar p\u00e5 en k\u00e4rna <strong>kvarlevor<\/strong>. Drivrutinerna visar ofta kopplingarna mellan k\u00f6er och CPU:er i sysfs; d\u00e4r kontrollerar jag om varje k\u00f6 har en passande k\u00e4rna och att inga asymmetrier uppst\u00e5r. F\u00f6r en mer ing\u00e5ende analys utg\u00e5r jag fr\u00e5n riktlinjer som <a href=\"https:\/\/webhosting.de\/sv\/server-irq-affinity-multicore-naetverksoptimering-prestanda\/\">IRQ-affinitet<\/a>, f\u00f6r att \u00e4ven beakta NUMA-aspekter och cache-effekter <strong>beakta<\/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\/09\/linux_softirq_optimierung_2793.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Praktisk handbok: Fr\u00e5n symptom till l\u00f6sning<\/h2>\n<p>Till att b\u00f6rja med kontrollerar jag symptomen: ksoftirqd\/cpuN i top, andelen SoftIRQ per k\u00e4rna i <strong>mpstat<\/strong> och p\u00e5fallande NET_RX-toppar. D\u00e4refter samlar jag in konkreta fakta fr\u00e5n \/proc\/softirqs, \/proc\/net\/softnet_stat och \/proc\/interrupts f\u00f6r att kartl\u00e4gga dominerande v\u00e4gar och skeva f\u00f6rdelningar. D\u00e4refter genomf\u00f6r jag sm\u00e5 finjusteringar, f\u00f6rst av netdev-budgetarna, f\u00f6ljt av IRQ-affinitet och RSS, i b\u00e5da fallen med noggrann <strong>Kontroll<\/strong>. Om f\u00f6rluster fortfarande syns kontrollerar jag drivrutinsinst\u00e4llningar, coalescing-alternativ, avlastningar och GRO\/LRO-beteende. I VM- eller container-v\u00e4rdar utv\u00e4rderar jag dessutom hur vNIC:erna interagerar med den fysiska v\u00e4rdstacken och var <strong>Hotspots<\/strong> verkligen ligger. Jag utv\u00e4rderar varje f\u00f6r\u00e4ndring utifr\u00e5n tidsserier tills nyckeltalen och latenserna har stabiliserats p\u00e5 en bra niv\u00e5 <strong>land<\/strong>.<\/p>\n\n<h2>B\u00e4sta praxis f\u00f6r h\u00e5llbar prestanda<\/h2>\n<p>Jag inf\u00f6r regelbunden \u00f6vervakning av SoftIRQ-r\u00e4knarna, eftersom endast konstanta <strong>\u00d6ppenhet<\/strong> f\u00f6rhindrar att flaskhalsar \u00e5terkommer. Aktuella k\u00e4rnversioner l\u00f6nar sig eftersom NAPI och stacken f\u00f6rb\u00e4ttras internt, vilket skapar reserver f\u00f6r tunga <strong>Belastningar<\/strong> skapa. En balanserad f\u00f6rdelning \u00f6ver flera k\u00e4rnor \u00e4r fortfarande ett m\u00e5ste, liksom v\u00e4l avv\u00e4gda budgetar som h\u00e4mtar tillr\u00e4ckligt m\u00e5nga paket utan att \u00f6verbelasta schemal\u00e4ggaren. F\u00f6r hostingprofiler med mycket HTTPS- och API-trafik l\u00f6nar det sig att ta en titt p\u00e5 <a href=\"https:\/\/webhosting.de\/sv\/softirq-cpu-hosting-naetverk-genomstroemning-optimering-datacenter\/\">SoftIRQ vid webbhotell<\/a>, eftersom det d\u00e4r framg\u00e5r hur mycket valet av n\u00e4tverkskort, k\u00f6er och finjustering f\u00f6rb\u00e4ttrar tj\u00e4nstekvaliteten. Vid kapacitetsplaneringen tar jag h\u00e4nsyn till CPU-k\u00e4rnor, n\u00e4tverkskortens funktioner, minne och NUMA-zoner, s\u00e5 att det finns reserver innan <strong>Tips<\/strong> intr\u00e4ffa. P\u00e5 s\u00e5 s\u00e4tt f\u00f6rblir plattformen stabil och reagerar smidigt p\u00e5 s\u00e4songs- eller kampanjrelaterade <strong>Trafiktoppar<\/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\/09\/linux_softirq_analyse_4839.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>softnet_stat i detalj: Vad siffrorna egentligen betyder<\/h2>\n<p>F\u00f6r att f\u00f6rfina mina kunskaper l\u00e4ser jag <strong>\/proc\/net\/softnet_stat<\/strong> under processens g\u00e5ng och tolka s\u00e4rskilt de f\u00f6rsta kolumnerna. De f\u00f6rsta f\u00e4lten visar antalet bearbetade och avvisade paket per CPU, vilka <strong>tredje kolumnen<\/strong> pekar p\u00e5 tidspress (kort sagt: f\u00f6r liten budget\/f\u00f6r kort tidsram, NAPI m\u00e5ste avbryta). Om avbrotten eller tidspressen \u00f6kar linj\u00e4rt med belastningen \u00e4r budgetar eller coalescing de f\u00f6rsta \u00e5tg\u00e4rderna. Om jag d\u00e4remot ser toppar utan varaktig \u00f6kning, s\u00e5 komprimerar bursts bara arbetet p\u00e5 kort sikt \u2013 d\u00e5 hj\u00e4lper batching (GRO) oftare \u00e4n stora budgetar. Nyare k\u00e4rnor ut\u00f6kar statistiken med f\u00e4lt f\u00f6r RPS\/RFS och fl\u00f6desgr\u00e4nser; om dessa \u00f6kar f\u00f6rdelar jag arbetet mer medvetet \u00f6ver RPS eller minskar RFS n\u00e4r dess uppslag blir dyrare \u00e4n nyttan. Jag korrelerar alltid r\u00e4knarna med <strong>\/proc\/softirqs<\/strong>: Om NET_RX \u00f6kar p\u00e5 enskilda k\u00e4rnor samtidigt som tidspressen i softnet_stat \u00f6kar, fokuserar jag f\u00f6rst p\u00e5 f\u00f6rdelningen (IRQ\/RSS) och f\u00f6rst i ett andra steg p\u00e5 st\u00f6rre budgetar.<\/p>\n\n<h2>RPS\/RFS och XPS: Full kontroll \u00f6ver programvarustyrning och k\u00f6optimering<\/h2>\n<p>Om det saknas h\u00e5rdvarubaserad RSS eller om den inte r\u00e4cker till, anv\u00e4nder jag <strong>RPS<\/strong> (Receive Packet Steering) f\u00f6r att f\u00f6rdela mottagningsbelastningen p\u00e5 flera k\u00e4rnor. Via rps_cpus tilldelar jag mottagningsk\u00f6erna s\u00e5dana k\u00e4rnor som passar de aktiva arbetarna och, om m\u00f6jligt, <strong>N\u00e4ra till NUMA<\/strong> ligger. I m\u00e5nga fl\u00f6den l\u00e4gger jag till <strong>RFS<\/strong> (Receive Flow Steering), s\u00e5 att inkommande paket hamnar d\u00e4r de tillh\u00f6rande socklarna bearbetas \u2013 bra f\u00f6r cache-lokaliteten, s\u00e5 l\u00e4nge fl\u00f6destabellerna inte blir en flaskhals. P\u00e5 s\u00e4ndarsidan hj\u00e4lper <strong>XPS<\/strong> (Transmit Packet Steering), att anpassa valet av TX-k\u00f6 till applikationens CPU-bindning. M\u00e5let \u00e4r att ett fl\u00f6de konsekvent ska g\u00e5 via samma RX\/TX-k\u00f6 och samma k\u00e4rna, vilket minskar latensen och <strong>GRO<\/strong>-Batcharna blir st\u00f6rre. Jag testar alltid f\u00f6rdelningar stegvis: f\u00f6rst aktiverar jag RPS p\u00e5 ett f\u00e5tal k\u00f6er, m\u00e4ter effekten (bortfall, %soft, latenser) och l\u00e4gger sedan till RFS\/XPS. Om k\u00e4rnorna blir \u00f6verbelastade av RPS eller om L3-tr\u00e4fffrekvensen f\u00f6rs\u00e4mras, minskar jag CPU-maskerna igen eller kopplar k\u00f6erna n\u00e4rmare k\u00e4rnorna f\u00f6r de ber\u00f6rda tj\u00e4nsterna.<\/p>\n\n<h2>NUMA, CPU-isolering och interaktioner mellan schemal\u00e4ggare<\/h2>\n<p>\u00c4ven de b\u00e4sta budgeterna och f\u00f6rdelningarna hj\u00e4lper f\u00f6ga om minnes\u00e5tkomsterna tar l\u00e5nga NUMA-v\u00e4gar. Jag ser till att NIC-avbrott, NAPI-efterbearbetning och de processer som g\u00f6r f\u00f6rfr\u00e5gningarna i m\u00f6jligaste m\u00e5n sker inom samma <strong>NUMA-dom\u00e4n<\/strong> f\u00f6rblir. I konfigurationer med dedikerade realtids- eller latensk\u00e4rnor isolerar jag dessa med hj\u00e4lp av CPU- och Cgroup-policyer och undviker medvetet att l\u00e5ta SoftIRQ-processer k\u00f6ras d\u00e4r. <strong>ksoftirqd<\/strong> b\u00f6r inte hamna p\u00e5 isolerade k\u00e4rnor, annars hopar sig paket utan att man m\u00e4rker det. Omv\u00e4nt f\u00e5r isolerade k\u00e4rnor inte l\u00e4mnas helt utan IRQ-hantering n\u00e4r de avslutar datav\u00e4gar \u2013 en tydlig affinitet och <strong>St\u00e4dning<\/strong>-En strategi \u00e4r ett m\u00e5ste. F\u00f6r arbetsbelastningar med strikta SLO:er undviker jag alltf\u00f6r aggressiva SCHED_FIFO\/RR-prioriteringar som skulle kunna tr\u00e4nga undan NAPI-k\u00f6rningen. Jag \u00f6vervakar l\u00e4ngden p\u00e5 k\u00f6rk\u00f6erna, uppvaknanden och preemptionsfrekvensen: Om SoftIRQ-tiderna \u00f6kar i takt med att appens interaktivitet v\u00e4xer justerar jag granulariteten och affiniteterna ist\u00e4llet f\u00f6r att generellt h\u00f6ja budgetarna.<\/p>\n\n<h2>qdisc, avlastningar och Busy-Poll: Balansera latens och genomstr\u00f6mning<\/h2>\n<p>P\u00e5 utg\u00e5ngsv\u00e4gen kostar varje <strong>qdisc<\/strong>-CPU-tid. Jag v\u00e4ljer den metod som passar profilen: fq_codel motverkar bufferbloat och j\u00e4mnar ut datastr\u00f6mmar, medan <em>mq<\/em>-varianter av Multi-Queue-NIC:er. Vid ren datagenomstr\u00f6mning p\u00e5 stabila l\u00e4nkar kan en l\u00e4ttare qdisc minimera latensspikar. P\u00e5 ingressen l\u00f6nar det sig att finjustera <strong>GRO\/TSO\/GSO<\/strong>: St\u00f6rre batcher s\u00e4nker SoftIRQ-frekvensen, men \u00f6kar i gr\u00e4nsfall paketets kvarh\u00e5llningstid i stacken. Jag m\u00e4ter om GRO-flush-intervall eller h\u00e5rdvaruavlastningar leder till f\u00f6r stora aggregat som skadar applikationen. F\u00f6r v\u00e4gar d\u00e4r latensen \u00e4r mycket kritisk st\u00e4ller jag in <strong>busy_poll<\/strong> och anv\u00e4nder busy_read i lagom m\u00e4ngd f\u00f6r att aktivt h\u00e4mta paket fr\u00e5n drivrutinen \u2013 men endast under noggrann \u00f6vervakning, s\u00e5 att andra uppgifter inte sv\u00e4lter ut. P\u00e5 samma s\u00e4tt st\u00e4ller jag in <strong>Sammanslagning av avbrott<\/strong> N\u00e4r det g\u00e4ller pl\u00f6tsliga trafik\u00f6kningar: att \u00f6ka mikrosekunderna n\u00e5got f\u00f6rb\u00e4ttrar genomstr\u00f6mningen, men f\u00f6r mycket f\u00f6rdr\u00f6jer ACK-svar och f\u00f6rl\u00e4nger handskakningarna. Det \u00e4r viktigt att utv\u00e4rdera varje f\u00f6r\u00e4ndring separat: simulerade trafik\u00f6kningar, verkliga produktionstoppar och perioder med l\u00e5g belastning uppvisar ofta olika latensprofiler.<\/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\/09\/linux-softirq-analyse-1934.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Diagnoslista och s\u00e4ker \u00e5terst\u00e4llning<\/h2>\n<p>Jag g\u00e5r konsekvent igenom \u00e4ndringar med hj\u00e4lp av en kort checklista: 1) Dokumentera symptomen (ksoftirqd, %soft, Drops). 2) Kontrollera f\u00f6rdelningen (\/proc\/interrupts, Queue-&gt;CPU, RSS\/RPS-status). 3) Justera budgetarna, effekten i <strong>softnet_stat<\/strong> \u00f6vervaka (tidspressen minskar, antalet avbrott stagnerar). 4) Finjustera offloads\/coalescing, granska qdisc. 5) Dubbelkolla NUMA\/CPU-bindningar och cgroups. Varje steg avslutas med en tydlig f\u00f6rb\u00e4ttring av m\u00e4tv\u00e4rdena eller med <strong>Rollback<\/strong> till det senaste godk\u00e4nda l\u00e4get. Jag dokumenterar m\u00e5l- och faktiska v\u00e4rden (latens P95\/P99, %soft per k\u00e4rna, avbrottsfrekvens, kontextbyten) s\u00e5 att senare iterationer inte sker i blindo. Om flera sm\u00e5 f\u00f6rb\u00e4ttringar inte leder till n\u00e5gon avlastning avbryter jag och letar efter strukturella orsaker (k\u00f6flaskhalsar, appblockeringar, lagringsp\u00e5verkan). Denna disciplin f\u00f6rhindrar felaktiga korrelationer och skyddar mot optimeringsspiraler som visserligen \u00f6kar genomstr\u00f6mningen men f\u00f6rs\u00e4mrar interaktiviteten och stabiliteten.<\/p>\n\n<h2>Att tydligt skilja mellan gr\u00e4nsfall och arbetsbelastningsprofiler<\/h2>\n<p>Jag g\u00f6r medvetet skillnad mellan bulk\u00f6verf\u00f6ring, latenskritiska API:er och burstig <strong>UDP<\/strong>-Trafik. F\u00f6r stora datam\u00e4ngder anv\u00e4nder jag batchning och sammanslagning tidigare, s\u00e5 l\u00e4nge det inte f\u00f6rekommer paketf\u00f6rluster. Vid API-trafik prioriterar jag j\u00e4mn f\u00f6rdelning, begr\u00e4nsade batcher och stabila E2E-f\u00f6rdr\u00f6jningar, \u00e4ven om den nominella maximala genomstr\u00f6mningen minskar n\u00e5got. UDP-bursts hanterar jag helst genom k\u00f6utvidgning och affiniteter \u2013 f\u00f6r stora budgetar \u00f6kar annars bara head-of-line-blockering. Om en milj\u00f6 anv\u00e4nder m\u00e5nga container- eller overlay-hopp planerar jag in extra stackarbete och sprider SoftIRQ-belastningen b\u00e4ttre. Jag utv\u00e4rderar dessutom \u00f6verhead f\u00f6r brandv\u00e4ggar och conntrack separat: N\u00e4r tabellerna n\u00e5r sina gr\u00e4nser \u00f6kar SoftIRQ-belastningen oundvikligen, oavsett hur bra IRQ-f\u00f6rdelningen \u00e4r. F\u00f6rst n\u00e4r v\u00e4garna per profil \u00e4r konsekvent smala l\u00f6nar det sig att finjustera de sista procenten.<\/p>\n\n<h2>SoftIRQ:er i moln- och containermilj\u00f6er<\/h2>\n<p>I virtualiserade milj\u00f6er flyttas belastningen via vSwitches, \u00f6verlagringsn\u00e4tverk och v\u00e4rdstackar, vilket \u00e4r anledningen till att jag b\u00e5de g\u00e4st- och v\u00e4rd-<strong>M\u00e4tetal<\/strong> analysera. L\u00e5nga SoftIRQ-tider i v\u00e4rdsystemet bromsar omedelbart ner containrar och virtuella maskiner, \u00e4ven om g\u00e4stsystemen till synes fungerar utan problem <strong>arbete<\/strong>. Jag kontrollerar d\u00e4rf\u00f6r avlastning och sammanslagning p\u00e5 det fysiska n\u00e4tverkskortet, medan RPS\/RFS i v\u00e4rddatorn f\u00f6rdelar mjukvarubanan b\u00e4ttre. F\u00f6r containerbaserade arbetsbelastningar kontrollerar jag om Cgroup-gr\u00e4nserna f\u00f6r CPU och IRQ-efterbearbetning \u00e4r rimligt inst\u00e4llda, s\u00e5 att viktiga tj\u00e4nster inte hamnar i <strong>K\u00f6er<\/strong> sv\u00e4lta ihj\u00e4l. vNIC:er med st\u00f6d f\u00f6r flera k\u00f6er och RSS f\u00f6rb\u00e4ttrar parallelliteten, f\u00f6rutsatt att affiniteterna och k\u00f6mappningarna st\u00e4mmer. Med detta perspektiv h\u00e5ller jag datav\u00e4garna korta och stabiliserar <strong>F\u00f6rdr\u00f6jningar<\/strong> och s\u00e4ker, reproducerbar prestanda.<\/p>\n\n<h2>Sammanfattning: Att beh\u00e4rska SoftIRQ-analys med s\u00e4ker hand<\/h2>\n<p>Den som analyserar SoftIRQ-belastningen p\u00e5 ett korrekt s\u00e4tt anv\u00e4nder tydliga m\u00e4tpunkter, granskar f\u00f6rdelningar och till\u00e4mpar differentierade <strong>Steg<\/strong>. Jag b\u00f6rjar med \/proc\/softirqs och softnet_stat, j\u00e4mf\u00f6r med ksoftirqd och mpstat och fastst\u00e4ller utifr\u00e5n detta ordningen p\u00e5 mina <strong>\u00c5tg\u00e4rder<\/strong>. F\u00f6rst justerar jag netdev_budget och netdev_budget_usecs, d\u00e4refter optimerar jag IRQ-affinitet, RSS samt batchningsalternativ som GRO och offloads. Varje justering \u00e4r liten, m\u00e4ts och forts\u00e4tter endast om den ger en positiv effekt, tills f\u00f6rlusterna f\u00f6rsvinner och <strong>F\u00f6rdr\u00f6jningar<\/strong> minskar. Denna disciplin f\u00f6rhindrar biverkningar, uppr\u00e4tth\u00e5ller interaktiviteten p\u00e5 CPU:n och s\u00e4kerst\u00e4ller att tj\u00e4nsterna fungerar \u00e4ven under trafiktoppar <strong>lyh\u00f6rd<\/strong>. P\u00e5 s\u00e5 s\u00e4tt f\u00f6rblir Linux-prestandan transparent, robust och anpassningsbar, utan att dolda flaskhalsar p\u00e5verkar <strong>Stabilitet<\/strong> \u00e4ventyra.<\/p>","protected":false},"excerpt":{"rendered":"<p>L\u00e4r dig hur du systematiskt analyserar och optimerar Linux SoftIRQ-anv\u00e4ndningen f\u00f6r att \u00f6ka dina servrars Linux-prestanda genom m\u00e5linriktad netdev-inst\u00e4llning och b\u00e4ttre f\u00f6rdelning av avbrott.<\/p>","protected":false},"author":1,"featured_media":21340,"comment_status":"","ping_status":"","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"inline_featured_image":false,"footnotes":""},"categories":[676],"tags":[],"class_list":["post-21347","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":"97","_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":"Linux SoftIRQ","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":"21340","footnotes":null,"_links":{"self":[{"href":"https:\/\/webhosting.de\/sv\/wp-json\/wp\/v2\/posts\/21347","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=21347"}],"version-history":[{"count":0,"href":"https:\/\/webhosting.de\/sv\/wp-json\/wp\/v2\/posts\/21347\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/webhosting.de\/sv\/wp-json\/wp\/v2\/media\/21340"}],"wp:attachment":[{"href":"https:\/\/webhosting.de\/sv\/wp-json\/wp\/v2\/media?parent=21347"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/webhosting.de\/sv\/wp-json\/wp\/v2\/categories?post=21347"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/webhosting.de\/sv\/wp-json\/wp\/v2\/tags?post=21347"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}