Pokročilý sprievodca optimalizáciou jadra Linuxu a znížením latencie

Informatec Digital » Zdroje » Pokročilý sprievodca optimalizáciou jadra Linuxu a znížením latencie

Keď hovoríme o výkone v Linuxe, takmer všetko nakoniec poukazuje na to isté: jadro ako ústredný komponent, ktorý riadi latenciu, stabilitu a využívanie zdrojov . Jeho jemné doladenie môže znamenať rozdiel medzi systémom, ktorý si len „zaobchádza“, a systémom, ktorý plynule reaguje na serveroch, desktopoch, cloudových prostrediach alebo dokonca na veľmi starom hardvéri.

Táto príručka sa zameriava na to, ako optimalizovať jadro Linuxu s cieľom minimalizovať latenciu bez ohrozenia bezpečnosti alebo údržby . Pokryjeme všetko od základných architektonických konceptov až po úpravy pomocou sysctl, kompiláciu vlastných jadier, používanie záplat v reálnom čase, ladenie sietí s nízkou latenciou (ako napríklad EC2) a techniky monitorovania a porovnávania na meranie, či vaše úpravy skutočne zlepšujú výkon.

Architektúra jadra Linuxu a kľúčové body latencie

Linuxové jadro funguje ako sprostredkovateľská vrstva medzi aplikáciami a hardvérom, spravuje pamäť, procesy, prerušenia, ovládače a súborové systémy . Jeho monolitický, no modulárny dizajn vďaka načítateľným modulom umožňuje flexibilné zapínanie alebo vypínanie funkcií bez nutnosti rekompilácie celého systému.

Pre pochopenie zdroja latencie je nevyhnutné pochopiť niekoľko subsystémov: plánovač procesov , správu pamäte a spracovanie prerušení. Zle nakonfigurovaný plánovač, agresívna politika pamäte alebo nadmerný počet nekontrolovaných prerušení môže viesť k pomalým časom odozvy, a to aj pri výkonnom hardvéri.

Do hry vstupujú možnosti konfigurácie jadra, ako napríklad CONFIG_PREEMPT, CONFIG_PREEMPT_VOLUNTARY a CONFIG_SMP . Tieto určujú, do akej miery môže byť jadro preempované na riešenie naliehavejších úloh a ako zvláda viacjadrové systémy. Výber vhodného modelu preempcie výrazne mení vnímanú latenciu na stolových počítačoch, serveroch s nízkou latenciou alebo priemyselných systémoch.

V moderných serveroch je dôležitá aj topológia hardvéru: distribúcia jadier, sokety, NUMA a hierarchia vyrovnávacej pamäte . Jemné doladenie afinity CPU a politík NUMA (napríklad priradenie procesov a pamäte tomu istému uzlu) pomáha skrátiť časy prístupu a zlepšiť mieru zásahov do vyrovnávacej pamäte, čo je kľúčové pri minimalizácii jitteru a nepredvídateľných latencií.

Okrem toho interakcia medzi plánovačom CPU a I/O subsystémami (disk a sieť) určuje priepustnosť a latenciu medzi aplikáciami. Pred vykonaním akýchkoľvek zmien je vhodné zdokumentovať aktuálny stav (konfigurácia jadra, sysctl, GRUB, načítané moduly), aby sa umožnil rýchly návrat k predchádzajúcej zmene, ak zmena zhorší výkon.

Úpravy cez sysctl na zlepšenie latencie a výkonu

Rozhranie sysctl umožňuje upravovať parametre jadra za chodu cez /proc/sys bez nutnosti rekompilácie. Je to ideálny vstupný bod pre ladenie bez toho, aby ste sa museli zaoberať kompiláciami.

V sieťovom prostredí parametre ako net.core.rmem_max, net.core.wmem_max a net.ipv4.tcp_congestion_control priamo ovplyvňujú priepustnosť, latenciu a správanie TCP pripojenia. Správne nastavenie vyrovnávacích pamätí a algoritmu preťaženia je nevyhnutné pre webové servery s vysokou prevádzkou alebo cloudové inštancie s nízkou latenciou.

V prípade pamäte vám hodnoty ako vm.swappiness, vm.dirty_ratio, vm.vfs_cache_pressure a vm.overcommit_memory umožňujú kontrolovať, koľko swapu sa používa, ako sa spravuje vyrovnávacia pamäť stránok a správanie virtuálnej pamäte. Zníženie swappiness (napríklad na 10) zvyčajne pomáha zabrániť príliš častému používaniu swapu systémom, čím sa znižujú špičky latencie spôsobené diskovými I/O operáciami.

Ak pracujete s rozsiahlymi databázami alebo aplikáciami, ktoré používajú obrovské množstvo zdieľanej pamäte, je dôležité upraviť kernel.shmall, kernel.shmall a maximálny počet otvorených súborov pomocou fs.file-max a fs.nr_open . Nesprávne nastavené limity môžu spôsobiť úzke miesta a chyby, ktoré je ťažké diagnostikovať pri záťaži.

Odporúča sa vykonať malé zmeny, merať ich vplyv pomocou monitorovacích nástrojov a až potom ich uložiť do súboru /etc/sysctl.conf alebo /etc/sysctl.d/ . V kontajnerových prostrediach nezabudnite, že mnohé parametre jadra sú pre hostiteľa globálne: neopatrné úpravy môžu ovplyvniť všetky služby, takže kombinovanie sysctl s cgroups a mennými priestormi je takmer povinné.

Kompilácia a údržba vlastných jadier

Kompilácia vlastného jadra zostáva mocným nástrojom, keď chcete znížiť latenciu, odstrániť zbytočnú réžiu alebo podporovať nezvyčajný hardvér . Hoci distribúcie obsahujú pomerne všestranné jadrá, v určitých scenároch je konkrétne jadro kľúčové.

Klasický pracovný postup zahŕňa stiahnutie kódu z kernel.org alebo opravené stromy ako xanmod alebo liquorixa používať nástroje ako make menuconfig vybrať možnosti. Uloženie súboru .config do vášho vlastného git repozitára spolu so skriptami zostavenia vám umožňuje reprodukovať zostavenia a zachovať konzistenciu medzi verziami.

Ak používate Debian alebo jeho deriváty, je veľmi pohodlné kompilovať ho „ debianským spôsobom “, aby ste získali .deb balíčky jadra, hlavičkové súbory a súvisiace knižnice. To vám umožňuje nasadiť toto vlastné jadro na viacero počítačov jednoduchou inštaláciou balíčkov a správou verzií pomocou vlastného repozitára.

V reálnom svete má ručná kompilácia často zmysel pri práci so starým alebo veľmi obmedzeným hardvérom . Typickým príkladom je starý netbook s procesorom Atom a 1 GB RAM, kde moderné generické jadro plné nepotrebných ovládačov a možností serverovej úrovne prináša latenciu a dodatočné využitie CPU, ktoré si nemôžete dovoliť.

Bežnou stratégiou je začať s aktuálnou konfiguráciou jadra (napríklad skopírovaním konfiguračného súboru z /boot ) a potom ho orezať alebo upraviť. Model preempcie môžete zmeniť na „ Preemptible Kernel (Low-Latency Desktop) “, aby ste uprednostnili interaktívnu odozvu pracovnej plochy, alebo pridať špecifické plánovače I/O, ako napríklad BFQ, ako modul na zlepšenie zážitku na mechanických diskoch.

Aby ste sa vyhli dlhému času kompilovania, má zmysel zostavovať na výkonnejšom počítači a v prípade potreby použiť krížovú kompiláciu (napríklad kompilácia 32-bitového jadra pre Atom z počítača x86_64 jednoduchou úpravou ARCH a príslušných nástrojov). Potom už len stačí nainštalovať súbory .deb na cieľový počítač a pridať príslušný záznam do GRUBu.

Najzložitejšou časťou je údržba: je vhodné testovať nové jadro na uzloch Kanárskych ostrovov , mať v správcovi zavádzania jasné cesty pre vrátenie zmien a počas prechodu zaznamenávať protokoly a metriky, aby sa zistili poklesy vo výkone alebo kompatibilite ovládačov.

Modely preempcie a záplaty PREEMPT_RT pre systémy s nízkou latenciou

Model preventívnej kontroly jadra určuje, do akej miery môže byť spustená úloha prerušená, aby ju mohla prevziať úloha s vyššou prioritou, čo priamo ovplyvňuje latenciu odozvy . To zahŕňa štandardné možnosti konfigurácie aj opravy v reálnom čase.

Generické jadrá ponúkajú niekoľko možností: žiadne preempcie (viac zamerané na priepustnosť servera), dobrovoľné preempcie a preemptibilné jadro pre desktopy , ktoré uprednostňuje rýchle časy odozvy pre interaktívne aplikácie. Úprava tohto nastavenia môže výrazne zlepšiť výkon desktopových systémov, zvukových aplikácií alebo dokonca starších, vysoko zaťažených počítačov.

Keď potrebujete zájsť o krok ďalej, objavia sa záplaty PREEMPT a PREEMPT_RT , ktoré upravujú dôležité časti jadra, aby sa minimalizovali nepreemptabilné sekcie. PREEMPT_RT je určený pre systémy, kde musí byť latencia v najhoršom prípade (nielen priemerná) veľmi nízka a predvídateľná: priemyselná automatizácia, profesionálne audio, telekomunikácie alebo vysokofrekvenčný obchod.

Rozhodnutie zaviesť PREEMPT_RT by nemalo byť založené na trendoch, ale skôr na konkrétnych meraniach latencie a jitteru . Najprv je vhodné dôkladne preskúmať nastavenia plánovača, afinity CPU, sysctl a prípadne konfigurácie, ako je dynamické beztickové ovládanie, predtým, ako komplikujete údržbu stromom RT.

Je potrebné zvážiť aj kompatibilitu: niektoré ovládače a subsystémy nie sú úplne prispôsobené pre RT a môžu vyžadovať špecifické verzie alebo dodatočné záplaty. Rozumným prístupom je pripraviť plán údržby, ktorý jasne načrtáva, kedy a ako integrovať nové verzie hlavného jadra s vetvou RT, ktorá sa síce pravidelne synchronizuje, ale stále trochu zaostáva.

Ladenie plánovania CPU, beztieková prevádzka a izolácia jadier

Okrem výberu modelu preempcie môžete jemne doladiť latenciu aj hraním sa s plánovaním CPU a správaním časovača jadra, najmä v podnikovo orientovaných distribúciách, ako je RHEL.

Napríklad Red Hat Enterprise Linux 8 je dodávaný s predvoleným jadrom bez tickless pre nečinné procesory , ktoré znižuje spotrebu energie tým, že sa vyhýba periodickým prerušeniam, keď je jadro nečinné. Pre pracovné zaťaženia citlivé na latenciu je možné na sade jadier povoliť dynamický režim bez tickless , takže iba jeden procesor („domovské jadro“) spracováva väčšinu úloh časovania a ostatné sú čo najviac bez periodických prerušení.

Táto konfigurácia sa vykonáva pridaním príslušných parametrov do príkazový riadok jadra v GRUBeregenerácia konfigurácie a následná úprava afinity kritických vlákien jadra, ako sú napríklad vlákna RCU alebo vlákna bdi-flush, takže sa nachádzajú v jadre vyhradenom pre údržbu.

Tento prístup je možné doplniť parametrom `isolcpus` , ktorý umožňuje izolovať jadrá od bežných úloh v používateľskom priestore. V scenároch s nízkou latenciou je veľmi bežné rezervovať niekoľko jadier výhradne pre kritickú aplikáciu, zatiaľ čo zvyšok systému (démony, prerušenia atď.) je zabezpečený inými jadrami.

Na overenie fungovania dynamického režimu bez ticknutia je možné spustiť jednoduché testy pomocou stress alebo skripty, ktoré na sekundu zamestnajú CPU a potom ho pozorujú počítadlá časovačov Ako počet prerušení za sekundu klesne z tisícov na iba jedno v izolovaných jadrách, čo je znakom toho, že periodický časovač zmizol.

Správa pamäte a úložiska so zameraním na latenciu

Spôsob, akým jadro spravuje pamäť a diskové I/O operácie, má obrovský vplyv na latenciu vnímanú aplikáciami , najmä v databázach a službách, ktoré vykonávajú veľa malých, častých operácií.

Na strane pamäte, zníženie vm.swappiness minimalizuje využitie swapu (ktorý je takmer vždy oveľa pomalší ako RAM), vm.vfs_cache_pressure riadi, ako rýchlo musí systém uvoľniť vyrovnávaciu pamäť inode a dentry, a vm.nr_hugepages umožňuje rezervovať statické HugePages pre veľké záťaže, ako sú databázy alebo JVM, čím sa znižuje réžia TLB.

V úložisku vyberte vhodný plánovač I/O podľa typu disku Je to kritické. Na moderných SSD diskoch je zvyčajne dobrý nápad použiť... none o mq-deadlineZatiaľ čo v mechanických diskoch a multitaskingových systémoch by algoritmy navrhnuté pre spravodlivosť mohli byť lepšie, ako napríklad BfqOkrem toho, montáž súborových systémov s možnosťami, ako napríklad noatime y nodiratime Vyhnite sa zbytočným zápisom pri každom prístupe k súboru alebo adresáru.

Pokiaľ ide o súborové systémy, ext4 a XFS zostávajú najbežnejšou voľbou: dobre vyladený ext4 je bezpečnou voľbou, zatiaľ čo XFS má tendenciu lepšie škálovať pri vysokej súbežnosti. Pre veľmi náročné scenáre môže kombinácia RAID (RAID 10 pre databázy, RAID 0 pre dočasné úložisko) s dobrým plánovačom znížiť priemernú latenciu a predovšetkým variabilitu.

Optimalizácia siete a jadra pre nízku latenciu v Linuxe a EC2

Vo vysokovýkonných sieťových aplikáciách latencia závisí nielen od hardvéru alebo vzdialenosti, ale aj od konfigurácie TCP/IP stacku a samotného jadra . Toto je obzvlášť viditeľné v cloudových inštanciách, ako je Amazon EC2 s rozhraniami ENA.

V prvom rade je kľúčové znížiť externé faktory, ako je počet sieťových skokov , ktoré pakety vykonávajú: použitie priamejších topológií, vyrovnávačov záťaže blízko backendu alebo optimalizovaných zón dostupnosti skracuje čas prenosu v milisekundách ešte predtým, ako sa pakety vôbec dotknú operačného systému.

V jadre zahŕňa konfigurácia siete zvýšenie počtu deskriptorov súborov (ulimit -n) , zmenu veľkosti prijímacích a odosielacích vyrovnávacích pamätí pomocou net.core.rmem_max, net.core.wmem_max, net.ipv4.tcp_rmem, net.ipv4.tcp_wmem a povolenie možností, ako napríklad TCP Fast Open, na zníženie latencie nadväzovania pripojenia.

V rozhraniach AWS ENA hrá moderovanie prerušení dôležitú úlohu: ovládač štandardne zoskupuje pakety, aby znížil počet IRQ. rx-usecs a tx-usecsAk chcete znížiť latenciu na absolútne minimum, môžete túto moderáciu vypnúť ethtool -CNastavenie rx-usecs a tx-usecs na nulu znižuje latenciu, ale zvyšuje réžiu prerušení, takže je potrebné nájsť rovnováhu v závislosti od záťaže.

Môžete tiež použiť irqbalance na distribúciu IRQ medzi viacero jadier alebo ho vypnúť a manuálne nastaviť afinity prerušení a sieťového frontu (RSS/RPS) ku konkrétnym jadrám, čo je veľmi bežné v prostrediach s ultranízkou latenciou alebo pri použití DPDK a preskočení veľkej časti zásobníka jadra.

Ďalším parametrom, ktorý treba zvážiť, sú stavy C procesora : stavy hlbokého spánku znižujú spotrebu energie, ale zavádzajú oneskorenia pri „prebudení“ jadra. Na zníženie latencie odozvy môžete tieto hlboké stavy obmedziť, akceptovať vyššiu spotrebu energie a menší priestor pre Turbo Boost na ostatných jadrách. Každé prostredie má svoj vlastný optimálny pomer medzi spotrebovanými wattmi a získanými mikrosekundami.

Optimalizácia CPU, služieb a aplikácií na zníženie latencie

Okrem samotného jadra má o celkovej latencii veľa čo povedať aj okolité prostredie: od služieb aktívnych v systéme až po špecifickú konfiguráciu každej aplikácie.

Vysokovýkonný server by mal spúšťať iba démoni, ktorí sú skutočne nevyhnutníSlužby ako Bluetooth, tlač alebo automatické vyhľadávanie siete (CUPS, Avahi atď.) na serverových počítačoch spotrebúvajú iba procesor, pamäť a vstupno-výstupné operácie bez toho, aby poskytovali akýkoľvek úžitok. Skontrolujte s systemctl list-unit-files --state=enabled A deaktivácia nepotrebných vecí je jednou z najlacnejších a najefektívnejších vecí, ktoré môžete urobiť.

Na stanovenie priorít kritických procesov môžete použiť nástroje ako renice, chrt a taskset . Úprava priority procesu (renice), priradenie plánovania v reálnom čase (chrt -f 99) alebo priradenie ku konkrétnym jadrám (taskset) znižuje interferenciu s inými úlohami a zlepšuje predvídateľnosť CPU pre databázy, VoIP, streamovanie alebo obchodné služby.

Na úrovni aplikácie je ladenie rovnako dôležité ako ladenie jadra. Webové servery ako Nginx alebo Apache potrebujú jemné doladenie workerov, funkcie keepalive, vyrovnávacích pamätí a kompresie. Databázy ako PostgreSQL alebo MySQL vyžadujú kontrolu veľkostí vyrovnávacích pamätí, kontrolných bodov, poolov pripojení a parametrov synchrónneho zápisu, aby sa dosiahla nízka a stabilná latencia.

JVM tiež zohráva úlohu: výberom garbage collectorov, ako sú G1GC alebo ZGC, a úpravou veľkosti haldy sa dajú znížiť pauzy, ktoré sa zvonku javia ako latencia. Vo virtualizovaných a kontajnerových prostrediach správne prideľovanie kvót vCPU, vRAM a I/O zabraňuje tichému súpereniu, ktoré sa neskôr prejavuje ako nekonečné diskové fronty alebo preťaženie CPU.

Monitorovanie a benchmarking jadra a systému

Všetko toto ladenie je zbytočné, ak nemeriate dopad. Kľúčom je kombinovať nepretržité monitorovanie s reprodukovateľnými výkonnostnými testami , aby sa každá zmena v jadre alebo sysctl dala vyhodnotiť pomocou objektívnych údajov.

Na zobrazenie celkového stavu systému môžete použiť klasické nástroje, ako napríklad htop, vmstat, iotop o sarKeď potrebujete viac podrobností, prichádzajú do úvahy špecifické nástroje jadra, ako napríklad výkon a ftracektoré vám umožňujú sledovať správanie plánovača, prerušení a interných volaní so značnou presnosťou.

V produkčných prostrediach je vhodné nasadiť metrické systémy ako Prometheus, collectd alebo sysstat s exportérmi , ktoré zobrazujú počítadlá CPU, I/O, latencie diskov a siete, fronty procesov atď. Vizualizácia týchto údajov v Grafane alebo podobných nástrojoch pomáha odhaliť regresie alebo anomálie skôr, ako si koncový používateľ všimne problémy.

Pri benchmarkingu je cieľom replikovať skutočné pracovné zaťaženie a porovnať stav „pred a po“ každej zmene. Nástroje ako sysbench (pre CPU a databázy), fio (pre disk) alebo iperf3 (pre sieť) umožňujú vytvárať opakovateľné scenáre. Je nevyhnutné zdokumentovať verzie jadra, konfigurácie sysctl, hardvér a testovacie parametre , aby boli porovnania v priebehu času zmysluplné.

V praxi je optimalizácia jadra Linuxu iteratívny proces: otestujete sériu vylepšení, zmeriate výsledky, ponecháte si tie, ktoré prinášajú skutočný úžitok, a zvyšok zahodíte. S dobrou správou zmien môžete premeniť vylepšenia v nových verziách jadra (ako napríklad nedávne série s vylepšeniami plánovača, grafiky, napájania alebo siete) na merateľné výhody pre vaše aplikácie, či už ide o lokálne servery, cloud alebo náročné pracovné stanice.

Kombinácia znalostí architektúry jadra, jemného doladenia pomocou sysctl, riadenej kompilácie, selektívneho používania záplat v reálnom čase a dobrého systému metrík umožňuje správcovi alebo operačnému tímu dosiahnuť rýchlejšie odozvy, nižšie latencie a lepšiu celkovú stabilitu bez nutnosti meniť hardvér pri najmenšej provokácii alebo ohroziť bezpečnosť systému.