{"id":21042,"date":"2026-08-27T08:32:23","date_gmt":"2026-08-27T06:32:23","guid":{"rendered":"https:\/\/webhosting.de\/irq-balance-linux-konfigurieren-server\/"},"modified":"2026-08-27T08:32:23","modified_gmt":"2026-08-27T06:32:23","slug":"configurare-lirq-balance-su-linux-per-un-server","status":"publish","type":"post","link":"https:\/\/webhosting.de\/it\/irq-balance-linux-konfigurieren-server\/","title":{"rendered":"Come configurare correttamente l'IRQ Balance su Linux: guida pratica"},"content":{"rendered":"<p>In Linux, IRQ Balance gestisce la distribuzione degli interrupt hardware tra i core della CPU e determina quindi se il carico di rete viene distribuito in modo uniforme o se alcuni core vengono rallentati. Ti mostrer\u00f2 come utilizzare irqbalance in modo mirato, quando passare all\u2019affinit\u00e0 IRQ manuale e quali impostazioni utilizzare su server con elevato <strong>carico di rete<\/strong> che contano davvero.<\/p>\n\n<h2>Punti centrali<\/h2>\n<p>Prima di entrare nei dettagli, riassumo le decisioni pi\u00f9 importanti che mi hanno aiutato in modo affidabile nei progetti con un carico I\/O elevato. Ritengo che la distribuzione automatica tramite irqbalance sia un buon punto di partenza; ne misuro l\u2019efficacia e apporto modifiche selettive. In presenza di carichi di lavoro deterministici, assegno manualmente singoli IRQ a determinati core ed escludo le restanti CPU dalla distribuzione automatica. Prendo in considerazione la vicinanza NUMA sin dalle prime fasi, poich\u00e9 riduce la latenza e garantisce il throughput. Grazie a un monitoraggio chiaro, individuo pi\u00f9 rapidamente i colli di bottiglia e li risolvo senza inutili <strong>I rischi<\/strong>.<\/p>\n<p>Questo elenco ti mostra a cosa presto particolare attenzione durante la configurazione:<\/p>\n<ul>\n  <li><strong>Automatico<\/strong> Per prima cosa: attivare irqbalance, misurare l'effetto<\/li>\n  <li><strong>affinit\u00e0<\/strong> in modo mirato: fissare gli IRQ critici, ridurre il jitter<\/li>\n  <li><strong>CPU vietate<\/strong>: Mantenere liberi i kernel per i thread delle app<\/li>\n  <li><strong>NUMA<\/strong> Nota: mantenere gli IRQ vicini al nodo di memoria<\/li>\n  <li><strong>Monitoraggio<\/strong>: Verificare \/proc\/interrupts e le latenze<\/li>\n<\/ul>\n\n<h2>Nozioni di base sugli IRQ spiegate in breve<\/h2>\n<p>Una richiesta di interruzione (IRQ) \u00e8 un segnale con cui l\u2019hardware trasferisce un\u2019operazione alla CPU, interrompendo cos\u00ec un\u2019attivit\u00e0 in corso. Se un numero eccessivo di questi segnali raggiunge lo stesso core, il carico di lavoro su di esso aumenta e il tempo di risposta rallenta, mentre altri core rimangono inutilizzati; \u00e8 proprio questo che voglio ottenere con <strong>Distribuzione<\/strong> evitare. irqbalance distribuisce dinamicamente questi IRQ su pi\u00f9 core e valuta a intervalli regolari lo stato del sistema. Per prima cosa dar\u00f2 un\u2019occhiata a <code>\/proc\/interruzioni<\/code> e osserva nelle colonne quanti IRQ arrivano per ogni CPU. Se alcune colonne diventano troppo piene, intervengo attivamente per regolare il carico e ridurre cos\u00ec gli IRQ superflui <strong>Hotspot<\/strong>.<\/p>\n\n\n<figure class=\"wp-block-image size-full is-resized\">\n  <img fetchpriority=\"high\" decoding=\"async\" src=\"https:\/\/webhosting.de\/wp-content\/uploads\/2026\/08\/linux-irq-guide-4513.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Distribuzione automatica con irqbalance<\/h2>\n<p>Sulle distribuzioni moderne avvio il servizio irqbalance, che per impostazione predefinita regola periodicamente la distribuzione degli IRQ. Lo attivo con <code>systemctl enable --now irqbalance<\/code> e verifico lo stato prima di intervenire in modo pi\u00f9 approfondito; in questo modo sfrutto ci\u00f2 che \u00e8 gi\u00e0 disponibile <strong>Automatico<\/strong>. A seconda del sistema, i file di configurazione si trovano in <code>\/etc\/sysconfig\/irqbalance<\/code> oppure <code>\/etc\/default\/irqbalance<\/code>, l\u00ec posso escludere CPU o IRQ. Particolarmente utile \u00e8 la variabile <code>IRQBALANCE_BANNED_CPUS<\/code> come maschera a 64 bit, per riservare core specifici alle applicazioni. Chi desidera approfondire gli esempi pratici, trover\u00e0 qui una breve introduzione alla <a href=\"https:\/\/webhosting.de\/it\/server-irq-balancing-ottimizzazione-delle-prestazioni-di-rete-datacenter\/\">Prestazioni della rete<\/a>, a cui faccio spesso riferimento nei workshop e che applico nei progetti.<\/p>\n\n<h2>Implementare in modo sicuro l'affinit\u00e0 IRQ manuale<\/h2>\n<p>Quando i carichi di lavoro sono molto sensibili al jitter o quando \u00e8 necessario che determinati core rimangano liberi esclusivamente per i processi dello spazio utente, imposto manualmente l\u2019affinit\u00e0 IRQ. A tal fine, scrivo le maschere di bit secondo <code>\/proc\/irq\/<em>NUMERO IRQ<\/em>\/smp_affinity<\/code> e stabilisco su quali core possa essere eseguito un interrupt; ci\u00f2 garantisce una maggiore pianificabilit\u00e0 <strong>Condotta<\/strong>. Per prima cosa individuo i numeri IRQ rilevanti con <code>grep<\/code> in <code>\/proc\/interruzioni<\/code>. Per i dispositivi di rete, spesso assegno le code RX\/TX a core vicini ai thread delle app, lasciando liberi gli altri core. Questo breve articolo fornisce una buona spiegazione di questo approccio <a href=\"https:\/\/webhosting.de\/it\/server-irq-affinita-multicore-ottimizzazione-delle-prestazioni-di-rete\/\">Guida all\u2019affinit\u00e0 IRQ<\/a>, che utilizzo regolarmente come punto di partenza.<\/p>\n<p>La tabella seguente mostra le maschere di bit pi\u00f9 comuni e il loro significato. Utilizzo questi esempi per impostare le configurazioni in modo rapido e con il minor numero possibile di errori, per poi verificarne l'effetto con <code>\/proc\/interruzioni<\/code> a <strong>verificare<\/strong>.<\/p>\n<table>\n  <thead>\n    <tr>\n      <th>Obiettivo<\/th>\n      <th>Esempio di maschera (esadecimale)<\/th>\n      <th>nuclei<\/th>\n      <th>Commento<\/th>\n    <\/tr>\n  <\/thead>\n  <tbody>\n    <tr>\n      <td>Solo CPU0<\/td>\n      <td>0x1<\/td>\n      <td>0<\/td>\n      <td>Test semplice, basso <strong>dispersione<\/strong><\/td>\n    <\/tr>\n    <tr>\n      <td>Solo CPU1<\/td>\n      <td>0x2<\/td>\n      <td>1<\/td>\n      <td>Disconnette gli IRQ dalla CPU0, riduce <strong>Interferenza<\/strong><\/td>\n    <\/tr>\n    <tr>\n      <td>CPU0\u2013CPU1<\/td>\n      <td>0x3<\/td>\n      <td>0\u20131<\/td>\n      <td>Distribuiti su due core, leggeri <strong>Sollievo<\/strong><\/td>\n    <\/tr>\n    <tr>\n      <td>CPU2\u2013CPU3<\/td>\n      <td>0xC<\/td>\n      <td>2-3<\/td>\n      <td>Utile se 0\u20131 per i thread delle app <strong>libero<\/strong> soggiorno<\/td>\n    <\/tr>\n    <tr>\n      <td>CPU0\u2013CPU3<\/td>\n      <td>0xF<\/td>\n      <td>0\u20133<\/td>\n      <td>Ampia distribuzione su 4 nuclei, mista <strong>Carico<\/strong><\/td>\n    <\/tr>\n  <\/tbody>\n<\/table>\n\n\n<figure class=\"wp-block-image size-full is-resized\">\n  <img decoding=\"async\" src=\"https:\/\/webhosting.de\/wp-content\/uploads\/2026\/08\/IRQ_Linux_Konferenz_3235.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Misurazione: leggere correttamente \/proc\/interrupts<\/h2>\n<p>Apro il file <code>\/proc\/interruzioni<\/code> e vedo un IRQ per ogni riga e, per ogni colonna, i contatori per ciascuna CPU; questo fa emergere immediatamente gli squilibri <strong>visibile<\/strong>. Se una colonna cresce in modo nettamente pi\u00f9 rapido rispetto alle altre, il carico si concentra proprio l\u00ec. A quel punto verifico quale driver sia coinvolto e se RSS\/RPS stiano gi\u00e0 distribuendo il carico. Inoltre, avvio temporaneamente irqbalance in primo piano con l\u2019output di debug, per comprenderne le decisioni ed evitare valutazioni errate. Dopo ogni modifica, ricontrollo i contatori e misuro la latenza sotto carico, in modo da poter documentare gli effetti ed evitare inutili <strong>I rischi<\/strong> pu\u00f2 evitare.<\/p>\n\n<h2>Isolamento della CPU e maschere di esclusione<\/h2>\n<p>Ho impostato <code>IRQBALANCE_BANNED_CPUS<\/code>, per escludere sistematicamente determinati core dalla distribuzione automatica; in questo modo libero risorse per i thread delle app. Nelle configurazioni pi\u00f9 recenti utilizzo inoltre <code>IRQBALANCE_BANNED_IRQS<\/code>, se si desidera che singoli dispositivi funzionino in modo autonomo su un kernel; ci\u00f2 riduce le interferenze per i sistemi sensibili <strong>Carichi di lavoro<\/strong>. Negli scenari a bassa latenza, disattivo in modo mirato irqbalance e assegno gli IRQ in modo statico, in modo che nessuna ridistribuzione interferisca. Chi desidera comprendere pi\u00f9 a fondo l\u2019assegnazione da parte della CPU della gestione degli interrupt, trover\u00e0 utili approfondimenti su <a href=\"https:\/\/webhosting.de\/it\/ottimizzazione-delle-prestazioni-della-cpu-per-la-gestione-degli-interrupt-del-server-7342\/\">Gestione degli interrupt<\/a> sui server. \u00c8 importante ricordare: prima misurare, poi definire e verificare nuovamente l'effetto, per evitare sorprese nel <strong>Operazione<\/strong> da evitare.<\/p>\n\n\n<figure class=\"wp-block-image size-full is-resized\">\n  <img decoding=\"async\" src=\"https:\/\/webhosting.de\/wp-content\/uploads\/2026\/08\/irq-balance-linux-guide-setup-3458.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Aspetti NUMA e vicinanza<\/h2>\n<p>Sui sistemi NUMA, cerco di indirizzare gli IRQ, per quanto possibile, ai core di quel nodo NUMA in cui si trovano i dati in questione; ci\u00f2 riduce la latenza e aumenta <strong>Produttivit\u00e0<\/strong>. Lo abbino all\u2019affinit\u00e0 della CPU per l\u2019applicazione, in modo che i thread e gli interrupt vengano eseguiti localmente tra loro. irqbalance funziona bene su NUMA, ma se necessario effettuo ulteriori regolazioni con le maschere di esclusione. \u00c8 fondamentale non distribuire il carico su pi\u00f9 nodi se \u00e8 comunque possibile mantenerlo a livello locale. Chi mantiene questa vicinanza ottiene tempi di risposta costanti e preserva preziose <strong>Cache<\/strong>-Risorse.<\/p>\n\n<h2>Corso intensivo sulle reti: RSS, RPS\/RFS e XPS<\/h2>\n<p>Prima di ottimizzare le maschere IRQ, verifico le funzionalit\u00e0 della scheda di rete (NIC), come l\u2019RSS, e i meccanismi del kernel, quali RPS\/RFS e XPS; questi influenzano notevolmente la distribuzione dei pacchetti. L\u2019RSS distribuisce gi\u00e0 gli interrupt delle code su pi\u00f9 core, mentre l\u2019RPS\/RFS modella l\u2019elaborazione nel kernel e l\u2019XPS definisce i percorsi di trasmissione; ci\u00f2 evita inutili <strong>Hotspot<\/strong>. Coordino questi meccanismi con la mia strategia IRQ, in modo che non entrino in conflitto tra loro. Se le code, le affinit\u00e0 IRQ e l\u2019affinit\u00e0 delle app sono ben sincronizzate, l\u2019I\/O di rete funziona in modo decisamente pi\u00f9 fluido. Successivamente, effettuo una nuova misurazione sotto carico reale, prima di procedere con ulteriori <strong>Passi<\/strong> metto.<\/p>\n\n\n<figure class=\"wp-block-image size-full is-resized\">\n  <img loading=\"lazy\" decoding=\"async\" src=\"https:\/\/webhosting.de\/wp-content\/uploads\/2026\/08\/irq_balance_linux_guide_7163.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>MSI-X, Multi-Queue e struttura ordinata delle code<\/h2>\n<p>Molte schede di rete da 10\u2013100G utilizzano MSI-X e mettono a disposizione vettori di interrupt dedicati per ogni coda RX\/TX. Per prima cosa verifico con <code>ethtool -l eth0<\/code> (numero di canali) e <code>\/proc\/interruzioni<\/code>, quante code sono effettivamente attive e come si chiamano (ad esempio,. <code>eth0-TxRx-0<\/code>, <code>eth0-TxRx-1<\/code>). L'obiettivo \u00e8 quello di adeguare il numero delle code al numero di core utilizzati per ogni nodo NUMA e di fissarle in modo deterministico. Con <code>ethtool -L eth0 combined N<\/code> impostare il numero di code; successivamente ordino gli IRQ generati tramite <code>smp_affinity<\/code> ai core appropriati. Mi assicuro che le coppie RX\/TX della stessa coda vengano assegnate allo stesso core o almeno allo stesso socket, in modo che <strong>Localit\u00e0 della cache<\/strong> . Importante: le modifiche al numero di code e all\u2019affinit\u00e0 le controllo direttamente in <code>\/proc\/interruzioni<\/code> e con un breve test di carico (pps\/Throughput), prima di procedere con l'ottimizzazione.<\/p>\n\n<h2>Coalescenza degli interrupt e budget NAPI<\/h2>\n<p>Soprattutto in presenza di elevate frequenze di pacchetti, i valori di coalescenza influenzano l'efficacia della mia strategia IRQ. Con <code>ethtool -c eth0<\/code> vedo se <code>rx-usecs<\/code> e <code>rx-frames<\/code> sono impostati. Una maggiore coalescenza riduce il numero di IRQ al secondo e alleggerisce il carico della CPU, ma aumenta la latenza e il jitter. Regolo con cautela: piccoli passi, misurando ogni volta (latenza p95\/p99 e carico della CPU). Dal lato del mittente si nota <code>tx-usecs<\/code> analogico. Inoltre, regolo il comportamento del NAPI tramite <code>net.core.netdev_budget<\/code> e <code>net.core.netdev_budget_usecs<\/code>, quando <strong>NET_RX<\/strong> cominciano ad accumularsi negli SoftIRQ. Se i drop aumentano in <code>\/proc\/net\/softnet_stat<\/code>, aumento il budget a titolo di prova oppure distribuisco le code RX in modo pi\u00f9 coerente; se la latenza del sistema diventa eccessiva, riduco nuovamente i valori. Prendo in considerazione GRO\/LRO e TSO\/GSO in modo integrato: un\u2019aggregazione eccessiva riduce il carico IRQ, ma pu\u00f2 generare picchi di latenza \u2013 li bilancio con il profilo dell\u2019applicazione.<\/p>\n\n<h2>Lettura trasparente degli SoftIRQ<\/h2>\n<p>Oltre agli HardIRQ, decido io il carico degli SoftIRQ. Con <code>cat \/proc\/softirqs<\/code> Osservo <strong>NET_RX<\/strong> e <strong>NET_TX<\/strong> per CPU; se alcune colonne prevalgono, in quei thread ksoftirqd finisce troppo lavoro. Un <code>top -H<\/code> fammi vedere subito quali <code>ksoftirqd\/N<\/code> I noccioli appesantiscono. Misuro pi\u00f9 in profondit\u00e0 con <code>perf top<\/code> o brevi <code>record perf<\/code> Eseguire per individuare eventuali punti critici nel driver o nell\u2019elaborazione dello stack. Quando i thread ksoftirqd diventano attivi (anzich\u00e9 l'elaborazione immediata nel contesto IRQ), la latenza spesso aumenta in modo significativo; io reagisco con una migliore distribuzione delle code, un budget NAPI pi\u00f9 ampio o un pinning mirato della CPU dei thread ksoftirqd interessati tramite <code>taskset -pc<\/code>. Importante: documento queste modifiche perch\u00e9 hanno un effetto impercettibile e, in caso di dubbio, ho bisogno di poter tornare rapidamente indietro.<\/p>\n\n<h2>Utilizzare correttamente SMT\/Hyper-Threading e la topologia<\/h2>\n<p>Con SMT attivo, condivido un core fisico con due CPU logiche. Verifico le relazioni di parit\u00e0 tramite <code>lscpu -e<\/code> e <code>\/sys\/devices\/system\/cpu\/cpuX\/topology\/thread_siblings_list<\/code>. Per i percorsi in cui la latenza \u00e8 critica, evito di collocare il thread dell\u2019app e l\u2019IRQ associato sullo stesso core fisico (thread SMT diversi); essi entrano in competizione per le unit\u00e0 di esecuzione e le cache. Preferisco coppie in cui, ad esempio, un thread dell\u2019app venga eseguito su CPU2 e la relativa coda RX su CPU3 (core fisico diverso, stesso nodo NUMA). Se l\u2019SMT compromette la costanza, opto invece per un numero minore di core fisici, ma esclusivi, evitando cos\u00ec situazioni instabili <strong>Interferenze<\/strong>.<\/p>\n\n<h2>Virtualizzazione: KVM, vhost e SR-IOV<\/h2>\n<p>Negli ambienti virtualizzati considero separatamente l\u2019host e il guest. Sull\u2019host distribuisco in modo ordinato gli IRQ delle schede di rete fisiche tra i core del nodo NUMA corrispondente. Se il guest utilizza virtio-net, vengono generati IRQ aggiuntivi per i thread vhost; li riconosco in <code>\/proc\/interruzioni<\/code> e assegno in modo coerente i worker vhost alle code delle schede di rete fisiche. A livello di guest, imposto anche le affinit\u00e0 RSS\/XPS e IRQ, a condizione che il driver virtio metta a disposizione pi\u00f9 code. Con SR-IOV, vale la pena assegnare a ogni guest una o pi\u00f9 VF con vettori MSI-X dedicati e fissarle all\u2019interno del guest; l\u2019isolamento migliora la latenza e la prevedibilit\u00e0. Mi attengo a uno schema chiaro: vCPU dell\u2019ospite su pCPU dedicate, IRQ associate su core vicini e non mescolare i thread dell\u2019emulatore\/vhost con thread di applicazioni ad alta intensit\u00e0 di calcolo \u2013 in questo modo il percorso dei dati rimane <strong>pianificabile<\/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\/08\/irq_balance_linux_guide_5421.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Frequenza della CPU, stati C e ottimizzazione NOHZ<\/h2>\n<p>Le latenze IRQ ne risentono quando i core entrano in stati C profondi o funzionano a frequenze elevate. Per i carichi di lavoro sensibili, imposto il governor della CPU su <code>performance<\/code> (<code>cpupower frequency\u2011set -g performance<\/code>) e riduco gli stati C profondi tramite opzioni di avvio o dei driver, per limitare i tempi di risveglio. Su server sottoposti a carico elevato, questo approccio spesso d\u00e0 risultati migliori rispetto a qualsiasi regolazione fine delle affinit\u00e0. In contesti caratterizzati da latenze molto elevate, aggiungo <code>nohz_full=<\/code> e <code>rcu_nocbs=<\/code> per i core isolati, in modo che il tick-timer e i callback RCU non interferiscano tra loro; definisco volutamente separatamente le CPU di housekeeping. Tuttavia, testo questi interventi separatamente, poich\u00e9 possono avere effetti collaterali sulla schedulazione e sul consumo energetico. L'aspetto fondamentale rimane: confrontare accuratamente i valori misurati prima e dopo la modifica, altrimenti mi ritrovo a brancolare nel buio <strong>Ottimizzazioni<\/strong> al buio.<\/p>\n\n<h2>Systemd, Cgroups e isolamento delle applicazioni<\/h2>\n<p>Oltre al pinning degli IRQ, isolo i thread delle app utilizzando i Cgroup e l\u2019affinit\u00e0 di systemd. Tramite <code>CPUAffinity=<\/code> Nei file Unit e nei controller della CPU (cgroup v2) assegno core fissi ai servizi. In questo modo impedisco che, a livello di scheduler, i thread vengano spostati sulle CPU che ho destinato agli IRQ. Negli ambienti container impiego <code>cpuset.cpus<\/code> e controllare <code>cpuset.cpus.effective<\/code>, affinch\u00e9 gli impegni in materia di risorse abbiano davvero effetto. Importante: <code>IRQBALANCE_BANNED_CPUS<\/code> controlla solo dove irqbalance non distribuisce; i thread del kernel come ksoftirqd continuano a seguire lo scheduler. Per un isolamento rigido ho quindi bisogno di una combinazione di affinit\u00e0 IRQ, affinit\u00e0 CPU dei servizi e, se necessario, kernel isolati. In questo modo il percorso dei dati e l\u2019applicazione rimangono chiaramente separati e il <strong>Carico<\/strong> non si mescola in modo incontrollato.<\/p>\n\n<h2>Errori tipici e misure correttive<\/h2>\n<p>Non disattivo mai irqbalance in modo indiscriminato senza conoscere i profili di carico; altrimenti gli IRQ si concentrano rapidamente su pochi core. Altrettanto svantaggioso \u00e8 aprire tutti i core a tutti gli IRQ, nonostante i thread sensibili siano esclusivi <strong>Risorse<\/strong> necessario. Un altro errore: non testare le modifiche in modo isolato e non misurarne gli effetti; in questo modo non \u00e8 chiaro cosa sia effettivamente utile. Prendo in considerazione anche le coppie di Hyper-Threading: \u00e8 preferibile che il thread dell\u2019app e l\u2019IRQ associato non condividano lo stesso core fisico. Documento ogni passaggio e creo punti di rollback, in modo da poter tornare rapidamente all\u2019ultima <strong>buono<\/strong> Torna alla configurazione.<\/p>\n\n<h2>Lista di controllo pratica per i server<\/h2>\n<p>Comincio sempre con una linea di base: irqbalance attivo, rilevamento del carico di sistema, monitoraggio di \/proc\/interrupts e misurazione delle latenze; solo dopo intervengo sulle impostazioni. Nella seconda fase concludo con <code>IRQBALANCE_BANNED_CPUS<\/code> seleziono quei core che devono rimanere riservati agli App Thread; in questo modo evito interferenze IRQ superflue. Successivamente, collego gli IRQ critici tramite <code>smp_affinity<\/code> su pochi core ben scelti, mantenendo la vicinanza NUMA. Successivamente verifico RSS\/RPS\/RFS e XPS, nonch\u00e9 le opzioni di offloading della scheda di rete (NIC), per distribuire il carico di lavoro in modo ottimale. Infine, eseguo dei test sotto carico di produzione, confronto le metriche e mantengo solo quelle modifiche che si dimostrano <strong>lavoro<\/strong>.<\/p>\n\n<h2>File di configurazione e comandi systemd<\/h2>\n<p>Attivo il servizio con <code>systemctl enable --now irqbalance<\/code> e verifica con <code>systemctl status irqbalance<\/code> la durata; ecco come lo imposto <strong>Servizio<\/strong> sicuramente pronto. In <code>\/etc\/sysconfig\/irqbalance<\/code> oppure <code>\/etc\/default\/irqbalance<\/code> metto <code>IRQBALANCE_BANNED_CPUS<\/code> e, facoltativamente, <code>IRQBALANCE_BANNED_IRQS<\/code>. Applicher\u00f2 le modifiche con <code>systemctl restart irqbalance<\/code> e, parallelamente, osservo i contatori in <code>\/proc\/interruzioni<\/code>. Per i test utilizzo la modalit\u00e0 \u201cForeground\u201d di irqbalance, in modo da poter seguire in tempo reale le decisioni prese. Solo dopo aver compreso il comportamento, inserisco le modifiche in modo permanente nel <strong>Configurazione<\/strong>.<\/p>\n\n<h2>Quando disattivo irqbalance<\/h2>\n<p>Nelle configurazioni in tempo reale o nelle applicazioni estremamente sensibili alla latenza, interrompo irqbalance e assegno gli IRQ in modo statico, in modo che nessuna ridistribuzione possa interferire. Isolo i core per questi carichi di lavoro e faccio in modo che gli IRQ di traffico vengano eseguiti intenzionalmente su altri core; in questo modo i thread delle applicazioni <strong>pianificabile<\/strong>. Questo approccio \u00e8 utile anche in ambienti tenant rigorosamente separati, poich\u00e9 riduce le interferenze tra macchine virtuali o container. Se si presentano driver che funzionano male con la modalit\u00e0 automatica, ne escludo gli IRQ tramite una lista di esclusione. Non appena i modelli di carico tornano ad essere pi\u00f9 variabili, riattivo irqbalance e ne verifico l\u2019effetto con nuovi <strong>Valori misurati<\/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\/08\/linux-irq-balance-setup-1234.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Riassumendo brevemente<\/h2>\n<p>Comincio con irqbalance, ne valuto l'effetto e apporto modifiche mirate, invece di intervenire alla cieca ovunque; in questo modo mantengo una visione d'insieme del sistema e <strong>Trasparenza<\/strong>. Per i carichi di lavoro sensibili, assegno gli IRQ appropriati, isolo i kernel per le applicazioni e rispetto la vicinanza NUMA. Con le maschere di esclusione controllo dove irqbalance pu\u00f2 operare e impedisco spostamenti indesiderati. Verifico regolarmente <code>\/proc\/interruzioni<\/code>, latenza e throughput, in modo che le modifiche siano documentate in modo attendibile. Chi procede in questo modo sfrutta appieno il potenziale di IRQ Balance e mantiene i server sotto carico di rete in modo tangibile <strong>reattivo<\/strong>.<\/p>","protected":false},"excerpt":{"rendered":"<p>Configurare correttamente irqbalance su Linux: ecco come distribuire in modo efficiente gli interrupt sui server Linux e migliorare le prestazioni.<\/p>","protected":false},"author":1,"featured_media":21035,"comment_status":"","ping_status":"","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"inline_featured_image":false,"footnotes":""},"categories":[676],"tags":[],"class_list":["post-21042","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":"163","_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":"IRQ Balance","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":"21035","footnotes":null,"_links":{"self":[{"href":"https:\/\/webhosting.de\/it\/wp-json\/wp\/v2\/posts\/21042","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=21042"}],"version-history":[{"count":0,"href":"https:\/\/webhosting.de\/it\/wp-json\/wp\/v2\/posts\/21042\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/webhosting.de\/it\/wp-json\/wp\/v2\/media\/21035"}],"wp:attachment":[{"href":"https:\/\/webhosting.de\/it\/wp-json\/wp\/v2\/media?parent=21042"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/webhosting.de\/it\/wp-json\/wp\/v2\/categories?post=21042"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/webhosting.de\/it\/wp-json\/wp\/v2\/tags?post=21042"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}