Napredni vodič za optimizaciju Linux kernela i smanjenje latencije

Informatec Digital » Resursi » Napredni vodič za optimizaciju Linux kernela i smanjenje latencije

Kada govorimo o performansama u Linuxu, gotovo sve na kraju ukazuje na istu stvar: kernel kao centralnu komponentu koja kontrolira latenciju, stabilnost i korištenje resursa . Njegovo fino podešavanje može napraviti razliku između sistema koji se samo "snalazi" i onog koji glatko reaguje na serverima, desktop računarima, cloud okruženjima ili čak na vrlo starom hardveru.

Ovaj vodič se fokusira na to kako optimizirati Linux kernel kako bi se minimizirala latencija bez ugrožavanja sigurnosti ili održivosti . Pokrit ćemo sve, od osnovnih arhitektonskih koncepata do podešavanja pomoću sysctl-a, kompajliranja prilagođenih kernela, korištenja zakrpa u stvarnom vremenu, podešavanja za mreže s niskom latencijom (kao što je EC2) i tehnika praćenja i mjerenja performansi kako bismo izmjerili da li vaša podešavanja zaista poboljšavaju performanse.

Arhitektura Linux kernela i ključne tačke za latenciju

Linux kernel djeluje kao posrednički sloj između aplikacija i hardvera, upravljajući memorijom, procesima, prekidima, drajverima i datotečnim sistemima . Njegov monolitni, ali modularni dizajn , zahvaljujući modulima koji se mogu učitati, omogućava fleksibilno omogućavanje ili onemogućavanje funkcionalnosti bez ponovnog kompajliranja cijelog sistema.

Da bi se razumio izvor latencije, ključno je razumjeti nekoliko podsistema: planer procesa , upravljanje memorijom i rukovanje prekidima. Loše konfigurisan planer, agresivna politika memorije ili prekomjeran broj nekontrolisanih prekida mogu rezultirati sporim vremenom odziva, čak i sa moćnim hardverom.

Opcije konfiguracije kernela kao što su CONFIG_PREEMPT, CONFIG_PREEMPT_VOLUNTARY i CONFIG_SMP dolaze do izražaja . One određuju stepen u kojem kernel može biti preemptovan kako bi se bavio hitnijim zadacima i kako se nosi sa višejezgrenim sistemima. Odabir odgovarajućeg modela preemptacije značajno mijenja percipiranu latenciju na desktop računarima, serverima sa niskom latencijom ili industrijskim sistemima.

Kod modernih servera, hardverska topologija je također važna: distribucija jezgara, utičnice, NUMA i hijerarhija keša . Fino podešavanje afiniteta CPU-a i NUMA politika (na primjer, dodjeljivanje procesa i memorije istom čvoru) pomaže u smanjenju vremena pristupa i poboljšanju stope pogodaka keša, što je ključno za minimiziranje podrhtavanja i nepredvidivih latencija.

Nadalje, interakcija između CPU planera i I/O podsistema (diska i mreže) određuje propusnost i latenciju od početka do kraja koju aplikacije doživljavaju. Prije bilo kakvih promjena, preporučljivo je dokumentirati trenutno stanje (konfiguracija kernela, sysctl, GRUB, učitani moduli) kako bi se omogućio brz povratak na prethodno stanje ako promjena pogorša performanse.

Prilagođavanja putem sysctl-a za poboljšanje latencije i performansi

sysctl interfejs vam omogućava da mijenjate parametre kernela u hodu putem /proc/sys, bez potrebe za ponovnim kompajliranjem. To je idealna početna tačka za podešavanje bez zaglavljivanja u kompajliranju.

U mrežnom okruženju, parametri kao što su net.core.rmem_max, net.core.wmem_max i net.ipv4.tcp_congestion_control direktno utiču na propusnost, latenciju i ponašanje TCP veze. Pravilno podešavanje bafera i algoritma zagušenja je od vitalnog značaja za web servere sa visokim prometom ili cloud instance sa niskom latencijom.

Za memoriju, vrijednosti poput vm.swappiness, vm.dirty_ratio, vm.vfs_cache_pressure i vm.overcommit_memory vam omogućavaju da kontrolišete koliko se swap-a koristi, kako se upravlja keš memorijom stranica i ponašanje virtuelne memorije. Smanjenje swap-a (na primjer, na 10) obično pomaže u sprečavanju sistema da prečesto koristi swap, smanjujući skokove latencije zbog I/O operacija diska.

Ako radite s velikim bazama podataka ili aplikacijama koje koriste ogromne količine dijeljene memorije, ključno je prilagoditi kernel.shmmax, kernel.shmall i maksimalni broj otvorenih datoteka pomoću fs.file-max i fs.nr_open . Nepravilno dimenzionirana ograničenja mogu uzrokovati uska grla i greške koje je teško dijagnosticirati pod opterećenjem.

Preporučuje se napraviti male promjene, izmjeriti njihov utjecaj alatima za praćenje i tek onda ih pohraniti u /etc/sysctl.conf ili /etc/sysctl.d/ . U kontejneriziranim okruženjima, imajte na umu da su mnogi parametri kernela globalni za hosta: nepažljive modifikacije mogu utjecati na sve servise, tako da je kombiniranje sysctl-a s cgrupama i imenskim prostorima gotovo obavezno.

Kompajliranje i održavanje prilagođenih kernela

Kompajliranje prilagođenog kernela ostaje moćan alat kada želite smanjiti latenciju, ukloniti nepotrebno opterećenje ili podržati neobičan hardver . Iako distribucije uključuju prilično svestrane kernele, u određenim scenarijima određeni kernel čini svu razliku.

Klasični tijek rada uključuje preuzimanje koda sa kernel.org ili zakrpljena stabla poput xanmod ili liquorixi koristite alate poput make menuconfig za odabir opcija. Spremanje .config datoteke u vaš vlastiti git repozitorij, zajedno sa skriptama za izgradnju, omogućava vam reprodukciju verzija i održavanje konzistentnosti između verzija.

Ako koristite Debian ili njegovu derivativnu verziju, vrlo je praktično kompajlirati " na Debian način " kako biste dobili .deb pakete kernela, zaglavlja i pridruženih biblioteka. Ovo vam omogućava da implementirate taj prilagođeni kernel na više mašina jednostavnim instaliranjem paketa i upravljanjem verzijama pomoću vlastitog repozitorija.

U stvarnom svijetu, ručno kompajliranje često ima smisla kada se radi sa starim ili vrlo ograničenim hardverom . Tipičan primjer je stari netbook sa Atom CPU-om i 1 GB RAM-a, gdje moderni generički kernel, pun nepotrebnih drajvera i opcija serverskog nivoa, uvodi latenciju i dodatno opterećenje CPU-a koje si ne možete priuštiti.

Uobičajena strategija je započeti s trenutnom konfiguracijom kernela (na primjer, kopiranjem konfiguracijske datoteke iz /boot ), a zatim je prilagoditi ili prilagoditi. Možete promijeniti model preempcije na " Preemptible Kernel (Low-Latency Desktop) " kako biste dali prioritet interaktivnom odgovoru radne površine ili dodati specifične I/O planere poput BFQ-a kao modul za poboljšanje iskustva na mehaničkim diskovima.

Da biste izbjegli dugotrajno kompajliranje, ima smisla graditi na snažnijoj mašini i, ako je potrebno, koristiti unakrsno kompajliranje (na primjer, kompajliranje 32-bitnog kernela za Atom sa x86_64 računara jednostavnim podešavanjem ARCH-a i odgovarajućih alata). Zatim samo trebate instalirati .deb datoteke na ciljnu mašinu i dodati odgovarajući unos u GRUB.

Najteži dio je održavanje: preporučljivo je testirati novi kernel na čvorovima na Kanarskim ostrvima , imati jasne putanje za vraćanje na prethodno stanje u boot manageru i snimati logove i metrike tokom tranzicije kako bi se otkrile regresije u performansama ili kompatibilnosti drajvera.

Modeli preempcije i PREEMPT_RT zakrpe za sisteme sa niskom latencijom

Model preempcije kernela određuje koliko se izvršavajući zadatak može prekinuti kako bi zadatak višeg prioriteta mogao preuzeti kontrolu, što direktno utiče na latenciju odgovora . To uključuje i standardne opcije konfiguracije i zakrpe u realnom vremenu.

Generički kerneli nude nekoliko opcija: bez preempcije (više fokusirani na propusnost servera), dobrovoljnu preempciju i preemptabilnu kernel za desktop računare , koji daje prioritet brzom vremenu odziva za interaktivne aplikacije. Podešavanje ove postavke može značajno poboljšati performanse desktop sistema, audio aplikacija ili čak starijih, jako opterećenih mašina.

Kada je potrebno ići korak dalje, pojavljuju se PREEMPT i PREEMPT_RT zakrpe koje modificiraju važne dijelove kernela kako bi se minimizirali dijelovi koji se ne mogu preemptiti. PREEMPT_RT je namijenjen sistemima gdje latencija u najgorem slučaju (ne samo prosjek) mora biti vrlo niska i predvidljiva: industrijska automatizacija, profesionalni audio, telekomunikacije ili visokofrekventna trgovina.

Odluka o uvođenju PREEMPT_RT ne bi trebala biti zasnovana na trendovima, već na konkretnim mjerenjima latencije i jittera . Prvo, preporučljivo je u potpunosti istražiti postavke raspoređivača, afinitete CPU-a, sysctl i, ako je primjenjivo, konfiguracije poput dinamičkog bezticklessa prije nego što se održavanje zakomplicira RT stablom.

Kompatibilnost se također mora uzeti u obzir: neki drajveri i podsistemi nisu u potpunosti prilagođeni RT-u i mogu zahtijevati specifične verzije ili dodatne zakrpe. Razuman pristup je pripremiti plan održavanja koji jasno navodi kada i kako integrirati nove verzije glavnog kernela sa RT granom, koja se periodično sinhronizuje, ali i dalje donekle zaostaje.

Podešavanje rasporeda CPU-a, rad bez otkucavanja i izolacija jezgra

Pored odabira modela preempcije, možete fino podesiti latenciju igranjem s raspoređivanjem CPU-a i ponašanjem kernel tajmera, posebno u distribucijama orijentiranim na preduzeća poput RHEL-a.

Na primjer, Red Hat Enterprise Linux 8 dolazi s podrazumijevanim kernelom bez otkucavanja za neaktivne CPU-e , što smanjuje potrošnju energije izbjegavanjem periodičnih prekida kada je kernel neaktivan. Za opterećenja osjetljiva na latenciju, dinamički način rada bez otkucavanja može se omogućiti na skupu kernela , tako da samo jedan CPU ("kućni kernel") obrađuje većinu zadataka mjerenja vremena, a ostali su što je moguće oslobođeni periodičnih prekida.

Ova konfiguracija se vrši dodavanjem odgovarajućih parametara u komandna linija kernela u GRUB-uregeneriranje konfiguracije, a zatim podešavanje afiniteta kritičnih niti jezgra, kao što su RCU niti ili niti bdi-flush, tako da se nalaze u jezgru rezerviranom za održavanje.

Ovaj pristup se može dopuniti parametrom `isolcpus` , koji omogućava izolaciju jezgara od normalnih zadataka u korisničkom prostoru. Vrlo je uobičajeno u scenarijima niske latencije rezervirati nekoliko jezgara isključivo za kritičnu aplikaciju, dok ostatak sistema (demoni, prekidi itd.) obrađuju druge jezgre.

Da biste provjerili da li dinamički način rada bez otkucavanja funkcionira, mogu se pokrenuti jednostavni testovi pomoću stress ili skripte koje zaokupljaju CPU na sekundu i posmatraju brojači otkucaja tajmera Kako broj prekida u sekundi pada sa hiljada na samo jedan u izolovanim jezgrima, znak da je periodični tajmer nestao.

Upravljanje memorijom i pohranom podataka s fokusom na latenciju

Način na koji kernel upravlja memorijom i I/O operacijama na disku ima ogroman utjecaj na latenciju koju aplikacije percipiraju , posebno u bazama podataka i servisima koji obavljaju mnogo malih, čestih operacija.

Što se tiče memorije, smanjenje vm.swappiness minimizira korištenje swapa (koji je gotovo uvijek mnogo sporiji od RAM-a), vm.vfs_cache_pressure kontrolira koliko brzo sistem treba osloboditi inode i dentry keš, a vm.nr_hugepages vam omogućava da rezervirate statičke HugePages za velika opterećenja poput baza podataka ili JVM-ova, smanjujući TLB opterećenje.

U skladištu odaberite odgovarajući I/O planer prema tipu diska To je kritično. Na modernim SSD diskovima, obično je dobra ideja koristiti... none o mq-deadlineDok kod mehaničkih diskova i multitasking sistema, algoritmi dizajnirani za pravednost mogu biti bolji, kao što je BfqPored toga, montiranje datotečnih sistema sa opcijama kao što su noatime y nodiratime Izbjegavajte nepotrebna pisanja svaki put kada se pristupa datoteci ili direktoriju.

Što se tiče datotečnih sistema, ext4 i XFS ostaju najčešći izbori: dobro podešen ext4 je sigurna opcija, dok XFS ima tendenciju da se bolje skalira pod visokom konkurentnošću. Za vrlo zahtjevne scenarije, kombinovanje RAID-a (RAID 10 za baze podataka, RAID 0 za privremeno skladištenje) sa dobrim planerom može smanjiti prosječnu latenciju i, prije svega, varijabilnost.

Optimizacija mreže i kernela za nisku latenciju u Linuxu i EC2

U visokoperformansnim mrežnim aplikacijama, latencija ne zavisi samo od hardvera ili udaljenosti, već i od toga kako su konfigurisani TCP/IP stek i sama jezgra . Ovo je posebno primjetno u cloud instancama poput Amazon EC2 sa ENA interfejsima.

Za početak, ključno je smanjiti vanjske faktore poput broja mrežnih skokova koje paketi prave: korištenje direktnijih topologija, uravnoteživača opterećenja blizu pozadine ili optimiziranih zona dostupnosti smanjuje vrijeme putovanja u milisekundama prije nego što uopće dotaknu operativni sistem.

Unutar kernela, konfiguracija mreže uključuje povećanje deskriptora datoteka (ulimit -n) , određivanje veličine prijemnih i slanih bafera sa net.core.rmem_max, net.core.wmem_max, net.ipv4.tcp_rmem, net.ipv4.tcp_wmem i omogućavanje opcija kao što je TCP Fast Open za smanjenje latencije uspostavljanja veze.

U AWS ENA interfejsima, moderiranje prekida igra važnu ulogu: prema zadanim postavkama, drajver grupira pakete kako bi smanjio broj IRQ-ova. rx-usecs i tx-usecsAko želite smanjiti latenciju na apsolutni minimum, možete onemogućiti ovu moderaciju tako što ćete ethtool -CPostavljanje rx-usecs i tx-usecs na nulu smanjuje latenciju, ali povećava opterećenje prekidima, tako da se mora pronaći ravnoteža ovisno o opterećenju.

Također možete koristiti irqbalance za distribuciju IRQ-ova na više jezgara ili ga onemogućiti i ručno postaviti afinitete prekida i mrežnog reda čekanja (RSS/RPS) za određene jezgre, što je vrlo uobičajeno u okruženjima s ultra-niskom latencijom ili kada se koristi DPDK i preskače veliki dio kernel steka.

Još jedan parametar koji treba uzeti u obzir su C-stanja CPU-a : stanja dubokog sna smanjuju potrošnju energije, ali uvode kašnjenja kada se jezgro "probudi". Da biste smanjili latenciju odgovora, možete ograničiti ova duboka stanja, prihvatajući veću potrošnju energije i manje prostora za Turbo Boost na drugim jezgrama. Svako okruženje ima svoju idealnu ravnotežu između potrošenih vati i dobijenih mikrosekundi.

Optimizacija CPU-a, usluga i aplikacija radi smanjenja latencije

Pored samog kernela, okolno okruženje ima mnogo toga za reći o ukupnoj latenciji: od servisa aktivnih na sistemu do specifične konfiguracije svake aplikacije.

Visokoperformansni server bi trebao pokretati samo demoni koji su zaista neophodniServisi poput Bluetootha, štampanja ili automatskog otkrivanja mreže (CUPS, Avahi, itd.) na backend mašinama samo troše CPU, memoriju i I/O bez pružanja ikakve koristi. Pregledajte sa systemctl list-unit-files --state=enabled A onemogućavanje nepotrebnih stvari je jedna od najjeftinijih i najefikasnijih stvari koje možete učiniti.

Za određivanje prioriteta kritičnih procesa možete koristiti alate poput renice, chrt i taskset . Podešavanje prioriteta procesa (renice), dodjeljivanje rasporeda u realnom vremenu (chrt -f 99) ili dodjeljivanje određenim jezgrama (taskset) smanjuje interferenciju s drugim zadacima, poboljšavajući predvidljivost CPU-a za baze podataka, VoIP, streaming ili trgovačke usluge.

Na nivou aplikacije, podešavanje je jednako važno kao i podešavanje kernela. Web serveri poput Nginxa ili Apachea trebaju fino podešavanje workera, keepalive-a, keepa i kompresije. Baze podataka poput PostgreSQL-a ili MySQL-a zahtijevaju pregled veličina bafera, kontrolnih tačaka, skupova veza i parametara sinhronog pisanja kako bi se postigla niska i stabilna latencija.

JVM također igra ulogu: odabir sakupljača smeća poput G1GC ili ZGC i podešavanje veličine heap-a može smanjiti pauze koje se izvana pojavljuju kao latencija. U virtualiziranim i kontejneriziranim okruženjima, pravilna alokacija vCPU, vRAM i I/O kvota sprječava tiho natjecanje, koje se kasnije manifestira kao beskrajni redovi čekanja na disku ili preopterećenje CPU-a.

Praćenje i testiranje kernela i sistema

Svo ovo podešavanje je beskorisno ako ne mjerite utjecaj. Ključno je kombinirati kontinuirano praćenje s reproducibilnim testovima performansi , tako da se svaka promjena u kernelu ili sysctl-u može procijeniti objektivnim podacima.

Da biste vidjeli cjelokupni status sistema, možete koristiti klasične alate kao što su htop, vmstat, iotop o sarKada vam je potrebno više detalja, na scenu dolaze specifični alati kernela, kao što su perf i ftracekoji vam omogućavaju praćenje ponašanja planera, prekida i internih poziva sa značajnom tačnošću.

U produkcijskim okruženjima, preporučljivo je implementirati sisteme metrike poput Prometheusa, collectd-a ili sysstat-a s izvoznicima koji otkrivaju brojače CPU-a, I/O, latencije diska i mreže, redove čekanja procesa i tako dalje. Vizualizacija ovih podataka u Grafani ili sličnim alatima pomaže u otkrivanju regresija ili anomalija prije nego što krajnji korisnik primijeti probleme.

Za benchmarking, ideja je replicirati stvarno opterećenje i uporediti "prije i poslije" svake promjene. Alati poput sysbench (za CPU i baze podataka), fio (za disk) ili iperf3 (za mrežu) omogućavaju vam da kreirate scenarije koji se mogu ponavljati. Bitno je dokumentirati verzije kernela, sysctl konfiguracije, hardver i parametre testiranja kako bi poređenja bila smislena tokom vremena.

U praksi, optimizacija Linux kernela je iterativni proces: testirate niz podešavanja, mjerite rezultate, zadržavate ono što pruža stvarnu korist, a ostalo odbacujete. Uz dobro upravljanje promjenama, možete prevesti poboljšanja u novim verzijama kernela (kao što su nedavne serije sa poboljšanjima raspoređivača, grafike, napajanja ili umrežavanja) u mjerljive koristi za vaše aplikacije, bilo da se radi o lokalnim serverima, u oblaku ili na zahtjevnim radnim stanicama.

Kombinacija poznavanja arhitekture kernela, finog podešavanja pomoću sysctl-a, kontrolirane kompajlacije, selektivne upotrebe zakrpa u realnom vremenu i dobrog sistema metrika omogućava administratoru ili operativnom timu da postigne brže odgovore, niže latencije i bolju ukupnu stabilnost bez potrebe za promjenom hardvera pri najmanjoj provokaciji ili ugrožavanja sigurnosti sistema.