Paplašināta rokasgrāmata Linux kodola optimizēšanai un latentuma samazināšanai

Informatec Digital » Resursi » Paplašināta rokasgrāmata Linux kodola optimizēšanai un latentuma samazināšanai

Kad mēs runājam par veiktspēju Linux sistēmā, gandrīz viss norāda uz vienu un to pašu vietu: kodols kā centrālā sastāvdaļa, kas kontrolē latentumu, stabilitāti un resursu izmantošanuPareiza noregulēšana var radīt atšķirību starp sistēmu, kas tik tikko "tiek galā", un tādu, kas vienmērīgi reaģē serveros, galddatoros, mākoņvidē vai pat iekštelpās. ļoti veca aparatūra.

Šajā rokasgrāmatā uzmanība tiek pievērsta tam, kā Optimizējiet Linux kodolu, lai samazinātu latentumu, neapdraudot drošību vai apkopes iespējasMēs apskatīsim visu, sākot no arhitektūras pamatkoncepcijām līdz pielāgošanai ar sysctl, pielāgotu kodolu kompilēšanai, reāllaika ielāpu izmantošanai, pielāgošanai tīkliem ar zemu latentumu (piemēram, EC2) un uzraudzības un salīdzinošās novērtēšanas metodēm, lai noteiktu, vai jūsu pielāgošana patiešām kaut ko uzlabo.

Linux kodola arhitektūra un galvenie latentuma aspekti

Linux kodols darbojas kā starpnieks starp lietojumprogrammām un aparatūru, pārvaldot atmiņa, procesi, pārtraukumi, draiveri un failu sistēmas. Su monolīta, bet modulāra konstrukcijaPateicoties ielādējamajiem moduļiem, tas ļauj elastīgi aktivizēt vai deaktivizēt funkcijas, nepārkompilējot visu sistēmu.

Lai saprastu, no kurienes rodas latentums, ir svarīgi zināt vairākas apakšsistēmas: procesu plānotājs (plānotājs)Atmiņas pārvaldība un pārtraukumu apstrāde ir ļoti svarīgas. Slikti konfigurēts plānotājs, agresīva atmiņas politika vai pārmērīgs nekontrolētu pārtraukumu skaits var izraisīt lēnu reakcijas laiku pat ar jaudīgu aparatūru.

Kodola konfigurācija ietver tādas opcijas kā CONFIG_PREEMPT, CONFIG_PREEMPT_VOLUNTARY vai CONFIG_SMPŠie faktori nosaka, cik lielā mērā kodola darbību var pārtraukt, lai veiktu steidzamākus uzdevumus, un kā tas izmanto vairāku kodolu sistēmas. Pareiza priekšlaicīguma modeļa izvēle būtiski maina uztverto latentumu galddatoros, serveros ar zemu latentumu vai rūpnieciskajās sistēmās.

Mūsdienu serveros aparatūras topoloģijai ir arī nozīme: kodolu, ligzdu, NUMA un kešatmiņas hierarhijas sadalījumsCPU afinitāšu un NUMA politiku precizēšana (piemēram, procesu un atmiņas piesaistīšana vienam mezglam) palīdz samazināt piekļuves laikus un uzlabot kešatmiņas trāpījumu ātrumu, kas ir ļoti svarīgi, ja vēlamies samazināt svārstības un neparedzamas latentuma vērtības.

Turklāt mijiedarbība starp CPU plānotāju un apakšsistēmām I/O (diska un tīkla) nosaka caurlaidspēju un pilno latentumu. ko redz lietojumprogrammas. Pirms kaut ko aiztikt, ieteicams dokumentēt pašreizējo stāvokli (kodola konfigurācija, sysctl, GRUB, ielādētie moduļi), lai varētu ātri atjaunot sākotnējo stāvokli, ja izmaiņas pasliktina veiktspēju.

Pielāgojumi, izmantojot sysctl, lai uzlabotu latentumu un veiktspēju

saskarni sysctl ļauj modificēt kodola parametrus darbības laikā caur /proc/sys, bez nepieciešamības to atkārtoti kompilēt. Tas ir ideāls sākumpunkts, lai sāktu regulēšanu, vēl neieslīgstot kompilācijās.

Tīkla laukā tādi parametri kā net.core.rmem_max, net.core.wmem_max vai net.ipv4.tcp_congestion_control Tie tieši ietekmē caurlaidspēju, latentumu un TCP savienojuma darbību. Pareiza buferu un pārslodzes algoritma pielāgošana ir ļoti svarīga tīmekļa serveriem ar lielu datplūsmu vai mākoņa instancēm ar zemu latentumu.

Atmiņai tādas vērtības kā vm.swappiness, vm.dirty_ratio, vm.vfs_cache_pressure vai vm.overcommit_memory Tie ļauj kontrolēt, cik daudz mijmaiņas tiek izmantots, kā tiek pārvaldīta lapas kešatmiņa un virtuālās atmiņas darbību. Mijmaiņas apjoma samazināšana (piemēram, līdz 10) parasti palīdz novērst pārāk biežu mijmaiņas izmantošanu sistēmā, samazinot diska I/O latentuma pieaugumus.

Ja strādājat ar lielām datubāzēm vai lietojumprogrammām, kas izmanto milzīgu koplietojamās atmiņas apjomu, ir svarīgi pielāgot kodols.shmmax, kodols.shmall un maksimālais atvērto failu skaits ar fs.file-max un fs.nr_openŠie nepietiekami izmērītie ierobežojumi var izraisīt sastrēgumus un kļūdas, kuras ir grūti diagnosticēt slodzes laikā.

Vislabākā pieeja ir ieviest nelielas izmaiņas, izmērīt to ietekmi ar uzraudzības rīkiem un tikai tad saglabājiet tos failā /etc/sysctl.conf vai /etc/sysctl.d/Konteinerizētās vidēs jāatceras, ka daudzi kodola parametri ir globāli resursdatoram: to neuzmanīga mainīšana var ietekmēt visus pakalpojumus, tāpēc sysctl apvienošana ar cgroups un namespaces ir gandrīz obligāta.

Pielāgotu kodolu kompilēšana un uzturēšana

Pielāgota kodola kompilēšana joprojām ir ļoti spēcīgs rīks, kad vēlaties samazināt latentumu, novērst nevajadzīgas pieslēgvietas vai atbalstīt retu aparatūruLai gan distribūcijām ir diezgan daudzpusīgi kodoli, dažos gadījumos konkrēts kodols rada visu atšķirību.

Klasiskā darbplūsma ietver koda lejupielādi no kernel.org vai ielāpoti koki, piemēram, xanmod vai Likorikssun izmantojiet tādus rīkus kā make menuconfig lai izvēlētos opcijas. Saglabājot .config failu savā git repozitorijā kopā ar būvēšanas skriptiem, varat reproducēt būvējumus un saglabāt konsekvenci starp versijām.

Ja izmantojat Debian vai tā atvasinājumus, ir ļoti ērti kompilēt “Debian stilā"Lai iegūtu kodola, galvenes un saistīto bibliotēku .deb pakotnes. Tas ļauj izvietot šo pielāgoto kodolu vairākās ierīcēs, vienkārši instalējot pakotnes un pārvaldot versijas ar savu repozitoriju."

Reālajā pasaulē manuāla kompilēšana bieži vien ir jēgpilna, strādājot ar veca vai ļoti ierobežota aparatūraTipisks piemērs ir vecs netbook ar Atom centrālo procesoru un 1 GB RAM, kur mūsdienīgs vispārīgs kodols, pilns ar nevajadzīgiem draiveriem un servera opcijām, ievieš latentumu un papildu centrālā procesora patēriņu, ko nevar atļauties.

Izplatīta stratēģija ir sākt no pašreizējās kodola konfigurācijas (piemēram, kopējot /boot konfigurācija), un no turienes apgriezt vai pielāgot. Jūs varat mainīt priekšapmaksas modeli uz “Preemptible Kernel (zemas latentuma darbvirsma)"lai prioritizētu interaktīvo darbvirsmas atbildi vai pievienotu konkrētus I/O plānotājus, piemēram, Bfq moduļa veidā, lai uzlabotu pieredzi ar mehāniskajiem diskiem.

Lai pusi dzīves nepavadītu kompilējot, ir lietderīgi veikt kompilēšanu uz jaudīgākas mašīnas un, ja nepieciešams, izmantot krustkompilācija (Piemēram, 32 bitu kodola kompilēšana Atom datoram no x86_64 datora, vienkārši pielāgojot ARCH un atbilstošās rīkjoslas). Pēc tam jums tikai jāinstalē .deb faili mērķa datorā un jāpievieno atbilstošais ieraksts GRUB.

Sarežģītākā daļa ir apkope: tā ir ieteicama jaunā kodola testēšana Kanāriju salu mezglos, sāknēšanas pārvaldniekā ir skaidri atcelšanas ceļi un pārejas laikā tiek reģistrēti žurnāli un metrikas, lai noteiktu veiktspējas vai draiveru saderības regresijas.

Preempcijas modeļi un PREEMPT_RT ielāpi sistēmām ar zemu latentumu

Kodola priekšrocību modelis nosaka, cik bieži var pārtraukt darbojošos uzdevumu, lai ļautu to pārņemt augstākas prioritātes uzdevumam, kas tieši ietekmē atbildes latentumsTas ietver gan standarta konfigurācijas opcijas, gan reāllaika ielāpus.

Vispārīgie kodoli piedāvā vairākas iespējas: bez priekšrocību piešķiršanas (vairāk koncentrējas uz servera caurlaidspēju), brīvprātīgu priekšrocību piešķiršanu un iepriekšizņemams kodols darbvirsmaiTas piešķir prioritāti interaktīvo lietojumprogrammu ātrajam reakcijas laikam. Šī iestatījuma pielāgošana var ievērojami uzlabot galddatoru sistēmu, audio vai pat ļoti noslogotu vecāku datoru veiktspēju.

Kad nepieciešams spert soli tālāk, parādās sekojošais: PREEMPT un PREEMPT_RT ielāpiŠīs modifikācijas maina būtiskas kodola daļas, lai samazinātu sadaļas, kuras nevar tikt priekšlaicīgi izņemtas. PREEMPT_RT ir paredzēts sistēmām, kurās sliktākā gadījuma latentumam (ne tikai vidējam) ir jābūt ļoti zemam un paredzamam: rūpnieciskajai automatizācijai, profesionālai audioiekārtām, telekomunikācijām vai augstfrekvences tirdzniecībai.

Lēmums ieviest PREEMPT_RT nedrīkst būt balstīts uz modi, bet gan uz specifiski latentuma un svārstību mērījumiPirmkārt, pirms apkopes sarežģīšanas ar RT koku ieteicams pilnībā izmantot plānotāja iestatījumus, CPU afinitātes, sysctl un, ja piemērojams, tādas konfigurācijas kā dynamic tickless.

Jāņem vērā arī saderība: daži Draiveri un apakšsistēmas nav pilnībā pielāgotas RT un tam var būt nepieciešamas noteiktas versijas vai papildu ielāpi. Saprātīgākā pieeja ir sagatavot apkopes plānu, kurā skaidri norādīts, kad un kā integrēt galvenās kodola jaunās versijas ar RT atzaru, kas periodiski sinhronizējas, bet joprojām nedaudz atpaliek.

CPU plānošanas regulēšana, bezkustīga darbība un kodola izolācija

Papildus priekšrocību modeļa izvēlei varat precīzi noregulēt latentumu, spēlējoties ar centrālā procesora plānošanu un kodola taimera darbību, īpaši uzņēmumiem paredzētos izplatījumos, piemēram, RHEL.

Piemēram, Red Hat Enterprise Linux 8 ir aprīkots ar kodols pēc noklusējuma nedarbojas dīkstāvē esošiem centrālajiem procesoriemTas samazina enerģijas patēriņu, izvairoties no periodiskiem pārtraukumiem, kad kodols ir dīkstāvē. Latentuma jutīgām darba slodzēm var iespējot režīmu. dinamisks bezkustīgs kodolu komplektālai tikai viens centrālais procesors ("mājas kodols") apstrādātu lielāko daļu laika uzdevumu, un pārējie būtu pēc iespējas brīvāki no periodiskiem pārtraukumiem.

Šī konfigurācija tiek veikta, pievienojot atbilstošus parametrus kodola komandrinda GRUB vidēkonfigurācijas atkārtota ģenerēšana un pēc tam kritisko kodola pavedienu, piemēram, RCU pavedienu vai pavedienu, afinitātes pielāgošana bdi-flush, lai tie atrastos apkopei paredzētajā kodolā.

Šo pieeju var papildināt ar parametru izolcpusTas ļauj izolēt kodolus no parastajiem lietotāja telpas uzdevumiem. Zema latentuma scenārijos ir ļoti bieži rezervēt vairākus kodolus tikai kritiskai lietojumprogrammai, kamēr pārējo sistēmu (dēmonus, pārtraukumus utt.) apstrādā citi kodoli.

Lai pārbaudītu, vai darbojas dinamiskais bezkustīgais režīms, var veikt vienkāršus testus ar stress vai skriptus, kas uz sekundi noslogo centrālo procesoru un novēro ar taimera skaitītāji Kā pārtraukumu skaits sekundē samazinās no tūkstošiem līdz tikai vienam atsevišķos kodolos, kas liecina par periodiskā taimera izzušanu.

Atmiņas un krātuves pārvaldība, koncentrējoties uz latentumu

Veidam, kā kodols pārvalda atmiņu un diska I/O, ir milzīga ietekme uz lietojumprogrammu uztvertā latentumaīpaši datubāzēs un pakalpojumos, kas veic daudzas nelielas un biežas darbības.

Atmiņas pusē samaziniet vm.swapiness minimizējiet mijmaiņas izmantošanu (kas gandrīz vienmēr ir daudz lēnāka nekā RAM), vm.vfs_cache_pressure Tas kontrolē, cik ātri sistēma mēģina notīrīt inode un dentry kešatmiņu, un vm.nr_hugepages Tas ļauj rezervēt statiskas HugePages lapas lielām slodzēm, piemēram, datubāzēm vai JVM, samazinot TLB pieskaitāmās izmaksas.

Noliktavā izvēlieties atbilstošs I/O plānotājs atkarībā no diska tipa Tas ir kritiski svarīgi. Mūsdienu SSD diskos parasti ir ieteicams izmantot... none o mq-deadlineSavukārt mehāniskajos diskos un daudzuzdevumu sistēmās taisnīguma labad izstrādātie algoritmi varētu būt labāki, piemēram, BfqTurklāt failu sistēmu pievienošana ar tādām opcijām kā noatime y nodiratime Izvairieties no nevajadzīgas rakstīšanas katru reizi, kad tiek piekļūts failam vai direktorijam.

Runājot par failu sistēmām, ext4 un XFS Šīs joprojām ir visizplatītākās iespējas: labi noregulēts ext4 ir droša izvēle, savukārt XFS mēdz labāk mērogoties augstas vienlaicīguma apstākļos. Ļoti prasīgos scenārijos RAID (RAID 10 datubāzēm, RAID 0 pagaidu datu krātuvei) apvienošana ar labu plānotāju var samazināt vidējo latentumu un, pats galvenais, mainīgumu.

Tīkla un kodola optimizācija zemai latentuma nodrošināšanai operētājsistēmās Linux un EC2

Augstas veiktspējas tīkla lietojumprogrammās latentums ir atkarīgs ne tikai no aparatūras vai attāluma, bet arī no kā tiek konfigurēts TCP/IP steks un pats kodolsTas ir īpaši redzams mākoņpakalpojumos, piemēram, Amazon EC2 ar ENA saskarnēm.

Vispirms ir svarīgi samazināt ārējos faktorus, piemēram, tīkla lēcieni ko pakotnes veic: izmantojot tiešākas topoloģijas, slodzes līdzsvarotājus tuvu aizmugursistēmai vai optimizētas pieejamības zonas, tiek samazināts pārvietošanās laiks milisekundēs, pirms tas pat pieskaras operētājsistēmai.

Kodola ietvaros tīkla konfigurācija ietver palielināšanu failu deskriptori (ulimit -n), izmēra saņemšanas un nosūtīšanas buferus ar tīkls.core.rmem_max, tīkls.core.wmem_max, tīkls.ipv4.tcp_rmem, tīkls.ipv4.tcp_wmemun aktivizējiet tādas opcijas kā TCP Fast Open lai samazinātu savienojuma izveides latentumu.

AWS ENA saskarnēs pārtraukumu moderēšanai ir svarīga loma: pēc noklusējuma draiveris grupē paketes, lai samazinātu IRQ skaitu. rx-usecs un tx-usecsJa vēlaties samazināt latentumu līdz absolūtam minimumam, varat atspējot šo moderāciju, ethtool -CIestatot rx-usecs un tx-usecs uz nulli, tiek samazināts latentums, bet palielināts pārtraukumu apjoms, tāpēc ir jāatrod līdzsvars atkarībā no slodzes.

To var arī izmantot irqbalance, lai sadalītu IRQ vairākos kodolos, vai arī atspējot to un manuāli iestatīt pārtraukumu un tīkla rindas (RSS/RPS) afinitātes konkrētiem kodoliem, kas ir ļoti tipiski īpaši zemas latentuma vidēs vai izmantojot DPDK un izlaižot ievērojamu daļu no kodola kaudzes.

Vēl viens parametrs, kas jāņem vērā, ir CPU C stāvokļiDziļi miega stāvokļi samazina enerģijas patēriņu, bet rada aizkaves, kad kodols "pamostas". Lai samazinātu reakcijas latentumu, varat ierobežot šos dziļos stāvokļus, pieņemot lielāku enerģijas patēriņu un mazāku rezervi Turbo Boost funkcijai citos kodolos. Katrai videi ir savs optimālais laiks starp patērētajiem vatiem un iegūtajām mikrosekundēm.

CPU, pakalpojumu un lietojumprogrammu optimizācija, lai samazinātu latentumu

Papildus pašam kodolam, apkārtējai videi ir daudz ko teikt par kopējo latentumu: sākot no aktīvi pakalpojumi sistēmā līdz katras lietojumprogrammas specifiskajai konfigurācijai.

Augstas veiktspējas serverim vajadzētu darbināt tikai dēmoni, kas ir patiesi nepieciešamiPakalpojumi, piemēram, Bluetooth, drukāšana vai tīkla automātiskā noteikšana (CUPS, Avahi utt.) serveru iekārtās, patērē tikai centrālo procesoru, atmiņu un ievades/izvades resursus, nesniedzot nekādu labumu. Pārskatiet šeit. systemctl list-unit-files --state=enabled Un nevajadzīgu lietu atspējošana ir viena no lētākajām un efektīvākajām lietām, ko varat darīt.

Lai noteiktu kritisko procesu prioritāti, varat izmantot tādus rīkus kā Renice, chart un uzdevumu komplektsProcesa prioritātes pielāgošana (renice), reāllaika plānošanas piešķiršana (chrt -f 99) vai piešķiršana konkrētiem kodoliem (taskset) samazina traucējumus citiem uzdevumiem, uzlabojot centrālā procesora paredzamību datubāzēm, VoIP, straumēšanas vai tirdzniecības pakalpojumiem.

Lietojumprogrammu līmenī regulēšana ir tikpat svarīga kā kodola regulēšana. Tīmekļa serveri, piemēram, Nginx vai Apache Viņiem ir nepieciešama darbinieku, saglabāšanas, kešatmiņu un saspiešanas precīza noregulēšana. Datubāzes, piemēram, PostgreSQL vai MySQL Lai sasniegtu zemu un stabilu latentumu, viņiem ir jāpārskata buferu izmēri, kontrolpunkti, savienojumu pūls un sinhronās rakstīšanas parametri.

Arī JVM ir nozīme: atkritumu savācēju izvēle, piemēram G1GC vai ZGC Pielāgojot kaudzes izmērus, var samazināt pauzes, kas no ārpuses šķiet kā latentums. Virtualizētās un konteinerizētās vidēs pareiza izplatīšana ir ļoti svarīga. vCPU, vRAM un I/O kvotas Tas novērš klusu konkurenci, kas vēlāk parādās kā nebeidzamas rindas diskā vai pārslogots procesors.

Kodola un sistēmas uzraudzība un salīdzinošā novērtēšana

Visa šī regulēšana ir bezjēdzīga, ja netiek mērīta tās ietekme. Galvenais ir kombinēšanā. nepārtraukta uzraudzība ar atkārtojamiem veiktspējas testiemlai visas kodola vai sysctl izmaiņas varētu novērtēt ar objektīviem datiem.

Lai redzētu sistēmas vispārējo stāvokli, varat izmantot klasiskus rīkus, piemēram, htop, vmstat, iotop o sarKad nepieciešama sīkāka informācija, tiek izmantoti īpaši kodola rīki, piemēram, perf un ftracekas ļauj ar ievērojamu precizitāti izsekot plānotāja, pārtraukumu un iekšējo izsaukumu darbībai.

Ražošanas vidē ieteicams ieviest metrikas sistēmas, piemēram, Prometheus, apkopots vai sysstat ar eksportētājiem kas atklāj centrālā procesora skaitītājus, ievades/izvades, diska un tīkla latentumus, procesu rindas utt. Šie dati, kas vizualizēti Grafana vai līdzīgos rīkos, palīdz atklāt regresijas vai anomālijas, pirms gala lietotājs pamana problēmas.

Salīdzinošās novērtēšanas nolūkā ideja ir atkārtot faktisko darba slodzi un salīdzināt katru izmaiņu "pirms un pēc". Rīki, piemēram, sysbench (centrālajiem procesoriem un datubāzēm), FIO (diska gadījumā) vai iperf3 (Tīklu gadījumā) tie ļauj veidot atkārtojamus scenārijus. Dokumentācija ir būtiska. kodola versijas, sysctl konfigurācijas, aparatūra un testa parametri lai salīdzinājumi laika gaitā iegūtu jēgu.

Praksē Linux kodola optimizācija ir iteratīvs process: jūs pārbaudāt virkni uzlabojumu, izmērāt rezultātus, saglabājat to, kas sniedz reālu labumu, un atmetat pārējo. Ar labu izmaiņu pārvaldību jūs varat pārvērst uzlabojumus jaunajās kodola versijās (piemēram, jaunākās sērijas ar plānotāju, grafiku, jaudu vai tīkla uzlabojumiem) izmērāmos ieguvumos jūsu lietojumprogrammām neatkarīgi no tā, vai tās ir lokālas serveru sistēmas, mākonī vai prasīgās darbstacijās.

Kodola arhitektūras zināšanu, precīzas pielāgošanas ar sysctl, kontrolētas kompilācijas, reāllaika ielāpu selektīvas izmantošanas un labas metrikas sistēmas apvienojums ļauj administratoram vai operāciju komandai sasniegt Ātrāka reakcija, zemāka latentuma pakāpe un uzlabota kopējā stabilitāte bez nepieciešamības mainīt aparatūru pie mazākās provokācijas vai apdraudēt sistēmas drošību.