{"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":"analisi-del-carico-di-lavoro-dei-softirq-su-linux-ottimizzazione-delle-prestazioni-data-center","status":"publish","type":"post","link":"https:\/\/webhosting.de\/it\/linux-softirq-auslastung-analysieren-performance-tuning-datacenter\/","title":{"rendered":"Analizzare e ottimizzare l'utilizzo dei SoftIRQ su Linux"},"content":{"rendered":"<p>Vi mostrer\u00f2 passo dopo passo come faccio a <strong>SoftIRQ di Linux<\/strong>-misuro il carico di sistema, individuo i colli di bottiglia e riprendo il controllo con poche modifiche al kernel. In questo contesto, do priorit\u00e0 agli effetti misurabili: tempi pi\u00f9 brevi <strong>Latenze<\/strong>, core della CPU bilanciati e elaborazione stabile dei pacchetti in condizioni di elevato carico di rete.<\/p>\n\n<h2>Punti centrali<\/h2>\n<ul>\n  <li><strong>Punti di misura<\/strong> comprendere: \/proc\/softirqs, softnet_stat, interrupts<\/li>\n  <li><strong>Sintomi<\/strong> Rilevare: carico di ksoftirqd, perdita di pacchetti, picchi di latenza<\/li>\n  <li><strong>Sintonizzazione<\/strong> controllare: netdev_budget e netdev_budget_usecs<\/li>\n  <li><strong>Distribuzione<\/strong> Salvare: affinit\u00e0 IRQ, RSS, mappatura delle code<\/li>\n  <li><strong>Monitoraggio<\/strong> eseguire: mpstat, perf, tracciamento<\/li>\n<\/ul>\n\n<h2>Panoramica sugli SoftIRQ: come funziona il kernel<\/h2>\n<p>Dopo un interrupt hardware, il kernel trasferisce parte del lavoro ai cosiddetti <strong>SoftIRQ<\/strong>, in modo che i percorsi critici vengano liberati rapidamente e l'elaborazione rimanga pianificabile. Soprattutto nel percorso di rete, gli handler NAPI raccolgono i pacchetti dagli anelli delle schede di rete, avviano le operazioni di protocollo e trasmettono i dati al <strong>Pila di rete<\/strong>. Se il volume degli eventi aumenta, i thread per CPU come ksoftirqd\/cpuN intervengono e si occupano del polling e delle operazioni di rielaborazione. Questo disaccoppiamento migliora la produttivit\u00e0 complessiva, ma in caso di sovraccarico pu\u00f2 causare tempi di esecuzione dei SoftIRQ prolungati su singoli <strong>Nuclei<\/strong> portare. Per questo motivo controllo tempestivamente se i percorsi NET_RX e NET_TX sono predominanti e se ksoftirqd consuma in modo evidente tempo di CPU. In questo modo riesco a individuare quando gli SoftIRQ diventano un collo di bottiglia e ulteriori <strong>Ottimizzazioni<\/strong> sono necessari.<\/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>Riconoscere i sintomi tipici di un elevato carico di SoftIRQ<\/h2>\n<p>Un carico elevato di SoftIRQ lo noto innanzitutto da un valore costantemente alto <strong>CPU del kernel<\/strong> e i processi ksoftirqd, che mantengono picchi per molti secondi. Parallelmente aumentano le latenze per l'I\/O di rete e a blocchi, il che si traduce in handshake TLS lenti o in un funzionamento fiacco <strong>API<\/strong> ha affermato. Spesso si verificano perdite di pacchetti, mentre gli anelli della scheda di rete vanno in overflow e i backlog aumentano. Se gli interrupt sono distribuiti male, la CPU 0 ne risente spesso in modo significativo, poich\u00e9 molte linee IRQ, insieme al lavoro che ne deriva, si concentrano su un <strong>Nucleo<\/strong> . Questo vincolo a un solo core aumenta i tempi di attesa per i servizi e riduce la larghezza di banda effettiva. Sto quindi verificando se si tratti di un fenomeno sistematico o solo di <strong>Picchi<\/strong> porta.<\/p>\n\n<h2>Punti di misurazione chiave: interpretare correttamente \/proc e gli strumenti<\/h2>\n<p>Comincio da \/proc\/softirqs, perch\u00e9 l\u00ec posso vedere, per ogni CPU e per ogni tipo, quanto sia forte, ad esempio <strong>NET_RX<\/strong>, NET_TX, TIMER o BLOCK aumentano. In \/proc\/net\/softnet_stat controllo le righe concentrandomi sui campi che segnalano budget non rispettati o pacchetti persi, il che, in caso di aumento costante, indica chiaramente che <strong>Cicli di polling<\/strong> indica. \/proc\/interrupts rivela quindi se gli interrupt hardware sono distribuiti in modo diseguale tra le CPU e quali IRQ sono i pi\u00f9 intensi. Strumenti come mpstat, top o htop mi aiutano a identificare ksoftirqd\/cpuN e a determinare la distribuzione dei <strong>Tempi Softirq<\/strong> da valutare per ogni core. Se necessario, perf fornisce gli hotspot nello stack, in modo da poter individuare gli handler e i percorsi dei driver che occupano una quota elevata di tempo. La tabella seguente riassume i principali punti di misurazione, indicatori e tipici <strong>Azioni<\/strong> insieme.<\/p>\n<table>\n  <thead>\n    <tr>\n      <th>Punto di misura<\/th>\n      <th>Campi\/indicatori principali<\/th>\n      <th>Interpretazione<\/th>\n      <th>Azione<\/th>\n    <\/tr>\n  <\/thead>\n  <tbody>\n    <tr>\n      <td>\/proc\/softirqs<\/td>\n      <td>NET_RX, NET_TX, BLOCK ciascuno <strong>CPU<\/strong><\/td>\n      <td>Si nota una distribuzione irregolare del carico<\/td>\n      <td>Regolare l'affinit\u00e0 IRQ, attivare RSS<\/td>\n    <\/tr>\n    <tr>\n      <td>\/proc\/net\/softnet_stat<\/td>\n      <td>Contatore di budget\/drop, terzo <strong>Colonna<\/strong><\/td>\n      <td>Bilanci troppo esigui, i pacchi restano in sospeso<\/td>\n      <td>Aumentare netdev_budget\/usecs, verificare RPS<\/td>\n    <\/tr>\n    <tr>\n      <td>\/proc\/interruzioni<\/td>\n      <td>Linee IRQ per <strong>CPU<\/strong>, mappatura delle code<\/td>\n      <td>Troppi IRQ su pochi core<\/td>\n      <td>Verificare irqbalance, impostare smp_affinity<\/td>\n    <\/tr>\n    <tr>\n      <td>mpstat \/ perf<\/td>\n      <td>%soft, Hotspot, <strong>Pile<\/strong><\/td>\n      <td>Mani e nuclei dominanti visibili<\/td>\n      <td>Dare priorit\u00e0 all'ottimizzazione dei driver e dello stack<\/td>\n    <\/tr>\n  <\/tbody>\n<\/table>\n\n<h2>Cause e andamenti dei carichi elevati<\/h2>\n<p>Le punte si formano spesso a causa di un livello molto elevato di <strong>Produttivit\u00e0<\/strong>, molte connessioni parallele o burst UDP che dominano NET_RX. A volte le impostazioni predefinite dei driver prevedono piccoli batch, il che genera un numero eccessivo di interrupt e sovraccarica ksoftirqd, mentre GRO\/LRO rimangono inutilizzati <strong>resti<\/strong>. Affinit\u00e0 sfavorevoli concentrano il carico di lavoro sulla CPU 0, sebbene siano disponibili pi\u00f9 code e l\u2019RSS potrebbe facilitare la distribuzione. Nelle macchine virtuali, le vNIC sovraccaricano il kernel host, il che comporta un aumento dei tempi di SoftIRQ nell\u2019host a scapito degli ospiti <strong>aumenta<\/strong>. Gli overlay dei container aggiungono ulteriori pacchetti allo stack, trasformando cos\u00ec flussi leggeri in percorsi improvvisamente pi\u00f9 complessi. Solo la combinazione di distribuzione, budget e <strong>Dosaggio<\/strong> offre un quadro completo.<\/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>Monitoraggio mirato: rendere visibili gli SoftIRQ<\/h2>\n<p>Per un monitoraggio efficace, leggo regolarmente <strong>\/proc<\/strong>-Interfacce e le collego alle metriche dell'host, come il carico e le latenze di schedulazione. Metto in correlazione gli aumenti di NET_RX con i contatori di pacchetti persi per capire se sta aumentando solo il throughput o se i pacchetti vanno persi lungo il percorso <strong>soggiorno<\/strong>. mpstat mi fornisce, per ogni CPU, le percentuali di tempo dedicate agli SoftIRQ, mentre top\/htop mostrano i thread ksoftirqd\/cpuN che saltano all\u2019occhio. Con perf record\/perf top isolo i percorsi costosi, ad esempio l\u2019offload dei checksum, l\u2019unione GRO o <strong>qdisc<\/strong>-Lavoro. Le tracce basate su eBPF o ftrace mostrano l\u2019inizio e la fine degli handler, consentendomi di valutare i tempi di esecuzione degli handler e gli effetti della schedulazione. In questo modo si ottiene un quadro chiaro della situazione grazie a metriche, andamenti temporali e <strong>Hotspot<\/strong>.<\/p>\n\n<h2>Ottimizzazione con netdev_budget e netdev_budget_usecs<\/h2>\n<p>Se il percorso NAPI risulta troppo breve, lo allungo gradualmente <strong>net.core.netdev_budget<\/strong> e net.core.netdev_budget_usecs, per elaborare un maggior numero di pacchetti per ciclo di polling. A tal fine osservo la terza colonna in \/proc\/net\/softnet_stat; se l\u2019incremento diminuisce, le modifiche vanno a segno e le latenze vengono <strong>pi\u00f9 breve<\/strong>. Aumento moderatamente i valori, ad esempio da 300 a 600 pacchetti e da 2000 a 4000 microsecondi, e verifico che le altre attivit\u00e0 conservino una quantit\u00e0 sufficiente di tempo di CPU. Un carico eccessivo blocca lo scheduler, motivo per cui tengo sotto stretto controllo i picchi di carico, i cambi di contesto e la lunghezza delle code di esecuzione <strong>accompagna<\/strong>. Inoltre, vale la pena verificare i valori di RPS\/RFS, GRO\/LRO e MTU per sfruttare in modo ottimale il batching e le dimensioni dei pacchetti. Per ridurre il numero di interrupt, tengo conto di <a href=\"https:\/\/webhosting.de\/it\/interruzione-della-coalescenza-ottimizzazione-della-rete-serverflux\/\">Interruzione della coalescenza<\/a> e regola le stesse impostazioni con i driver NIC, se questa opzione \u00e8 disponibile <strong>\u00e8<\/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>Ottimizzazione della distribuzione degli interrupt e dell\u2019affinit\u00e0 IRQ<\/h2>\n<p>Per evitare colli di bottiglia a singolo core, distribuisco gli IRQ su pi\u00f9 <strong>CPU<\/strong>, tramite irqbalance oppure con maschere smp_affinity manuali. A tal fine mi baso sulle code delle schede di rete esistenti e attivo RSS, in modo che l\u2019hardware distribuisca uniformemente i flussi in entrata e ogni core possa beneficiare di un carico di lavoro pi\u00f9 leggero <strong>batch<\/strong> riceve. Faccio attenzione a non mescolare gli IRQ di controllo con i percorsi di dati ad alto traffico, per preservare la localit\u00e0 della cache e la pianificabilit\u00e0. Le affinit\u00e0 impostate correttamente riducono le latenze e diminuiscono le perdite, poich\u00e9 l\u2019elaborazione successiva degli SoftIRQ non rimane pi\u00f9 bloccata su un singolo core <strong>resti<\/strong>. I driver spesso mostrano le associazioni tra code e CPU in sysfs; l\u00ec verifico che ogni coda abbia un kernel corrispondente e che non si verifichino asimmetrie. Per un\u2019analisi pi\u00f9 approfondita, mi baso su guide come <a href=\"https:\/\/webhosting.de\/it\/server-irq-affinita-multicore-ottimizzazione-delle-prestazioni-di-rete\/\">Affinit\u00e0 IRQ<\/a>, per tenere conto anche degli aspetti NUMA e dell'effetto cache <strong>tenere conto<\/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>Guida pratica: dai sintomi alla soluzione<\/h2>\n<p>Per prima cosa verifico i sintomi: ksoftirqd\/cpuN in top, percentuali di SoftIRQ per ciascun core in <strong>mpstat<\/strong> e picchi evidenti di NET_RX. Successivamente raccolgo dati concreti da \/proc\/softirqs, \/proc\/net\/softnet_stat e \/proc\/interrupts per individuare i percorsi dominanti e le distribuzioni sbilanciate. Successivamente, applico piccoli interventi di ottimizzazione, iniziando dai budget netdev, seguiti dall\u2019affinit\u00e0 IRQ e dall\u2019RSS, in ciascun caso con un monitoraggio minuzioso <strong>Controllo<\/strong>. Se i \u201cdrops\u201d rimangono visibili, controllo le impostazioni dei driver, le opzioni di coalescing, gli offload e il comportamento di GRO\/LRO. Negli host di macchine virtuali o container, valuto inoltre come le vNIC interagiscono con lo stack fisico dell\u2019host e dove i <strong>Hotspot<\/strong> effettivamente. Valuto ogni modifica sulla base di serie temporali, finch\u00e9 le metriche e le latenze non si stabilizzano a un buon livello <strong>terra<\/strong>.<\/p>\n\n<h2>Migliori pratiche per una performance sostenibile<\/h2>\n<p>Implemento un monitoraggio regolare dei contatori SoftIRQ, poich\u00e9 solo valori costanti <strong>Trasparenza<\/strong> impedisce il ripetersi dei colli di bottiglia. Le versioni attuali del kernel sono vantaggiose perch\u00e9 NAPI e lo stack vengono ulteriormente migliorati internamente, creando cos\u00ec riserve per le situazioni pi\u00f9 difficili <strong>Carichi<\/strong> creare. \u00c8 fondamentale garantire una distribuzione equilibrata su pi\u00f9 core, cos\u00ec come budget ragionevoli che gestiscano un numero sufficiente di pacchetti senza sovraccaricare lo scheduler. Per i profili di hosting con un traffico HTTPS e API intenso, vale la pena dare un\u2019occhiata a <a href=\"https:\/\/webhosting.de\/it\/softirq-cpu-hosting-rete-ottimizzazione-del-throughput-datacenter\/\">SoftIRQ nell'hosting<\/a>, poich\u00e9 \u00e8 proprio l\u00ec che si vede quanto la scelta delle schede di rete (NIC), delle code e dell'ottimizzazione migliori la qualit\u00e0 del servizio. Nella pianificazione della capacit\u00e0 tengo conto dei core della CPU, delle funzionalit\u00e0 delle schede di rete (NIC), della memoria e delle zone NUMA, in modo che ci siano riserve disponibili prima che <strong>Suggerimenti<\/strong> raggiungere. In questo modo la piattaforma rimane robusta e reagisce in modo ottimale alle variazioni stagionali o legate alle campagne <strong>Ore di punta<\/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 in dettaglio: cosa significano davvero i numeri<\/h2>\n<p>Per affinare le mie conoscenze in modo mirato, leggo <strong>\/proc\/net\/softnet_stat<\/strong> nel corso dell'elaborazione e interpreta in particolare le prime colonne. Le celle iniziali riportano il numero di pacchetti elaborati e scartati per ciascuna CPU, mentre <strong>terza colonna<\/strong> indica una pressione temporale (in breve: budget\/tempo a disposizione insufficienti, NAPI deve interrompere l\u2019operazione). Se i drop o la pressione temporale crescono in modo lineare con il carico, i budget o il coalescing sono le prime leve da utilizzare. Se invece osservo picchi senza un aumento sostenuto, i burst concentrano il lavoro solo a breve termine: in tal caso, il batching (GRO) \u00e8 pi\u00f9 efficace di budget elevati. I kernel pi\u00f9 recenti ampliano le statistiche con campi per RPS\/RFS e limiti di flusso; se questi aumentano, distribuisco in modo pi\u00f9 consapevole tramite RPS o riduco l\u2019RFS quando le sue ricerche diventano pi\u00f9 costose dei benefici che apportano. Correlando sempre i contatori con <strong>\/proc\/softirqs<\/strong>: Se NET_RX aumenta su singoli core contemporaneamente a un aumento della pressione temporale in softnet_stat, mi concentro innanzitutto sulla distribuzione (IRQ\/RSS) e solo in un secondo momento su budget pi\u00f9 elevati.<\/p>\n\n<h2>RPS\/RFS e XPS: gestione dello steering del software e ottimizzazione delle code sotto controllo<\/h2>\n<p>Se l'RSS hardware manca o non \u00e8 sufficiente, imposto <strong>RPS<\/strong> (Receive Packet Steering), per distribuire il carico di ricezione su pi\u00f9 core. Tramite rps_cpus assegno alle code di ricezione quei core che corrispondono ai worker attivi e, se possibile, <strong>Vicino a NUMA<\/strong> si trovano. In molti flussi aggiungo <strong>RFS<\/strong> (Receive Flow Steering), affinch\u00e9 i pacchetti in entrata arrivino proprio dove vengono elaborati i socket corrispondenti \u2013 utile per la localit\u00e0 della cache, purch\u00e9 le tabelle di flusso non diventino un collo di bottiglia. Dal lato di invio, aiuta <strong>XPS<\/strong> (Transmit Packet Steering), ovvero adeguare la scelta della coda TX al binding della CPU dell'applicazione. L'obiettivo \u00e8 che un flusso passi in modo coerente attraverso la stessa coda RX\/TX e lo stesso kernel, riducendo cos\u00ec le latenze e <strong>GRO<\/strong>-I batch diventano pi\u00f9 grandi. Testo sempre le distribuzioni in modo graduale: prima attivo l\u2019RPS su poche code, misuro l\u2019effetto (drops, %soft, latenze), poi aggiungo RFS\/XPS. Se i core vengono sovraccaricati dall\u2019RPS o se l\u2019L3-Hitrate peggiora, riduco nuovamente le maschere CPU oppure associo le code in modo pi\u00f9 stretto ai core dei servizi interessati.<\/p>\n\n<h2>NUMA, isolamento delle CPU e interazioni tra scheduler<\/h2>\n<p>Anche i migliori budget e le migliori distribuzioni servono a poco se gli accessi alla memoria percorrono lunghe distanze NUMA. Mi assicuro che gli interrupt della scheda di rete, l\u2019elaborazione NAPI e i processi richiedenti si trovino, per quanto possibile, all\u2019interno della stessa <strong>Dominio NUMA<\/strong> rimangono. Nelle configurazioni con core dedicati in tempo reale o a bassa latenza, li isolo tramite policy relative alla CPU e ai cgroup, evitando deliberatamente di farvi eseguire operazioni SoftIRQ. <strong>ksoftirqd<\/strong> non dovrebbe finire su core isolati, altrimenti i pacchetti si accumulano senza che ce ne si accorga. D\u2019altra parte, i core isolati non devono rimanere completamente privi di gestione degli IRQ quando terminano i percorsi dei dati \u2013 una chiara affinit\u00e0 e <strong>Servizi di pulizia<\/strong>-La strategia \u00e8 fondamentale. Per i carichi di lavoro con SLO rigorosi, evito priorit\u00e0 SCHED_FIFO\/RR eccessivamente aggressive che potrebbero sovrascrivere l\u2019esecuzione NAPI. Monitoro le lunghezze delle code di esecuzione, i wakeup e i tassi di preemption: se i tempi degli SoftIRQ aumentano con la crescente interattivit\u00e0 dell\u2019app, regolo la granularit\u00e0 e le affinit\u00e0, invece di aumentare i budget in modo indiscriminato.<\/p>\n\n<h2>qdisc, offload e Busy-Poll: bilanciare latenza e throughput<\/h2>\n<p>Sul percorso di uscita, ogni <strong>qdisc<\/strong>-Tempo di esecuzione della CPU. Scelgo la disciplina pi\u00f9 adatta al profilo: fq_codel aiuta a risolvere il problema del \"puffer bloat\" e smussa i picchi, mentre <em>mq<\/em>-varianti delle schede di rete multi-queue. In caso di puro throughput su collegamenti stabili, un qdisc pi\u00f9 leggero pu\u00f2 ridurre al minimo i picchi di latenza. Sull'ingresso, vale la pena ottimizzare <strong>GRO\/TSO\/GSO<\/strong>: I batch pi\u00f9 grandi riducono la frequenza degli SoftIRQ, ma in casi limite aumentano il tempo di permanenza dei pacchetti nello stack. Verifico se gli intervalli di flush GRO o gli offload hardware generano aggregati troppo grandi che danneggiano l'applicazione. Per i percorsi in cui la latenza \u00e8 fondamentale, imposto <strong>busy_poll<\/strong> e utilizzo `busy_read` con moderazione per estrarre attivamente i pacchetti dal driver \u2013 ma solo tenendo tutto sotto stretto controllo, affinch\u00e9 le altre attivit\u00e0 non rimangano a corto di risorse. Allo stesso modo, mi allineo <strong>Interruzione della coalescenza<\/strong> In caso di picchi di traffico: aumentare la durata di un po' in microsecondi migliora la velocit\u00e0 effettiva, ma un aumento eccessivo ritarda gli ACK e allunga gli handshake. \u00c8 importante valutare separatamente ogni modifica: i picchi simulati, i veri picchi di produzione e i periodi di inattivit\u00e0 presentano spesso profili di latenza diversi.<\/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>Lista di controllo per la diagnosi e rollback sicuro<\/h2>\n<p>Quando apporto delle modifiche, seguo sistematicamente una breve lista di controllo: 1) Verificare i sintomi (ksoftirqd, %soft, Drops). 2) Verificare la distribuzione (\/proc\/interrupts, Queue-&gt;CPU, stato RSS\/RPS). 3) Regolare i budget, valutare l\u2019effetto in <strong>softnet_stat<\/strong> monitorare (la pressione temporale diminuisce, i drop ristagnano). 4) Regolare con precisione gli offload\/coalescing, controllare il qdisc. 5) Ricontrollare le associazioni NUMA\/CPU e i cgroup. Ogni fase si conclude con un netto miglioramento delle metriche o con il <strong>Rollback<\/strong> all'ultimo stato ottimale. Documento i valori target e quelli effettivi (latenza P95\/P99, %soft per core, tassi di drop, cambi di contesto), in modo che le iterazioni successive non avvengano alla cieca. Se una serie di piccoli miglioramenti non porta ad un alleggerimento del carico, interrompo il processo e cerco le cause strutturali (colli di bottiglia nelle code, blocchi dell\u2019applicazione, influenze dello storage). Questa disciplina impedisce correlazioni errate e protegge dalle spirali di ottimizzazione che, pur aumentando i valori di throughput, compromettono l\u2019interattivit\u00e0 e la stabilit\u00e0.<\/p>\n\n<h2>Distinguere chiaramente i casi limite e i profili di carico di lavoro<\/h2>\n<p>Distinguo volutamente tra trasferimento in blocco, API sensibili alla latenza e traffico a picchi <strong>UDP<\/strong>-Traffico. Per i dati in blocco, ricorro prima al batching e al coalescing, purch\u00e9 non si verifichino perdite di pacchetti. Nel traffico API, do priorit\u00e0 a una distribuzione uniforme, a batch limitati e a latenze E2E stabili, anche se la velocit\u00e0 massima nominale dovesse diminuire leggermente. Preferisco contrastare i burst UDP tramite l\u2019ampliamento delle code e le affinit\u00e0; altrimenti, budget troppo elevati aumentano solo l\u2019head-of-line blocking. Se un ambiente utilizza molti hop di container o overlay, pianifico un carico di lavoro aggiuntivo per lo stack e distribuisco il carico SoftIRQ in modo pi\u00f9 ampio. Valuto inoltre separatamente gli overhead di firewall\/Conntrack: quando le tabelle raggiungono i propri limiti, il carico di SoftIRQ aumenta inevitabilmente, indipendentemente da quanto sia ottimale la distribuzione degli IRQ. Solo quando i percorsi per ciascun profilo sono costantemente snelli, vale la pena ottimizzare gli ultimi punti percentuali.<\/p>\n\n<h2>SoftIRQ negli ambienti cloud e container<\/h2>\n<p>Negli scenari virtualizzati, il carico si sposta attraverso vSwitch, reti overlay e stack host, motivo per cui devo considerare sia l'ospite che l'host-<strong>Metriche<\/strong> Analizza. Tempi elevati di SoftIRQ nell'host rallentano immediatamente i container e le VM, anche se i sistemi guest sembrano funzionare senza problemi <strong>lavoro<\/strong>. Verifico quindi gli offload e il coalescing sulla scheda di rete fisica, mentre RPS\/RFS nell\u2019host distribuisce meglio il carico sul percorso software. Per i carichi di lavoro dei container, controllo che i limiti dei cgroup per la CPU e la gestione degli IRQ siano impostati in modo appropriato, in modo che i servizi importanti non finiscano in <strong>Code<\/strong> morire di fame. Le vNIC con supporto multi-queue e RSS migliorano il parallelismo, a condizione che le affinit\u00e0 e le mappature delle code siano corrette. Con questa prospettiva, mantengo brevi i percorsi dei dati e stabilizzo <strong>Latenze<\/strong> e prestazioni affidabili e riproducibili.<\/p>\n\n<h2>Sintesi: Padroneggiare con sicurezza l\u2019analisi degli SoftIRQ<\/h2>\n<p>Chi analizza accuratamente il carico degli SoftIRQ utilizza punti di misurazione chiari, esamina le distribuzioni e imposta valori graduali <strong>Passi<\/strong>. Comincio da \/proc\/softirqs e softnet_stat, stabilisco una correlazione con ksoftirqd e mpstat e ne deduco l'ordine dei miei <strong>Misure<\/strong>. Per prima cosa regolo netdev_budget e netdev_budget_usecs, poi ottimizzo l\u2019affinit\u00e0 IRQ, l\u2019RSS e le opzioni di batching come GRO e gli offload. Ogni intervento \u00e8 di entit\u00e0 limitata, viene misurato e proseguito solo se produce un effetto positivo, finch\u00e9 i drop non scompaiono e <strong>Latenze<\/strong> diminuire. Questa disciplina previene gli effetti collaterali, mantiene l'interattivit\u00e0 sulla CPU e garantisce il funzionamento dei servizi anche durante i picchi di traffico <strong>reattivo<\/strong>. In questo modo, le prestazioni di Linux rimangono trasparenti, affidabili e personalizzabili, senza che punti critici nascosti possano <strong>Stabilit\u00e0<\/strong> mettere a rischio.<\/p>","protected":false},"excerpt":{"rendered":"<p>Scopri come analizzare e ottimizzare sistematicamente l'utilizzo degli SoftIRQ in Linux per migliorare le prestazioni dei tuoi server grazie a una messa a punto mirata di netdev e a una migliore distribuzione degli interrupt.<\/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":"93","_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\/it\/wp-json\/wp\/v2\/posts\/21347","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/webhosting.de\/it\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/webhosting.de\/it\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/webhosting.de\/it\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/webhosting.de\/it\/wp-json\/wp\/v2\/comments?post=21347"}],"version-history":[{"count":0,"href":"https:\/\/webhosting.de\/it\/wp-json\/wp\/v2\/posts\/21347\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/webhosting.de\/it\/wp-json\/wp\/v2\/media\/21340"}],"wp:attachment":[{"href":"https:\/\/webhosting.de\/it\/wp-json\/wp\/v2\/media?parent=21347"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/webhosting.de\/it\/wp-json\/wp\/v2\/categories?post=21347"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/webhosting.de\/it\/wp-json\/wp\/v2\/tags?post=21347"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}