Udhëzues i avancuar për optimizimin e kernelit Linux dhe zvogëlimin e vonesës

Informatec Digital » Burime » Udhëzues i avancuar për optimizimin e kernelit Linux dhe zvogëlimin e vonesës

Kur flasim për performancën në Linux, pothuajse gjithçka përfundon duke treguar në të njëjtin vend: kernel si komponenti qendror që kontrollon vonesën, stabilitetin dhe përdorimin e burimeveRregullimi i duhur i tij mund të bëjë diferencën midis një sistemi që mezi "ia del mbanë" dhe një sistemi që përgjigjet pa probleme në servera, desktopë, mjedise cloud, apo edhe në... pajisje shumë të vjetra.

Ky udhëzues përqendrohet në mënyrën se si Optimizoni kernelin e Linux-it për të minimizuar vonesën pa kompromentuar sigurinë ose mirëmbajtjenDo të mbulojmë gjithçka, nga konceptet themelore arkitekturore deri te përshtatjet me sysctl, përpilimi i bërthamave të personalizuara, përdorimi i patch-eve në kohë reale, përshtatja për rrjetet me vonesë të ulët (si në EC2) dhe teknikat e monitorimit dhe krahasimit për të matur nëse ajo që po përshtatni përmirëson në të vërtetë diçka.

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 memorie, procese, ndërprerje, drajverë dhe sisteme skedarësh. e tij dizajn monolit por modularFalë moduleve të ngarkueshme, ju lejon të aktivizoni ose çaktivizoni në mënyrë fleksibile funksionalitetet pa e rikompiluar të gjithë sistemin.

Për të kuptuar se nga vijnë vonesat, është thelbësore të njihen disa nënsisteme: planifikues procesi (planifikues)Menaxhimi i memories dhe trajtimi i ndërprerjeve janë thelbësorë. 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 pajisje të fuqishme.

Konfigurimi i bërthamës përfshin opsione të tilla si CONFIG_PREEMPT, CONFIG_PREEMPT_VOLUNTARY ose CONFIG_SMPKëta faktorë përcaktojnë shkallën në të cilën bërthama mund të ndërpritet për t'u marrë me detyra më urgjente dhe si i shfrytëzon ai sistemet me shumë bërthama. Zgjedhja e modelit të duhur të parandalimit ndryshon ndjeshëm vonesën e perceptuar në desktopë, serverë me vonesë të ulët ose sisteme industriale.

Në serverat modernë, topologjia e harduerit gjithashtu ka rëndësi: shpërndarja e bërthamave, soketave, NUMA-s dhe hierarkisë së memorjes së përkohshmeRregullimi i imët i afiniteteve të CPU-së dhe politikave NUMA (p.sh., rregullimi 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 së përkohshme, e cila është thelbësore kur duam të minimizojmë luhatjet dhe vonesat e paparashikueshme.

Për më tepër, bashkëveprimi midis planifikuesit të CPU-së dhe nënsistemeve të Hyrjet/Daljet (disku dhe rrjeti) përcaktojnë throughput-in dhe latencën nga fillimi në fund. që aplikacionet shohin. Përpara se të prekni ndonjë gjë, këshillohet të dokumentoni gjendjen aktuale (konfigurimi i bërthamës, sysctl, GRUB, modulet e ngarkuara) në mënyrë që të mund të ktheheni shpejt në gjendjen e mëparshme 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ë përmes /proc/sys, pa pasur nevojë të rikompiloni. Është pika ideale e fillimit për të filluar akordimin pa u zhytur ende në kompilime.

Në fushën e rrjetit, parametra të tillë si net.core.rmem_max, net.core.wmem_max ose net.ipv4.tcp_congestion_control Ato 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 kujtesën, vlera të tilla si vm.swappiness, vm.dirty_ratio, vm.vfs_cache_pressure ose vm.overcommit_memory Ato ju lejojnë të kontrolloni se sa përdoret shkëmbimi, si menaxhohet memoria e faqes në memorje dhe sjelljen e memories virtuale. Ulja e shkallës së shkëmbimit (për shembull, në 10) zakonisht ndihmon në parandalimin e përdorimit shumë të shpeshtë të shkëmbimit nga sistemi, duke zvogëluar luhatjet e vonesës së hyrjes/daljes 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ë thelbësore të përshtateni kernel.shmmax, kernel.shmall dhe numri maksimal i skedarëve të hapur me fs.file-max dhe fs.nr_openKëto kufij të papërshtatshëm mund të shkaktojnë pengesa dhe gabime që janë të vështira për t'u diagnostikuar nën ngarkesë.

Qasja më e mirë është të zbatohen ndryshime të vogla, të matet ndikimi i tyre me mjete monitorimi dhe vetëm atëherë ruajini ato në /etc/sysctl.conf ose në /etc/sysctl.d/Në mjediset e kontejnerizuara, mos harroni se shumë parametra të kernelit janë globalë për hostin: ndryshimi i tyre pa kujdes mund të ndikojë 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 shumë i fuqishëm kur dëshironi zvogëloni vonesën, hiqni mbingarkesën e panevojshme ose mbështesni pajisje të rrallaEdhe pse shpërndarjet vijnë me kernel mjaft të gjithanshëm, 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 derivate, është shumë e përshtatshme të kompiloni "Në stilin Debian"Për të marrë paketa .deb të kernelit, kokat dhe libraritë e lidhura. Kjo ju lejon të vendosni atë kernel të personalizuar në shumë makina thjesht duke instaluar paketat dhe duke menaxhuar versionet me depon tuaj."

Në botën reale, përpilimi manual shpesh ka kuptim kur punoni me pajisje të vjetra ose shumë të kufizuaraNjë shembull tipik është një netbook i vjetër me një CPU Atom dhe 1 GB RAM, ku një kernel modern gjenerik, plot me drajverë dhe opsione serveri të panevojshëm, sjell vonesa dhe konsum shtesë të CPU-së që nuk mund t'i përballoni.

Një strategji e zakonshme është të fillohet nga konfigurimi aktual i kernelit (për shembull, duke kopjuar konfigurimi /boot), dhe prej andej priteni ose rregulloni. Mund ta ndryshoni modelin e parapërgatitjes në "Bërthama e Parapërgatitshme (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ç është Bfq në formën e një moduli për të përmirësuar përvojën në disqet mekanike.

Për të shmangur shpenzimin e gjysmës së jetës suaj duke kompiluar, ka kuptim ta bëni ndërtimin në një makinë më të fuqishme dhe, nëse është e nevojshme, të përdorni përpilim i 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: është e këshillueshme duke testuar kernelin e ri në nyjet e Ishujve Kanarie, kanë shtigje të qarta rikthimi në menaxherin e nisjes dhe regjistrojnë regjistra dhe metrika 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ë kernelit dikton 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, gjë që ndikon drejtpërdrejt në vonesa e përgjigjesKjo 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ë shumë të fokusuara në throughput-in e serverit), përparësi vullnetare dhe bërthamë e parapërcaktueshme për desktopKjo i jep përparësi kohës së shpejtë të reagimit të aplikacioneve interaktive. Rregullimi i këtij cilësimi mund të përmirësojë ndjeshëm performancën e sistemeve desktop, audios ose edhe të makinave të vjetra me ngarkesë të lartë.

Kur duhet të shkoni një hap më tej, shfaqen këto: Patch-et PREEMPT dhe PREEMPT_RTKëto modifikime ndryshojnë 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ë modë, por në matje konkrete të latencës dhe luhatjesSë pari, këshillohet që të shfrytëzohen plotësisht cilësimet e planifikuesit, afinitetet me CPU-në, sysctl dhe, nëse është e aplikueshme, konfigurime të tilla si dinamika pa tik-tak përpara se të ndërlikohet mirëmbajtja me një pemë RT.

Pajtueshmëria gjithashtu duhet të merret në konsideratë: disa Drajverët dhe nënsistemet nuk janë përshtatur plotësisht për RT dhe mund të kërkojë 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 i pandryshueshëm si parazgjedhje për CPU-të joaktiveKjo zvogëlon konsumin e energjisë duke shmangur ndërprerjet periodike kur bërthama është në gjendje të papërdorur. Mund të aktivizohet një modalitet për ngarkesat e punës të ndjeshme ndaj vonesës. dinamik pa tik-tak në një grup bërthamashnë mënyrë që vetëm një CPU ("bërthama kryesore") të trajtojë shumicën e detyrave të bazuara në kohë, dhe pjesa tjetër të jetë sa më e lirë 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 izolcpusKjo 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 e diskut ka një ndikim të madh në vonesa e perceptuar nga aplikacionetveçanërisht në bazat e të dhënave dhe shërbimet që kryejnë shumë operacione të vogla dhe të shpeshta.

Nga ana e kujtesës, zvogëloni vm.ndërrim minimizoni 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 sistemi po përpiqet të pastrojë memorjen e përkohshme të inode dhe dentry, dhe vm.nr_hugepages Ai lejon rezervimin e HugePages statike për ngarkesa të rënda siç janë 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 Këto mbeten opsionet 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ëkohshme të 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 si konfigurohen pirgu TCP/IP dhe vetë kerneliKjo ë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ërcimet e rrjetit që paketat kryejnë: përdorimi i topologjive më të drejtpërdrejta, balancuesit e ngarkesës afër backend-it ose zonat e disponueshmërisë së optimizuar zvogëlojnë kohën e udhëtimit në milisekonda para se të preket sistemi operativ.

Brenda kernelit, konfigurimi i rrjetit përfshin rritjen e përshkruesit e skedarëve (ulimit -n), madhësia e buffer-ave të pranimit dhe dërgimit me net.core.rmem_max, net.core.wmem_max, net.ipv4.tcp_rmem, net.ipv4.tcp_wmemdhe aktivizoni opsione të tilla si TCP i hapur i shpejtë për të zvogëluar vonesën e vendosjes së 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.

Mund të përdoret gjithashtu irqbalance për të shpërndarë IRQ-të nëpër bërthama të shumta, ose çaktivizojeni atë dhe caktoni manualisht afinitetet e ndërprerjeve dhe radhës së rrjetit (RSS/RPS) ndaj bërthamave specifike, diçka shumë tipike në mjedise me latencë ultra të ulët ose kur përdorni DPDK dhe anashkaloni një pjesë të mirë të pirgut të bërthamës.

Një tjetër parametër që duhet marrë në konsideratë është 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ërthama të tjera. Çdo mjedis ka pikën e vet të preferuar 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ërbime aktive në sistem deri në konfigurimin specifik të 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 të tilla si renice, chart dhe tasksetRregullimi i përparësisë së një procesi (renice), dhënia e planifikimit në kohë reale (chrt -f 99) ose caktimi i tij te 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 p.sh. Nginx ose Apache Ata kanë nevojë për rregullim të imët të punëtorëve, ruajtjen e të dhënave, memorjet e përkohshme dhe kompresimin. Bazat e të dhënave si PostgreSQL ose MySQL Ata duhet të rishikojnë madhësitë e buffer-ave, pikat e kontrollit, grupin e lidhjeve dhe parametrat e shkrimit sinkron për të arritur vonesa të ulëta dhe të qëndrueshme.

JVM-të gjithashtu luajnë një rol: zgjedhja e mbledhësve të mbeturinave si G1GC ose ZGC Rregullimi i madhësive të grumbullit të të dhënave mund të zvogëlojë pauzat që, nga një perspektivë e jashtme, shfaqen si vonesë. Në mjediset e virtualizuara dhe të kontejnerizuara, shpërndarja e duhur është thelbësore. vCPU, vRAM dhe kuota I/O Shmang grindjet e heshtura që më vonë shfaqen si radhë të pafundme në disk ose CPU të mbingarkuar.

Monitorimi dhe krahasimi i bërthamës dhe sistemit

I gjithë ky akordim është i padobishëm nëse nuk e matni ndikimin. Çelësi është te kombinimi. monitorim i vazhdueshëm me teste të riprodhueshme të performancësnë 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, rekomandohet të vendosen sisteme metrike si p.sh. Prometeu, i mbledhur ose sistematik me eksportuesit që ekspozojnë numëruesit e CPU-së, I/O, vonesat e diskut dhe rrjetit, radhët e proceseve, etj. Këto të dhëna, të vizualizuara në Grafana ose mjete të ngjashme, ndihmojnë 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" çdo ndryshimi. Mjete të tilla si sysbench (për CPU-të dhe bazat e të dhënave), Fio (për disk) ose iperf3 (Për rrjetet) ato lejojnë ndërtimin e skenarëve të përsëritshëm. Dokumentacioni është thelbësor. versionet e kernelit, konfigurimet sysctl, hardueri dhe parametrat e testimit në mënyrë që krahasimet të kenë kuptim 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, rregullimit 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, vonesë më e ulët dhe stabilitet i përgjithshëm i përmirësuar pa pasur nevojë të ndryshoni harduerin me provokimin më të vogël ose të kompromentoni sigurinë e sistemit.

Artikulli i lidhur:

Linux 6.14: Çfarë ka të re, përmirësime të sigurisë dhe mbështetje për harduerin