K čemu se v Linuxu používá IRQbalance a jak zapadá do pokročilé optimalizace?

Když začnete ladit s výkonem systému GNU/Linux, dříve či později se objeví opakující se protagonista: irqbalance a distribuce hardwarových přerušení mezi procesory . Diskutuje se o tom na fórech, v dokumentaci k distribucím a tutoriálech o „ladění“ systému, aby fungoval... ale jen zřídka je jasně vysvětleno, co to vlastně dělá, v jakých scénářích to prospívá a ve kterých si toho vůbec ničeho nevšimnete.

Navíc se veškeré toto vyvažování IRQ zaplétá s dalšími pokročilými koncepty: NAPI, fronty příjmu jádra, vyrovnávací paměti síťových karet, algoritmy pro řízení zahlcení TCP, RSS/RPS, BBR, nastavení sysctl, výkonnostní démony jako preload, swap komprimovaný zramem, optimalizace GTK, dočasné soubory v RAM atd. Je velmi snadné se ztratit mezi parametry, příkazy a konfiguračními soubory, aniž byste jasně pochopili, co každá věc dělá.

Co je IRQbalance a k čemu se vlastně v Linuxu používá?

irqbalance je démon v uživatelském prostoru, který distribuuje hardwarová přerušení (IRQ) mezi jádra CPU v SMP (víceprocesorových nebo vícejádrových) systémech. Jeho účel není magický: jeho cílem je jednoduše zabránit tomu, aby veškerá zátěž obslužných zařízení (síť, disky, USB atd.) dopadla na stejné jádro.

Když zařízení generuje IRQ, jádro spustí obslužnou rutinu přerušení. Pokud je mnoho těchto přerušení soustředěno na jednom CPU, může být toto CPU přetíženo, zatímco ostatní zůstanou nečinné. Irqbalance analyzuje objem přerušení na zařízení a přiřazuje každé IRQ vhodnému jádru pro rozložení zátěže a zároveň se snaží minimalizovat ztráty v mezipaměti a respektovat logické afinity (například udržuje IRQ ze stejného síťového rozhraní související).

V systémech s jedním CPU nebo jádry, která plně sdílejí L2 cache , irqbalance sám zjistí, že nemá nic užitečného na práci, a vypne se. Nejedná se o chybu; jednoduše není prostor pro zlepšení. Na serverech s více fyzickými CPU nebo mnoha jádry, zejména s velkým síťovým provozem nebo vysokým počtem I/O operací, to však může mít vliv na latenci a stabilitu.

Démon může běžet na pozadí (servisní režim) nebo podle potřeby s volbou –jednorázový, Také, umožňuje vyloučení specifických IRQ podle možnosti --banirq a zabránit mu v používání určitých jader s maskou CPU definovanou v proměnné prostředí IRQBALANCE_BANNED_CPUSToto vše se obvykle ovládá z konfiguračního souboru, který se v mnoha distribucích nachází v /etc/default/irqbalance o /etc/irqbalance.env.

Vyvažování IRQ: kernel vs. irqbalance a kdy je to patrné

Linux již má svůj vlastní interní mechanismus pro rozhodování, který procesor zpracovává která IRQ, aniž by potřeboval irqbalance. Jádro může nastavit afinity přerušení a distribuovat je pomocí jednoduché heuristiky a na mnoha stolních počítačích je to více než dostatečné: průměrný uživatel si nevšimne žádného rozdílu mezi povolením nebo zakázáním irqbalance.

Proto je poměrně běžné, že si někdo vyzkouší irqbalance na své desktopové distribuci a řekne: „Nevšiml jsem si žádného zlepšení, ale ani nic špatného .“ To je naprosto normální. Na notebooku s čtyřjádrovým procesorem a jednou síťovou kartou bez velké zátěže I/O už plánovač Linuxu a interní mechanismy jádra (NAPI, síťové fronty atd.) udržují věci v rozumné rovnováze.

Smysl to dává na vícejádrových serverech s intenzivním provozem : velké databáze , reverzní proxy, webové servery s vysokým provozem, úložiště záloh , silně zatížené virtuální počítače atd. V těchto situacích se může stát, že mnoho síťových nebo diskových IRQ připnutých k jednomu jádru se stane úzkým hrdlem. Jejich efektivní distribuce snižuje fronty, doby obsluhy a špičky latence.

Někteří uživatelé dávají přednost použití irqbalance namísto irqbalance. parametrizovat jádro pomocí voleb jako například acpi_irq_balance v GRUBu. Tento parametr ovlivňuje, jak ACPI a jádro alokují IRQ, ale nenabízí stejnou dynamickou flexibilitu jako irqbalance, který přehodnocuje alokaci na základě skutečné zátěže. Jsou to různé přístupy: první je statičtější a nízkoúrovňový; druhý je adaptivnější.

V prostředích s ultranízkou latencí (například některé obchodní platformy nebo sítě s DPDK) dochází k opaku: irqbalance je obvykle zakázáno a IRQ jsou ručně přiřazována konkrétním jádrům spolu s pečlivým mapováním mezi frontami síťových karet a procesory. V těchto scénářích se usiluje o absolutní kontrolu a obětuje se určitá automatizace.

Přerušení, NAPI a síťové fronty: jak do toho zapadá IRQbalance

Abychom lépe pochopili roli irqbalance, musíme se podívat na další úroveň a na to, jak s nimi Linux nakládá. přerušení sítě a příjem paketůSíťový subsystém jádra kombinuje několik klíčových komponent: NAPI, fronty příjmu (DMA buffer), parametry net.core.*, algoritmy pro správu front (qdisc) a laterální škálování (RSS/RPS).

NAPI (New API) je mechanismus, kterým jádro snižuje počet přerušení při příchodu velkého provozu. Místo vyvolání IRQ pro každý paket generuje síťová karta přerušení, které indikuje „čeká na práci“, a jádro dotazuje frontu příjmu, dokud není prázdná nebo dokud není vyčerpán časový/paketový rozpočet. To snižuje jitter a zlepšuje výkon, i když to může také způsobit určité kolísání latence.

Fronta, kam pakety přistávají před zpracováním síťovým zásobníkem, se běžně nazývá fronta příjmu jádra nebo DMA buffer . Její kapacita je omezena parametry, jako například:

• net.core.netdev_max_backlog: maximální počet paketů ve frontě pro příjem softwaru, když je jádro nedokáže zpracovat rychlostí, s jakou přicházejí.
• net.core.netdev_budget_usecs: „rozpočet“ času v mikrosekundách, který má NAPI k dispozici pro vyprázdnění front v každém cyklu.
• net.core.dev_weight: počet paketů zpracovaných na rozhraní v každém kole v rámci daného rozpočtu.

Si netdev_max_backlog je velmi nízký a síťová karta odesílá více paketů, než jádro dokáže zpracovat, začneme v /proc/net/softnet_statTypický výchozí bod pro jemné doladění na serverech s vysokou návštěvností je v rozsahu 4000 balení, nakonfigurováno v /etc/sysctl.conf s něčím jako:

net.core.netdev_max_backlog = 4000

Po úpravě se aplikuje s sysctl -p nebo s sysctl -w dochvilný. Tímto způsobem, ocas lépe absorbuje příletové špičky bez ztráty paketů, pokud zbytek procesní cesty obstojí.

V celém tomto obvodu irqbalance rozhoduje, které CPU zpracovává IRQ spojená se síťovým rozhraním. Pokud soustředíme všechna přerušení síťové karty na jedno jádro, toto jádro bude spouštět rutiny NAPI a vyprázdní frontu samostatně . Pokud efektivně rozdělíme IRQ a použijeme mechanismy jako RSS nebo RPS, může více CPU spolupracovat na zpracování paketů, čímž se sníží počet front a ztráta paketů.

Jemné doladění front, vyrovnávacích pamětí a TCP oken pro náročný provoz

Pokud server zpracovává velké množství dat (například zálohy, FTP provoz, velké soubory nebo replikaci databází), nestačí pouze mít povolený irqbalance. Je třeba harmonizovat několik úrovní: fronty jádra, vyrovnávací paměti síťového rozhraní, velikosti oken TCP a parametry zahlcení , aby vše fungovalo stejným směrem.

První blok nastavení se nachází ve vyrovnávací paměti pro příjem paketů a v okně TCP . Linux zpřístupňuje parametry jako například:

• net.ipv4.tcp_rmemTriplet (minimum, výchozí, maximální) paměti pro příjem TCP na socket.
• net.ipv4.tcp_wmemekvivalent pro dopravu.
• net.core.rmem_max y net.core.wmem_max: maximální pevná vyrovnávací paměť, kterou může aplikace vyžadovat.

Praktickým způsobem, jak tyto hodnoty upravit pro gigabitové spojení s nízkou latencí, je vypočítat součin šířky pásma a zpoždění (BDP) a použít faktor škálování (díky možnosti škálování okna TCP , která je ve většině moderních jader ve výchozím nastavení povolena). V praxi mnoho administrátorů skončí s maximálními hodnotami několika megabajtů, například:

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

Toto maximum ~10,8 MB pochází ze specifických výpočtů pro spojení 1 Gb/s s velmi nízkým RTT (~0,00017 s). Čím vyšší je propustnost nebo latence, tím větší musí být vyrovnávací paměť, aby se využila šířka pásma bez omezení oknem vyrovnávací paměti.

Je důležité vztáhnout toto maximum k velikosti fronty pro příjem paketů. Pokud netdev_max_backlog = 4000 a každý efektivní paket má přibližně 1480 bajtů, představuje tato fronta přibližně 5,9 MB. Vyrovnávací paměť okna TCP musí být větší než kapacita fronty , jinak ztratíme pakety, protože se vyrovnávací paměť zaplní dříve než fronta.

Pro sledování ztrát lze použít příkazy, jako například následující:

• cat /sys/class/net/eth0/statistics/rx_dropped: pakety ztracené v síťové kartě.
• watch -n 1 -t -d cat /proc/net/softnet_stat: počet zpracovaných, vyřazených, časově omezených atd. sloupců na CPU.
• watch -n 1 -t -d "netstat -s | grep err"chyby síťového zásobníku.

Pokud netstat indikuje chyby, ale /proc/net/softnet_stat ne , ke ztrátám s největší pravděpodobností dochází mimo našeho hostitele (podél cesty, přes mezilehlý firewall atd.). Kvůli algoritmům pro řízení přetížení budou určité ztráty vždy přítomny, ale měly by zůstat zvládnutelné a korelovat s nárůstem provozu.

Správa front (qdisc), QoS a řízení přetížení TCP

I když jsou interní fronty jádra kritické, stejně tak je důležitá i disciplína řazení do front (qdisc) spojená se síťovými rozhraními . Ta určuje, jak jsou pakety na výstupu řazeny, seskupovány a zahazovány, a může mít vliv na zmírnění jevů, jako je nadýmání (bufferbloat).

Linux nabízí několik relevantních qdisc :

• pfifo_fastStará výchozí disciplína, FIFO se třemi prioritními pásmy.
• fq_codelKombinace fair queuingu s CoDel pro boj s bufferbloatem, vysoce doporučeno pro routery a obecné použití.
• fqJednoduché spravedlivé řazení do fronty, velmi užitečné na vysoce zatížených serverech.
• dort (dort): dnes nejpokročilejší, ale vyžaduje kompilaci nebo přítomnost modulu v jádře.

Výchozí qdisc vypadá takto:

sysctl net.core.default_qdisc

A lze jej vyměnit za provozu pomocí:

sysctl -w net.core.default_qdisc=fq_codel

Aby se zajistilo, že konkrétní rozhraní používá určitou disciplínu, uchýlí se k tc:

sudo tc qdisc nahradit dev eth0 root fq_codel

V souvislosti s tím má algoritmus pro řízení přetížení TCP vliv i v prostředích WAN nebo v prostředích s masivním provozem. Jádro nabízí několik algoritmů (cubic, reno atd.) a mezi moderní verze patří BBR, vyvinutý společností Google , který obvykle zlepšuje trvalou propustnost bez výrazného zvýšení latence. Aktivuje se pomocí:

sudo sysctl -w net.ipv4.tcp_congestion_control=bbr

Seznam dostupných algoritmů si můžete prohlédnout v modulech. tcp_* en /lib/modules/<versión>/kernel/net/ipv4/. Zkombinujte BBR s vhodným qdisc (fq/fq_code) a dobrou konfigurací bufferu. To má za následek mnohem stabilnější datové toky.

Pokročilá nastavení síťové karty: vyrovnávací paměti kruhového provozu, RSS, RPS a odlehčení zátěže

Samotná síťová karta má také vlastní sadu front a vyrovnávacích pamětí: přijímací (RX) a vysílací (TX) kruhové vyrovnávací paměti . Jejich maximální velikost závisí na hardwaru a zobrazuje se následovně:

ethtool -g ethX

Pole „Přednastavené maxima“ označují, o kolik lze hodnoty zvýšit. Pokud to karta umožňuje, lze hodnoty RX a TX zvýšit na hodnoty jako 4096, 8192 nebo 16384 pomocí:

ethtool -G ethX rx 4096 tx 4096

Pokud se zobrazí chyba, například „Nelze nastavit parametry vyzvánění zařízení: Neplatný argument“, tato hodnota překračuje možnosti síťové karty a bude nutné vyzkoušet menší děliče.

Aby se zabránilo tomu, aby jeden procesor zpracovával veškerou přijímací zátěž , mnoho moderních síťových karet implementuje Receive Side Scaling (RSS) , čímž vytváří více hardwarových front spojených s různými jádry. V Linuxu je tato distribuce reprezentována takto:

cat /proc/interrupts | grep

Na kartách bez RSS lze něco podobného „emulovat“ pomocí RPS (Receive Packet Steering) , přiřazováním CPU softwarovým frontám rozhraní:

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

Hodnota je hexadecimální maska. Například f V binárním kódu (1111) to znamená použití prvních čtyř jader. Jádro musí být zkompilováno s CONFIG_RPS Aby to fungovalo.

Můžete si také hrát s odlehčení kontrolních součtů a segmentace přesunout práci z CPU na procesor síťové karty. ethtool -k Aktivované funkce jsou viditelné a lze zapnout například tyto:

ethtool -K ethX rx zapnuto (ověření kontrolního součtu na recepci)
ethtool -K ethX tso on (Odlehčení segmentace TCP)

Aby tyto změny byly trvalé, jsou obvykle umístěny v síťových skriptech (/etc/network/interfaces v Debianu/Ubuntu, /etc/sysconfig/network-scripts/ifcfg-ethX v Red Hatu) nebo v pravidlech udev.

Ručně dolaďte afinitu IRQ a pracujte s IRQbalance

Ve starších jádrech nebo v případech, kdy chceme jemnou kontrolu, je možné Ručně přiřaďte, který CPU zpracovává konkrétní IRQ.Všechny informace jsou v /proc/irq y /proc/interruptsTypický tok by byl:

• Zobrazit přerušení: cat / proc / přerušení a vyhledejte linku síťového rozhraní (např. IRQ 25 pro enp0s8).
• Zkontrolujte aktuální afinitu: cat /proc/irq/25/smp_affinity (hexadecimální maska: 02 = CPU1, 01 = CPU0, 04 = CPU2 atd.).
• Změňte to: echo 1 > /proc/irq/25/smp_affinity přesunout ho do CPU0.

Tímto způsobem můžete například odlehčit přesycený procesor přesunutím IRQ na méně vytížené jádro. Pokud máte nainstalovaný a povolený irqbalance, je důležité mu říct, aby se daného přerušení nedotýkal, přidáním volby, jako je tato:

MOŽNOSTI="--banirq=25"

en /etc/default/irqbalancenebo pomocí možnosti --banirq=25 Když démon začne. Takhle Vynecháváte to z logiky automatické distribuce. a respektujete své manuální zadání.

Takže se to mění jako echo 1 > /proc/irq/25/smp_affinity přežít restartyObvykle se přidávají ke klasickému /etc/rc.local (pokud je povoleno) nebo ke konkrétním jednotkám systemd.

Další související nastavení výkonu: swap, zram, dočasné soubory, předběžné načítání

Veškerá tato práce na vylepšení odezvy sítě a distribuce IRQ je obvykle doprovázena dalším laděním systému , které sice není přímo spojeno s irqbalance, ale dotváří celkový obraz výkonu.

V oblasti paměti mnoho administrátorů snižuje agresivní využití swapu modifikující /etc/sysctl.conf s parametry jako například:

• vm.swappiness: jak moc jádro preferuje používat swap (0-100, výchozí 60). Nízké hodnoty (1-10) upřednostňují RAM.
• vm.vfs_cache_pressureTlak na inode a dentry cache. Jeho snížení pomáhá uchovávat metadata v RAM.
• vm.dirty_writeback_centisecs y vm.dirty_expire_centisecs: četnost a platnost zápisu nečistých stránek na disk.
• vm.dirty_ratio y vm.dirty_background_ratioProcento paměti, které lze zaplnit nečistými daty před vynuceným zápisem.

S vhodnými hodnotami (například vm.swappiness=1 , vm.vfs_cache_pressure=50 atd.) lze systém nastavit tak, aby před zahájením stránkování využíval více RAM , což je žádoucí u serverů s velkým množstvím paměti.

Dalším klasickým opatřením je přesunout dočasné adresáře do paměti RAM montáž je jako tmpfs en /etc/fstab:

tmpfs /tmp tmpfs čas_procedury, čas_procedury_nod, čas_procedury_nodev, ID_procedury_nosuid, režim=1777, výchozí 0 0
tmpfs /var/tmp tmpfs čas_pouze, ...

To umožňuje provádět dočasné přístupy (kompilace, pracovní soubory aplikací atd.) rychlostí RAM , což snižuje opotřebení SSD disků.

V prostředí s nízkými zdroji je také běžné aktivovat zram-swapKomprimované odkládací zařízení v RAM. Instaluje se z repozitáře (například pomocí Gitu klonováním). zram-swap a vykonávání jeho install.sh) a vytvoří komprimované blokové zařízení, kde systém provádí swapování, než se uchýlí k swapování disku, pokud je to možné. Získáte efektivní paměť za cenu o něco vyššího výkonu CPU.který kompenzuje mnoho zatížení.

A konečně, démony jako preload analyzují, které aplikace běží nejčastěji, a předběžně načítají jejich binární soubory a knihovny do RAM, čímž urychlují jejich spouštění za cenu spotřeby paměti. To dává smysl na stolních počítačích s dostatkem RAM; na serverech s velmi omezenými zdroji se to obvykle vynechává.

GTK, GRUB, Firefox a další vylepšení pro „kvalitu života“

Kromě čistě serverového výkonu obsahuje mnoho tutoriálů dlouhé části o optimalizaci prostředí na počítači : doba odezvy nabídky GTK, písma, tmavá témata, zvuk, chování myši atd. I když tyto prvky přímo neovlivňují vyvážení IRQ ani síťový provoz, přispívají k rychlejší odezvě systému.

V GTK2, GTK3 a GTK4 lze provádět úpravy. desítky parametrů v souborech, jako například ~/.gtkrc-2.0, ~/.config/gtk-3.0/settings.ini o ~/.config/gtk-4.0/settings.iniAnimace, časování dvojitého kliknutí, velikost kurzoru, design titulkového řádku, použití tmavých motivů, chování popisků nástrojů, vyhlazování písem atd. Tyto soubory se upravují ručně (pomocí nano) nebo přidáním řádků pomocí echo >> z terminál.

Verze jsou také obvykle upraveny. "globální" těchto parametrů v /etc/gtk-2.0/gtkrc, /etc/gtk-3.0/settings.ini y /etc/gtk-4.0/settings.ini, aby se ovlivnily všechny uživatele, vždy s ohledem na to, že v těchto případech musíte být root (prostřednictvím su - o sudo).

El čekací doba manažera bota GRUB Úpravami se zkracuje. /etc/default/grub a úpravy GRUB_TIMEOUT (například z 10 na 3 sekundy) a přidáním parametrů do jádra, jako například noresume o acpi_irq_balance en GRUB_CMDLINE_LINUX_DEFAULTPak se provede update-grub (Debian/Ubuntu) nebo grub-mkconfig -o /boot/grub/grub.cfg (Archivy a odvozené materiály).

V případě prohlížeče se jedná o soubory jako např. user.js pro Firefox Tato nastavení umožňují použít dávky předvoleb zaměřených na urychlení prohlížení: počet připojení, chování mezipaměti, kompresi, WebSockety atd. Obvyklý postup je resetovat profil, otevřít adresář profilu z „Informací o řešení problémů“, zavřít Firefox a vložit následující: user.js ve složce profilu a znovu otevřete prohlížeč.

I když to vše souvisí s tématem irqbalance, ilustruje to důležitou myšlenku: Optimalizace Linuxu je holistický proces . Nejde jen o démona nebo magický parametr, ale o jemné doladění CPU, paměti, disku, sítě, plochy a aplikací, dokud to neodpovídá skutečnému využití počítače.

Při pohledu na celkový obrázek – alokace IRQ pomocí irqbalance nebo ruční konfigurace, optimalizované NAPI a fronty, správně dimenzované TCP buffery, moderní qdisc jako fq_codel nebo fq, řízení zahlcení BBR, rozšířené kruhové buffery, povolený RSS/RPS, řízený swap a zram, dočasná RAM a jemně vyladěné desktopové prostředí – je zřejmé, že irqbalance je jen jedním dílkem poměrně velké skládačky . Jeho role je zásadní na vícejádrových serverech s intenzivním provozem, irelevantní na mnoha desktopech a kontraproduktivní na systémech s extrémně latencí, kde se preferuje ruční nastavení afinity. Pochopení tohoto kontextu je klíčové pro rozhodnutí, zda jej nechat fungovat, omezit jeho používání nebo jej úplně zakázat.