- Akordimi i kernelit Linux kërkon kombinimin e konfigurimit arkitektonik, sysctl dhe planifikimit të CPU-së të orientuar drejt vonesës.
- Bërthamat e personalizuara dhe patch-et PREEMPT_RT lejojnë ulje ekstreme të latencës, por ato kërkojnë më shumë kompleksitet dhe mirëmbajtje.
- Optimizimi i rrjetit, memories, diskut dhe shërbimeve të sistemit duhet të matet gjithmonë me monitorim dhe krahasim të rreptë.
- Një qasje iterative, e bazuar në metrika, i shndërron përmirësimet e bërthamës në përfitime reale për aplikacionet dhe përdoruesit.
Kur flasim për performancën në Linux, pothuajse gjithçka përfundon duke treguar të njëjtën gjë: bërthamën si komponentin qendror që kontrollon vonesën, stabilitetin dhe përdorimin e burimeve . Rregullimi i imët i saj mund të bëjë ndryshimin midis një sistemi që thjesht "ia del mbanë" dhe një sistemi që përgjigjet pa probleme në servera, desktopë, mjedise cloud, apo edhe në harduer shumë të vjetër.
Ky udhëzues përqendrohet në mënyrën e optimizimit të kernelit Linux për të minimizuar vonesën pa kompromentuar sigurinë ose mirëmbajtjen . Ne do të mbulojmë gjithçka, nga konceptet themelore arkitekturore deri te ndryshimet me sysctl, përpilimin e kernelave të personalizuara, përdorimin e patch-eve në kohë reale, akordimin për rrjetet me vonesë të ulët (siç është EC2) dhe teknikat e monitorimit dhe krahasimit për të matur nëse ndryshimet tuaja përmirësojnë vërtet performancën.
Arkitektura e kernelit Linux dhe pikat kryesore për vonesën
Bërthama e Linux-it vepron si një shtresë ndërmjetëse midis aplikacioneve dhe pajisjeve, duke menaxhuar memorien, proceset, ndërprerjet, drajverët dhe sistemet e skedarëve . Dizajni i saj monolit, por edhe modular , falë moduleve të ngarkueshme, lejon që funksionalitetet të aktivizohen ose çaktivizohen në mënyrë fleksibile pa e rikompiluar të gjithë sistemin.
Për të kuptuar burimin e latencës, është thelbësore të kuptohen disa nënsisteme: planifikuesi i proceseve , menaxhimi i memories dhe trajtimi i ndërprerjeve. Një planifikues i konfiguruar keq, një politikë agresive e memories ose një numër i tepërt ndërprerjesh të pakontrolluara mund të rezultojnë në kohë të ngadalta reagimi, madje edhe me harduer të fuqishëm.
Opsionet e konfigurimit të bërthamës si CONFIG_PREEMPT, CONFIG_PREEMPT_VOLUNTARY dhe CONFIG_SMP hyjnë në lojë . Këto përcaktojnë masën në të cilën bërthama mund të parapërgatitet për t'u marrë me detyra më urgjente dhe si i trajton sistemet me shumë bërthama. Zgjedhja e modelit të duhur të parapërgatitjes ndryshon ndjeshëm vonesën e perceptuar në desktopë, serverë me vonesë të ulët ose sisteme industriale.
Në serverat modernë, topologjia e harduerit ka rëndësi gjithashtu: shpërndarja e bërthamës, soketat, NUMA dhe hierarkia e memorjes cache . Rregullimi i imët i afiniteteve të CPU-së dhe politikave NUMA (për shembull, caktimi i proceseve dhe memories në të njëjtën nyje) ndihmon në zvogëlimin e kohës së aksesit dhe përmirësimin e shkallës së goditjes së memorjes cache, e cila është thelbësore kur minimizohet luhatja dhe vonesat e paparashikueshme.
Për më tepër, bashkëveprimi midis planifikuesit të CPU-së dhe nënsistemeve I/O (disk dhe rrjet) përcakton rendimentin dhe vonesën nga fillimi në fund që përjetojnë aplikacionet. Para se të bëni ndonjë ndryshim, këshillohet të dokumentoni gjendjen aktuale (konfigurimi i bërthamës, sysctl, GRUB, modulet e ngarkuara) për të lejuar një rikthim të shpejtë nëse një ndryshim përkeqëson performancën.
Rregullime nëpërmjet sysctl për të përmirësuar vonesën dhe performancën
Ndërfaqja sysctl ju lejon të modifikoni parametrat e kernelit menjëherë nëpërmjet /proc/sys, pa pasur nevojë të rikompiloni. Është pika ideale e hyrjes për akordim pa u zhytur në kompilime.
Në mjedisin e rrjetit, parametra të tillë si net.core.rmem_max, net.core.wmem_max dhe net.ipv4.tcp_congestion_control ndikojnë drejtpërdrejt në rendimentin, vonesën dhe sjelljen e lidhjes TCP. Rregullimi i duhur i memorjeve të përkohshme dhe algoritmit të mbingarkesës është jetik për serverët web me trafik të lartë ose instancat cloud me vonesë të ulët.
Për memorien, vlera si vm.swappiness, vm.dirty_ratio, vm.vfs_cache_pressure dhe vm.overcommit_memory ju lejojnë të kontrolloni se sa swap përdoret, si menaxhohet memoria e faqes dhe sjelljen e memories virtuale. Ulja e swappiness (për shembull, në 10) zakonisht ndihmon në parandalimin e përdorimit shumë të shpeshtë të swap nga sistemi, duke zvogëluar rritjet e vonesës për shkak të hyrjeve/daljeve në disk.
Nëse punoni me baza të dhënash ose aplikacione të mëdha që përdorin sasi të mëdha memorieje të përbashkët, është shumë e rëndësishme të rregulloni kernel.shmmax, kernel.shmall dhe numrin maksimal të skedarëve të hapur duke përdorur fs.file-max dhe fs.nr_open . Limitet me madhësi të papërshtatshme mund të shkaktojnë bllokime dhe gabime që janë të vështira për t'u diagnostikuar nën ngarkesë.
Rekomandohet të bëni ndryshime të vogla, të matni ndikimin e tyre me mjete monitorimi dhe vetëm pastaj t'i vendosni ato në /etc/sysctl.conf ose /etc/sysctl.d/ . Në mjedise të kontejnerizuara, mbani mend se shumë parametra të kernelit janë globalë për hostin: modifikimet e pakujdesshme mund të ndikojnë në të gjitha shërbimet, kështu që kombinimi i sysctl me cgroups dhe namespaces është pothuajse i detyrueshëm.
Kompilimi dhe mirëmbajtja e kernelave të personalizuara
Kompilimi i një kerneli të personalizuar mbetet një mjet i fuqishëm kur doni të zvogëloni vonesën, të hiqni mbingarkesën e panevojshme ose të mbështesni harduerin e pazakontë . Edhe pse shpërndarjet përfshijnë kernele mjaft të gjithanshme, në skenarë të caktuar një kernel specifik bën gjithë ndryshimin.
Fluksi klasik i punës përfshin shkarkimin e kodit nga kernel.org ose pemë të patchuara si xanmod ose liquorixdhe përdorni mjete si make menuconfig për të zgjedhur opsionet. Ruajtja e skedarit .config në deponë tuaj git, së bashku me skriptet e ndërtimit, ju lejon të riprodhoni ndërtimet dhe të ruani qëndrueshmërinë midis versioneve.
Nëse përdorni Debian ose një version derivativ, është shumë e përshtatshme të kompiloni " në mënyrën Debian " për të marrë paketa .deb të kernelit, kokat dhe libraritë e lidhura me të. Kjo ju lejon të vendosni atë kernel të personalizuar në makina të shumta thjesht duke instaluar paketat dhe duke menaxhuar versionet me depon tuaj.
Në botën reale, përpilimi manual shpesh ka kuptim kur punohet me harduer të vjetër ose shumë të kufizuar . Një shembull tipik është një netbook i vjetër me një CPU Atom dhe 1 GB RAM, ku një kernel modern gjenerik, plot me drajverë të panevojshëm dhe opsione të nivelit të serverit, sjell vonesë dhe përdorim shtesë të CPU-së që nuk mund ta përballoni.
Një strategji e zakonshme është të fillosh me konfigurimin aktual të kernelit (për shembull, duke kopjuar skedarin e konfigurimit nga /boot ) dhe pastaj ta shkurtosh ose ta rregullosh atë. Mund ta ndryshosh modelin e parapërgatitjes në " Kërnel i Parapërgatitshëm (Desktop me Latenci të Ulët) " për të përcaktuar përparësitë e përgjigjes interaktive të desktopit, ose për të shtuar planifikues specifikë I/O si BFQ si modul për të përmirësuar përvojën në disqet mekanike.
Për të shmangur shpenzimin e shumë kohëve duke kompiluar, ka kuptim të ndërtoni mbi një makinë më të fuqishme dhe, nëse është e nevojshme, të përdorni kompilimin e kryqëzuar (për shembull, kompilimi i një kerneli 32-bit për një Atom nga një PC x86_64 thjesht duke rregulluar ARCH dhe zinxhirët përkatës të mjeteve). Pastaj thjesht duhet të instaloni skedarët .deb në makinën e synuar dhe të shtoni hyrjen e duhur në GRUB.
Pjesa më e vështirë është mirëmbajtja: këshillohet të testohet kerneli i ri në nyjet e Ishujve Kanarie , të ketë shtigje të qarta për rikthim në menaxherin e nisjes dhe të regjistrohen regjistrat dhe metrikat gjatë tranzicionit për të zbuluar regresionet në performancë ose përputhshmërinë e drajverëve.
Modelet e parandalimit dhe patch-et PREEMPT_RT për sistemet me vonesë të ulët
Modeli i parandalimit të bërthamës përcakton se sa mund të ndërpritet një detyrë në ekzekutim për të lejuar që një detyrë me përparësi më të lartë të marrë përsipër, duke ndikuar drejtpërdrejt në vonesën e përgjigjes . Kjo përfshin si opsionet standarde të konfigurimit ashtu edhe patch-et në kohë reale.
Bërthamat gjenerike ofrojnë disa mundësi: pa përparësi (më të fokusuara në rendimentin e serverit), përparësi vullnetare dhe një bërthamë të përparësishme për desktopët , e cila i jep përparësi kohës së shpejtë të reagimit për aplikacionet interaktive. Rregullimi i këtij cilësimi mund të përmirësojë ndjeshëm performancën e sistemeve desktop, aplikacioneve audio ose edhe makinave më të vjetra dhe me ngarkesë të lartë.
Kur duhet të shkoni një hap më tej, shfaqen patch-et PREEMPT dhe PREEMPT_RT , të cilat modifikojnë pjesë të rëndësishme të bërthamës për të minimizuar seksionet që nuk mund të parapërgatiten. PREEMPT_RT është menduar për sisteme ku vonesa në rastin më të keq (jo vetëm mesatarja) duhet të jetë shumë e ulët dhe e parashikueshme: automatizimi industrial, audio profesional, telekomunikacioni ose tregtia me frekuencë të lartë.
Vendimi për të futur PREEMPT_RT nuk duhet të bazohet në trende, por në matje konkrete të latencës dhe luhatjes . Së pari, këshillohet të eksplorohen plotësisht cilësimet e planifikuesit, afinitetet me CPU-në, sysctl dhe, nëse është e aplikueshme, konfigurimet si pa tik-tak dinamik përpara se të ndërlikohet mirëmbajtja me një pemë RT.
Duhet të merret në konsideratë edhe përputhshmëria: disa drajverë dhe nënsisteme nuk janë përshtatur plotësisht me RT dhe mund të kërkojnë versione specifike ose patch-e shtesë. Qasja më e arsyeshme është përgatitja e një plani mirëmbajtjeje që përshkruan qartë se kur dhe si të integrohen versionet e reja të kernelit kryesor me degën RT, e cila sinkronizohet periodikisht, por prapë mbetet disi prapa.
Akordimi i planifikimit të CPU-së, funksionimi pa ndërprerje dhe izolimi i bërthamës
Përveç zgjedhjes së modelit të parandalimit, mund të rregulloni hollësisht vonesën duke luajtur me planifikimin e CPU-së dhe sjelljen e kohëmatësit të bërthamës, veçanërisht në shpërndarjet e orientuara drejt ndërmarrjeve si RHEL.
Red Hat Enterprise Linux 8, për shembull, vjen me një kernel të parazgjedhur pa ndërprerje për CPU-të joaktive , i cili zvogëlon konsumin e energjisë duke shmangur ndërprerjet periodike kur kerneli është joaktiv. Për ngarkesat e punës të ndjeshme ndaj vonesës, një modalitet dinamik pa ndërprerje mund të aktivizohet në një grup kernelësh , në mënyrë që vetëm një CPU ("kerneli kryesor") të trajtojë shumicën e detyrave të kohëzimit, dhe pjesa tjetër të jetë sa më e lirë të jetë e mundur nga ndërprerjet periodike.
Ky konfigurim bëhet duke shtuar parametrat e duhur në rreshti i komandës së kernelit në GRUBrigjenerimi i konfigurimit, dhe më pas rregullimi i afinitetit të fijeve kritike të kernelit, siç janë fijet ose fijet RCU bdi-flush, në mënyrë që ato të qëndrojnë në bërthamën e rezervuar për mirëmbajtje.
Kjo qasje mund të plotësohet me parametrin `isolcpus` , i cili lejon që bërthamat të izolohen nga detyrat normale të hapësirës së përdoruesit. Është shumë e zakonshme në skenarët me vonesë të ulët të rezervohen disa bërthama ekskluzivisht për një aplikacion kritik, ndërsa pjesa tjetër e sistemit (daemonët, ndërprerjet, etj.) trajtohet nga bërthama të tjera.
Për të verifikuar që modaliteti dinamik pa tik-tak po funksionon, mund të kryhen teste të thjeshta me stress ose skripte që e mbajnë CPU-në të zënë për një sekondë dhe vëzhgojnë me numëruesit e tik-takëve të kohëmatësit Se si numri i ndërprerjeve për sekondë bie nga mijëra në vetëm një në bërthamat e izoluara, një shenjë se kohëmatësi periodik është zhdukur.
Menaxhimi i kujtesës dhe ruajtjes me fokus në vonesën
Mënyra se si kerneli menaxhon memorien dhe hyrjet/daljet në disk ka një ndikim të madh në vonesën e perceptuar nga aplikacionet , veçanërisht në bazat e të dhënave dhe shërbimet që kryejnë shumë operacione të vogla dhe të shpeshta.
Nga ana e memories, zvogëlimi i vm.swappiness minimizon përdorimin e swap-it (i cili është pothuajse gjithmonë shumë më i ngadaltë se RAM-i), vm.vfs_cache_pressure kontrollon se sa shpejt duhet që sistemi të lirojë memorjen cache inode dhe dentry, dhe vm.nr_hugepages ju lejon të rezervoni HugePages statike për ngarkesa të rënda si bazat e të dhënave ose JVM-të, duke zvogëluar mbingarkesën e TLB-së.
Në magazinim, zgjidhni planifikues i përshtatshëm I/O sipas llojit të diskut Është kritike. Në SSD-të moderne, zakonisht është një ide e mirë të përdoret... none o mq-deadlineNdërsa në disqet mekanike dhe sistemet shumëdetyrëshe, algoritmet e projektuara për drejtësi mund të jenë më të mira, si p.sh. BfqPër më tepër, montimi i sistemeve të skedarëve me opsione të tilla si noatime y nodiratime Shmangni shkrimet e panevojshme sa herë që aksesohet një skedar ose direktori.
Lidhur me sistemet e skedarëve, ext4 dhe XFS mbeten zgjedhjet më të zakonshme: një ext4 i akorduar mirë është një bast i sigurt, ndërsa XFS tenton të shkallëzohet më mirë në kushte të njëkohshmërisë së lartë. Për skenarë shumë të kërkuar, kombinimi i RAID (RAID 10 për bazat e të dhënave, RAID 0 për ruajtje të përkohshme fillestare) me një planifikues të mirë mund të zvogëlojë vonesën mesatare dhe, mbi të gjitha, ndryshueshmërinë.
Optimizimi i rrjetit dhe bërthamës për vonesë të ulët në Linux dhe EC2
Në aplikacionet e rrjetëzimit me performancë të lartë, vonesa varet jo vetëm nga hardueri ose distanca, por edhe nga mënyra se si konfigurohen pirgu TCP/IP dhe vetë bërthama . Kjo është veçanërisht e dukshme në instancat e cloud-it si Amazon EC2 me ndërfaqe ENA.
Për të filluar, është thelbësore të zvogëlohen faktorët e jashtëm, siç është numri i kërcimeve në rrjet që bëjnë paketat: përdorimi i topologjive më të drejtpërdrejta, balancuesve të ngarkesës afër backend-it ose zonave të disponueshmërisë së optimizuar zvogëlon kohën e udhëtimit në milisekonda para se të preket sistemi operativ.
Brenda kernelit, konfigurimi i rrjetit përfshin rritjen e përshkruesve të skedarëve (ulimit -n) , ndryshimin e madhësisë së buffer-ave të marrjes dhe dërgimit me net.core.rmem_max, net.core.wmem_max, net.ipv4.tcp_rmem, net.ipv4.tcp_wmem , dhe aktivizimin e opsioneve të tilla si TCP Fast Open për të zvogëluar vonesën e krijimit të lidhjes.
Në ndërfaqet AWS ENA, moderimi i ndërprerjeve luan një rol të rëndësishëm: si parazgjedhje, drajveri grupon paketat për të zvogëluar numrin e IRQ-ve. rx-usecs dhe tx-usecsNëse doni ta zvogëloni vonesën në minimumin absolut, mund ta çaktivizoni këtë moderim duke ethtool -CVendosja e rx-usecs dhe tx-usecs në zero ul latencën, por rrit mbingarkesën e ndërprerjeve, kështu që duhet të gjendet një ekuilibër në varësi të ngarkesës.
Gjithashtu mund të përdorni irqbalance për të shpërndarë IRQ-të nëpër bërthama të shumta , ose ta çaktivizoni atë dhe të vendosni manualisht afinitetet e ndërprerjeve dhe radhës së rrjetit (RSS/RPS) për bërthama specifike, gjë që është shumë e zakonshme në mjedise me latencë ultra të ulët ose kur përdorni DPDK dhe anashkaloni një pjesë të madhe të pirgut të kernelit.
Një tjetër parametër që duhet marrë në konsideratë janë gjendjet C të CPU-së : gjendjet e gjumit të thellë zvogëlojnë konsumin e energjisë, por sjellin vonesa kur bërthama "zgjohet". Për të zvogëluar vonesën e reagimit, mund t'i kufizoni këto gjendje të thella, duke pranuar konsum më të lartë të energjisë dhe më pak hapësirë për Turbo Boost në bërthamat e tjera. Çdo mjedis ka pikën e vet të përsosur midis vatëve të konsumuar dhe mikrosekondave të fituara.
Optimizimi i CPU-së, shërbimit dhe aplikacionit për të zvogëluar vonesën
Përveç vetë bërthamës, mjedisi përreth ka shumë për të thënë në lidhje me vonesën e përgjithshme: nga shërbimet aktive në sistem deri te konfigurimi specifik i secilit aplikacion.
Një server me performancë të lartë duhet të ekzekutojë vetëm demonë që janë vërtet të nevojshëmShërbime si Bluetooth, printimi ose zbulimi automatik i rrjetit (CUPS, Avahi, etj.) në makinat backend konsumojnë vetëm CPU, memorie dhe I/O pa ofruar ndonjë përfitim. Rishikoni me systemctl list-unit-files --state=enabled Dhe çaktivizimi i gjërave të panevojshme është një nga gjërat më të lira dhe më efektive që mund të bëni.
Për të përcaktuar përparësitë e proceseve kritike, mund të përdorni mjete si renice, chrt dhe taskset . Rregullimi i përparësisë së një procesi (renice), caktimi i tij në kohë reale (chrt -f 99) ose caktimi i tij në bërthama specifike (taskset) zvogëlon ndërhyrjen me detyra të tjera, duke përmirësuar parashikueshmërinë e CPU-së për bazat e të dhënave, VoIP, transmetimin ose shërbimet e tregtimit.
Në nivelin e aplikacionit, akordimi është po aq i rëndësishëm sa akordimi i bërthamës. Serverët web si Nginx ose Apache kanë nevojë për akordim të imët të punëtorëve, keepalive, memorjeve të përkohshme dhe kompresimit. Bazat e të dhënave si PostgreSQL ose MySQL kërkojnë rishikimin e madhësive të buffer-ave, pikave të kontrollit, grupeve të lidhjeve dhe parametrave të shkrimit sinkron për të arritur vonesë të ulët dhe të qëndrueshme.
JVM gjithashtu luan një rol: zgjedhja e mbledhësve të mbeturinave si G1GC ose ZGC dhe rregullimi i madhësive të heap-eve mund të zvogëlojë pauzat që, nga jashtë, shfaqen si latencë. Në mjedise të virtualizuara dhe të kontejnerizuara, ndarja e duhur e kuotave vCPU, vRAM dhe I/O parandalon grindjen e heshtur, e cila më vonë manifestohet si radhë të pafundme disku ose mbingarkesë e CPU-së.
Monitorimi dhe krahasimi i bërthamës dhe sistemit
I gjithë ky rregullim është i padobishëm nëse nuk e matni ndikimin. Çelësi është të kombinoni monitorimin e vazhdueshëm me teste të riprodhueshme të performancës , në mënyrë që çdo ndryshim në kernel ose sysctl të mund të vlerësohet me të dhëna objektive.
Për të parë gjendjen e përgjithshme të sistemit, mund të përdorni mjete klasike si p.sh. htop, vmstat, iotop o sarKur keni nevojë për më shumë detaje, hyjnë në lojë mjete specifike të kernelit, si p.sh. perf dhe ftracetë cilat ju lejojnë të gjurmoni sjelljen e planifikuesit, ndërprerjet dhe thirrjet e brendshme me saktësi të konsiderueshme.
Në mjediset e prodhimit, këshillohet të vendosen sisteme metrike si Prometheus, collectd ose sysstat me eksportues që ekspozojnë numëruesit e CPU-së, I/O, vonesat e diskut dhe rrjetit, radhët e proceseve e kështu me radhë. Vizualizimi i këtyre të dhënave në Grafana ose mjete të ngjashme ndihmon në zbulimin e regresioneve ose anomalive përpara se përdoruesi përfundimtar të vërejë probleme.
Për krahasimin, ideja është të replikohet ngarkesa aktuale e punës dhe të krahasohet "para dhe pas" e çdo ndryshimi. Mjete si sysbench (për CPU dhe bazat e të dhënave), fio (për diskun) ose iperf3 (për rrjetin) ju lejojnë të ndërtoni skenarë të përsëritshëm. Është thelbësore të dokumentoni versionet e kernelit, konfigurimet sysctl, harduerin dhe parametrat e testimit në mënyrë që krahasimet të jenë kuptimplote me kalimin e kohës.
Në praktikë, optimizimi i bërthamës Linux është një proces përsëritës: ju testoni një sërë ndryshimesh, matni rezultatet, mbani atë që ofron përfitim të vërtetë dhe hidhni poshtë pjesën tjetër. Me një qeverisje të mirë të ndryshimeve, ju mund t'i përktheni përmirësimet në versionet e reja të bërthamës (siç janë seritë e fundit me përmirësime të planifikuesit, grafikës, fuqisë ose rrjetit) në përfitime të matshme për aplikacionet tuaja, qofshin ato servera lokalë, në cloud apo në stacione pune me kërkesa të larta.
Kombinimi i njohurive të arkitekturës së bërthamës, akordimit të imët me sysctl, kompilimit të kontrolluar, përdorimit selektiv të patch-eve në kohë reale dhe një sistemi të mirë metrikash i lejon një administratori ose ekipi operacionesh të arrijë përgjigje më të shpejta, vonesa më të ulëta dhe stabilitet më të mirë të përgjithshëm pa pasur nevojë të ndryshojë harduerin me provokimin më të vogël ose të kompromentojë sigurinë e sistemit.
