A cosa serve IRQbalance in Linux e come si inserisce nell'ottimizzazione avanzata?

Quando si comincia a modificare le prestazioni di un sistema GNU/Linux, prima o poi compare un protagonista ricorrente: irqbalance e la distribuzione degli interrupt hardware tra le CPUSe ne parla nei forum, nella documentazione della distribuzione e nei tutorial su come "mettere a punto" il sistema per farlo funzionare... ma raramente viene spiegato bene cosa fa realmente, in quali scenari contribuisce e in quali non si nota affatto nulla.

Inoltre, tutto questo riguarda Bilanciamento IRQ Si intreccia con altri concetti avanzati: NAPI, code di ricezione del kernel, buffer NIC, algoritmi di controllo della congestione TCP, RSS/RPS, BBR, impostazioni sysctl, demoni delle prestazioni come il preload, swap compresso zram, ottimizzazione GTK, file temporanei nella RAM, ecc. È molto facile perdersi tra i parametri. comandi e file di configurazione senza una chiara comprensione di cosa fa ogni cosa.

Che cos'è IRQbalance e a cosa serve realmente in Linux?

irqbalance è un demone dello spazio utente responsabile della distribuzione degli interrupt hardware (IRQ) tra i diversi core della CPU. nei sistemi SMP (multiprocessore o multicore). Il suo scopo non è magico: cerca semplicemente di impedire tutto il lavoro di manutenzione dei dispositivi (rete, dischi, USB, ecc.) cade sempre sullo stesso nucleo.

Quando un dispositivo genera un IRQ, il kernel esegue un gestore di interrupt. Se molti di questi interrupt sono concentrati su una singola CPU, questa può sovraccaricarsi mentre le altre rimangono inattive. irqbalance analizza il volume di interrupt per dispositivo e assegna ogni IRQ a un core "adatto" per distribuire il carico., cercando allo stesso tempo di ridurre al minimo le perdite di cache e di rispettare le affinità logiche (ad esempio, mantenendo correlati gli IRQ della stessa interfaccia di rete).

Nei sistemi con una singola CPU o core che condividono completamente la cache L2irqbalance rileva automaticamente di non avere nulla di utile da fare e si chiude. Non si tratta di un errore; semplicemente non c'è margine di miglioramento. Tuttavia, su server con più CPU fisiche o molti core, soprattutto con traffico di rete intenso o I/O elevato, può fare la differenza in termini di latenza e stabilità.

Il demone può essere eseguito in background (modalità di servizio) o in base alle necessità con l'opzione – colpo singolo. Anche consente di escludere IRQ specifici per opzione --banirq e impedirgli di utilizzare determinati core con la maschera della CPU definita nella variabile di ambiente IRQBALANCE_BANNED_CPUSTutto questo è normalmente controllato dal tuo file di configurazione, che in molte distribuzioni si trova in /etc/default/irqbalance o /etc/irqbalance.env.

Bilanciamento IRQ: kernel vs irqbalance e quando è evidente

Linux ha già un suo meccanismo interno per decidere quale CPU serve ogni IRQ, senza bisogno di irqbalance. Il kernel può impostare affinità di interrupt e distribuirle seguendo semplici euristicheE su molti computer desktop questo è più che sufficiente: l'utente medio non noterà alcuna differenza attivando o disattivando irqbalance.

Ecco perché è relativamente comune che qualcuno provi irqbalance sulla propria distribuzione desktop e dica: "Non noto alcun miglioramento, ma nemmeno niente di male."È perfettamente normale. Su un laptop con un processore quad-core e una singola scheda di rete senza un carico di I/O elevato, lo scheduler Linux e i meccanismi interni del kernel (NAPI, code di rete, ecc.) mantengono già le cose ragionevolmente equilibrate.

Dove ha senso è in server con più core e traffico intenso: database grandi proxy inversi, server web ad alto traffico, immagazzinamento di backup, macchine virtuali molto caricateecc. Avere molti IRQ di rete o disco assegnati a un singolo core può diventare un collo di bottiglia. Distribuirli correttamente riduce le code, i tempi di servizio e i picchi di latenza.

Alcuni utenti preferiscono usare irqbalance invece di irqbalance parametrizzare il kernel con opzioni come acpi_irq_balance In GRUB. Questo parametro influenza il modo in cui ACPI e il kernel allocano gli IRQ, ma non offre la stessa flessibilità dinamica di irqbalance, che rivaluta l'allocazione in base al carico effettivo. Si tratta di approcci diversi: il primo è più statico e di basso livello; il secondo, più adattivo.

In ambienti a latenza ultra bassa (ad esempio, alcune piattaforme di trading o reti con DPDK), si verifica il contrario: irqbalance è solitamente disabilitato e gli IRQ vengono assegnati manualmente a core specifici.insieme a un'attenta mappatura tra code NIC e CPU. In questi scenari, si ricerca il controllo assoluto e si sacrifica una parte dell'automazione.

Interruzioni, NAPI e code di rete: come si inserisce IRQbalance

Per comprendere meglio il ruolo di irqbalance, dobbiamo scendere a un altro livello e vedere come Linux li gestisce. interruzioni di rete e ricezione dei pacchettiIl sottosistema di rete del kernel combina diversi componenti chiave: NAPI, code di ricezione (buffer DMA), parametri di net.core.*, algoritmi di gestione delle code (qdisc) e ridimensionamento laterale (RSS/RPS).

NAPI (Nuova API) Questo è il meccanismo con cui il kernel riduce la tempesta di interrupt quando arriva molto traffico. Invece di attivare un IRQ per ogni pacchetto, la scheda di rete genera un interrupt che indica "c'è lavoro in sospeso" e il kernel sonda La coda di ricezione viene elaborata finché non si svuota o non si esaurisce il budget di tempo/pacchetto. Questo riduce il jitter e migliora le prestazioni, sebbene possa anche introdurre qualche variazione nella latenza.

La coda in cui i pacchetti atterrano prima di essere elaborati dallo stack di rete è quella che di solito viene chiamata coda di ricezione del kernel o buffer DMALa sua capacità è limitata da parametri quali:

• net.core.netdev_max_backlog: numero massimo di pacchetti nella coda di ricezione del software quando il kernel non riesce a elaborarli alla velocità con cui arrivano.
• net.core.netdev_budget_usecs: “budget” di tempo in microsecondi che NAPI ha a disposizione per svuotare le code in ogni ciclo.
• net.core.dev_weight: numero di pacchetti elaborati per interfaccia in ogni round entro quel budget.

Si netdev_max_backlog è molto basso e la NIC invia più pacchetti di quanti il ​​kernel possa gestire, inizieremo a vedere "pacchetti scartati" in /proc/net/softnet_statUn tipico punto di partenza per la messa a punto su server ad alto traffico è nell'intervallo di Pacchetti 4000, configurato in /etc/sysctl.conf con qualcosa del tipo:

net.core.netdev_max_backlog = 4000

Dopo averlo modificato, viene applicato con sysctl -p o un sysctl -w puntuale. In questo modo, la coda assorbe meglio i picchi di arrivo senza perdere pacchetti, a patto che il resto del percorso di elaborazione regga.

In tutto questo circuito, irqbalance decide quale CPU gestisce gli IRQ associati all'interfaccia di rete. Se concentriamo tutti gli interrupt NIC su un singolo core, quel core eseguirà le routine NAPI e svuoterà la coda da solo.Se distribuiamo correttamente gli IRQ e utilizziamo meccanismi come RSS o RPS, più CPU possono collaborare per elaborare i pacchetti, riducendo code e perdite.

Ottimizzare le code, i buffer e la finestra TCP per il traffico intenso

Quando un server sposta molti dati (ad esempio, backup, traffico FTP, file di grandi dimensioni o database in replica), il semplice fatto di "avere irqbalance abilitato" non è sufficiente. È necessario armonizzare diversi livelli: code del kernel, buffer delle schede, dimensioni delle finestre TCP e parametri di congestione.in modo che tutti remino nella stessa direzione.

Il primo blocco di regolazione è nel buffer di ricezione dei pacchetti e finestra TCPLinux espone parametri come:

• net.ipv4.tcp_rmem: tripletta (minimo, predefinito, massimo) di memoria di ricezione TCP per socket.
• net.ipv4.tcp_wmem: equivalente per la spedizione.
• net.core.rmem_max y net.core.wmem_max: buffer massimo che un'applicazione può richiedere.

Un modo pratico per adattarli a un collegamento Gigabit a bassa latenza è calcolare il BDP (prodotto larghezza di banda-ritardo) e applicare un fattore di scala (grazie all'opzione di Ridimensionamento della finestra TCP(abilitato di default nella maggior parte dei kernel moderni). In pratica, molti amministratori finiscono per ottenere valori massimi di diversi megabyte, ad esempio:

net.ipv4.tcp_rmem = 4096 16384 10880000
net.ipv4.tcp_wmem = 4096 16384 10880000

Quel massimo di ~ 10,8 MB Questo deriva da calcoli specifici per collegamenti da 1 Gbps con RTT molto basso (~0,00017 s). Maggiore è la velocità di trasmissione o la latenza, maggiore deve essere il buffer per sfruttare la larghezza di banda senza essere limitato dalla finestra.

È importante mettere in relazione questo massimo con la dimensione della coda di ricezione dei pacchetti. Se netdev_max_backlog = 4000 e ogni pacchetto effettivo è di circa 1480 byte, quella coda rappresenta circa ~5,9 MB. Il buffer della finestra TCP deve essere più grande di quanto possa essere contenuto nella codaoppure perderemo pacchetti saturando il buffer prima della coda.

Per monitorare le perditeÈ possibile utilizzare comandi come i seguenti:

• cat /sys/class/net/eth0/statistics/rx_dropped: pacchetti persi nella NIC.
• watch -n 1 -t -d cat /proc/net/softnet_stat: colonne elaborate, eliminate, tempi ridotti, ecc. per CPU.
• watch -n 1 -t -d "netstat -s | grep err": errori dello stack di rete.

Si netstat indica errori ma /proc/net/softnet_stat noMolto probabilmente, le perdite si verificano all'esterno del nostro host (lungo il percorso, attraverso un firewall intermedio, ecc.). Ci saranno sempre delle perdite dovute agli algoritmi di controllo della congestione, ma dovrebbero rimanere sotto controllo e correlarsi ai picchi di traffico.

Gestione delle code (qdisc), QoS e controllo della congestione TCP

Sebbene le code interne del kernel siano critiche, lo è anche il disciplina di coda (qdisc) associata alle interfacce di reteQuesto è ciò che determina il modo in cui i pacchetti vengono ordinati, raggruppati e scartati nell'output e può fare la differenza di fronte a fenomeni come il bufferbloat.

Offerte Linux diversi qdisc rilevanti:

• pfifo_fast: vecchia disciplina predefinita, un FIFO con tre fasce di priorità.
• fq_codice: combinazione di coda equa con CoDel per combattere il bufferbloat, altamente consigliata per router e uso generale.
• fq: semplice coda equa, molto utile sui server ad alto carico.
• torta (sch_cake): il più avanzato oggi, ma richiede la compilazione o la presenza del modulo nel kernel.

Il qdisc predefinito si presenta così:

sysctl net.core.default_qdisc

E può essere sostituito a caldo con:

sysctl -w net.core.default_qdisc=fq_codel

Per garantire che un'interfaccia specifica utilizzi una disciplina particolare, si ricorre a tc:

sudo tc qdisc replace dev eth0 radice fq_codice

In relazione a ciò, il Algoritmo di controllo della congestione TCP Fa la differenza anche negli ambienti WAN o in quelli con traffico intenso. Il kernel offre diverse opzioni (cubic, reno, ecc.) e le versioni moderne includono BBR sviluppato da Googleche in genere migliora la produttività sostenuta senza aumentare la latenza. Viene attivato da:

sudo sysctl -w net.ipv4.tcp_congestion_control=bbr

L'elenco degli algoritmi disponibili può essere ispezionato visualizzando i moduli tcp_* en /lib/modules/<versión>/kernel/net/ipv4/. Combina BBR con un qdisc adatto (fq/fq_code) e una buona configurazione del buffer Ciò si traduce in flussi di dati molto più stabili.

Impostazioni NIC avanzate: buffer ad anello, RSS, RPS e offload

Anche la scheda di rete stessa ha il suo set di code e buffer: buffer ad anello per ricezione (RX) e trasmissione (TX)La sua dimensione massima dipende dall'hardware e viene visualizzata con:

ethtool -g ethX

Campi “Massimi preimpostati” Indicano di quanto può essere aumentato. Se la scheda lo consente, RX e TX possono essere aumentati a valori come 4096, 8192 o 16384 con:

ethtool -G ethX rx 4096 tx 4096

Se viene visualizzato un errore del tipo "Impossibile impostare i parametri di suoneria del dispositivo: argomento non valido", Tale valore supera le capacità della scheda di rete e dovremo provare divisori più piccoli.

a impedire a una singola CPU di gestire tutto il lavoro di ricezioneMolte schede di rete moderne implementano RSS (Riceve Side Scaling)creando diverse code hardware associate a kernel diversi. In Linux, questa distribuzione si presenta così:

gatto /proc/interruzioni | grep

Sulle schede senza RSS, qualcosa di simile può essere "emulato" con RPS (Receive Packet Steering), assegnando le CPU alle code del software di interfaccia:

echo f > /sys/class/net/enp4s0f0/queues/rx-0/rps_cpus

Il valore è una maschera esadecimale. Ad esempio, f In binario (1111), indica l'utilizzo dei primi quattro kernel. Il kernel deve essere compilato con CONFIG_RPS perché funzioni.

Puoi anche giocare con scaricamenti e segmentazione del checksum per scaricare il lavoro dalla CPU al processore NIC. ethtool -k Le funzionalità attivate sono visibili e possono essere attivate cose come le seguenti:

ethtool -K ethX rx acceso (verifica del checksum alla reception)
ethtool -K ethX tso on (Scarico della segmentazione TCP)

Affinché questi cambiamenti siano duraturi, sono solitamente inseriti negli script di rete (/etc/network/interfaces in Debian/Ubuntu, /etc/sysconfig/network-scripts/ifcfg-ethX in Red Hat) o nelle regole udev.

Regola manualmente l'affinità IRQ e vivi con IRQbalance

Nei kernel più vecchi o nei casi in cui vogliamo un controllo preciso, è possibile Assegna manualmente la CPU che gestisce uno specifico IRQ.Tutte le informazioni sono in /proc/irq y /proc/interruptsUn flusso tipico sarebbe:

• Visualizza interruzioni: cat / proc / interrupts e individuare la linea dell'interfaccia di rete (ad esempio, IRQ 25 per enp0s8).
• Controlla l'affinità attuale: gatto /proc/irq/25/smp_affinity (maschera esadecimale: 02 = CPU1, 01 = CPU0, 04 = CPU2, ecc.).
• Cambialo: echo 1 > /proc/irq/25/smp_affinity per spostarlo su CPU0.

In questo modo puoi, ad esempio, scarico da una CPU sovraccarica Spostare un IRQ su un core meno occupato. Se irqbalance è installato e abilitato, è importante dirgli di non toccare quello specifico interrupt aggiungendo un'opzione come:

OPZIONI="--banirq=25"

en /etc/default/irqbalanceoppure utilizzando l'opzione --banirq=25 Quando il demone inizia. Così Lo si esclude dalla logica di distribuzione automatica. e rispetti il ​​tuo compito manuale.

Quindi questo cambia come echo 1 > /proc/irq/25/smp_affinity sopravvivere ai riavviiDi solito vengono aggiunti al classico /etc/rc.local (se abilitato) o a unità systemd specifiche.

Altre impostazioni di prestazioni correlate: swap, zram, file temporanei, preload

Tutto questo lavoro per migliorare la risposta della rete e la distribuzione IRQ è solitamente accompagnato da altra messa a punto del sistema che, pur non essendo direttamente legati a irqbalance, completano il quadro delle prestazioni.

Nell'ambito della memoria, molti amministratori riducono la uso aggressivo dello swap modificando /etc/sysctl.conf con parametri quali:

• vm.swappiness: quanto il kernel preferisce usare lo swap (0-100, predefinito 60). Valori bassi (1-10) danno priorità alla RAM.
• vm.vfs_cache_pressionePressione sulla cache inode e dentry. Ridurla aiuta a mantenere i metadati nella RAM.
• vm.dirty_writeback_centisecs y vm.dirty_expire_centisecs: frequenza e scadenza della scrittura di pagine sporche su disco.
• vm.dirty_ratio y vm.dirty_ background_ratio: percentuale di memoria che può essere riempita con dati sporchi prima delle scritture forzate.

Con valori appropriati (ad esempio vm.swappiness = 1, vm.vfs_cache_pressione=50ecc.) si ottiene che Il sistema utilizzerà più RAM prima di iniziare la paginazione., qualcosa di desiderabile nei server con molta memoria.

Un'altra misura classica è spostare le directory temporanee nella RAM montandoli come tmpfs en /etc/fstab:

tmpfs /tmp tmpfs noatime,nodiratime,nodev,nosuid,mode=1777,defaults 0 0
tmpfs /var/tmp tmpfs noatime,nodiratime,nodev,nosuid,mode=1777,defaults 0 0

Con questo vengono eseguiti accessi temporanei (compilazioni, file di lavoro dell'applicazione, ecc.) velocità della RAM e riduce l'usura dei dischi SSD.

È anche comune in ambienti con poche risorse attivare zram-swapUn dispositivo di swap compresso nella RAM. Viene installato da un repository (ad esempio, utilizzando Git tramite clonazione). zram-swap eseguendo il suo install.sh) e crea un dispositivo a blocchi compresso in cui il sistema effettua lo scambio prima di ricorrere, se disponibile, allo scambio del disco. Si ottiene una memoria effettiva a discapito di una CPU leggermente maggiore.che compensa molti carichi.

Infine, demoni come precarico Analizzano quali applicazioni vengono eseguite più frequentemente e precaricano i loro file binari e librerie nella RAM, velocizzando l'avvio a scapito del consumo di memoria. Questo ha senso sui desktop con ampia RAM; sui server con risorse limitate, di solito viene omesso.

GTK, GRUB, Firefox e altre modifiche alla “qualità della vita”

Oltre alle prestazioni del server, molti tutorial includono sezioni molto lunghe su ottimizzare l'esperienza desktopTempi di risposta del menu GTK, font, temi scuri, audio, comportamento del mouse, ecc. Sebbene non influiscano direttamente sul bilanciamento IRQ o sul traffico di rete, contribuiscono a rendere il sistema più reattivo.

In GTK2, GTK3 e GTK4 è possibile effettuare delle regolazioni. decine di parametri in file come ~/.gtkrc-2.0, ~/.config/gtk-3.0/settings.ini o ~/.config/gtk-4.0/settings.iniAnimazioni, tempi di doppio clic, dimensioni del cursore, design della barra del titolo, utilizzo di temi scuri, comportamento dei suggerimenti, antialiasing dei caratteri, ecc. Questi file vengono modificati manualmente (con nano) o aggiungendo linee tramite echo >> da terminale.

Anche le versioni vengono solitamente modificate. "globale" di questi parametri in /etc/gtk-2.0/gtkrc, /etc/gtk-3.0/settings.ini y /etc/gtk-4.0/settings.ini, in modo che riguardino tutti gli utenti, rispettando sempre che in quei casi bisogna essere root (tramite su - o sudo).

El tempo di attesa del direttore Boot GRUB Si accorcia modificandolo. /etc/default/grub e modificando GRUB_TIMEOUT (ad esempio, da 10 a 3 secondi) e aggiungendo parametri al kernel come noresume o acpi_irq_balance en GRUB_CMDLINE_LINUX_DEFAULT. Quindi viene eseguito update-grub (Debian/Ubuntu) o grub-mkconfig -o /boot/grub/grub.cfg (Archivi e derivati).

Nel caso del browser, ci sono file come user.js per firefox Queste impostazioni consentono di applicare gruppi di preferenze volte ad accelerare la navigazione: numero di connessioni, comportamento della cache, compressione, WebSocket, ecc. La procedura usuale è quella di reimpostare il profilo, aprire la directory del profilo da "Informazioni sulla risoluzione dei problemi", chiudere Firefox e incollare quanto segue: user.js nella cartella del profilo e riaprire il browser.

Sebbene tutto ciò sia parallelo al tema dell'irqbalance, illustra un'idea importante: L'ottimizzazione di Linux è un processo olisticoNon si tratta solo di un demone o di un parametro magico, ma di ottimizzare CPU, memoria, disco, rete, desktop e applicazioni fino a quando non si adattano all'uso effettivo della macchina.

Considerando l'intero pacchetto (allocazione IRQ con irqbalance o manuale, NAPI e code ottimizzate, buffer TCP di dimensioni appropriate, qdisc moderni come fq_codel o fq, controllo della congestione BBR, buffer ad anello espansi, RSS/RPS abilitati, swap e zram sotto controllo, file temporanei nella RAM e un ambiente desktop ottimizzato), diventa chiaro che irqbalance è solo un altro pezzo di un puzzle piuttosto grandeIl suo ruolo è fondamentale nei server multi-core e ad alto traffico, irrilevante in molti desktop e controproducente nei sistemi con latenza estrema in cui sono preferite le affinità manuali; comprendere bene questo contesto è fondamentale per decidere se lasciarlo funzionare, limitarlo o semplicemente disattivarlo.