- Täiustatud kerneli häälestamine sysctl-iga võimaldab teil võrgu, mälu, failide ja ajastaja seadistusi kohandada, et maksimeerida jõudlust ja stabiilsust.
- Iga muudatuse tegeliku mõju valideerimiseks on oluline mõõta enne ja pärast võrdlusaluste ja jälgimise abil.
- Spetsiifilised profiilid (veeb, andmebaasid, madal latentsus, Kubernetes) saavutavad paremaid tulemusi kui üksik üldine konfiguratsioon.
- Tööriistad nagu perf, ftrace, vmstat ja iostat hõlbustavad iteratiivset, turvalist ja objektiivset andmepõhist optimeerimist.
Kui oled juba mõnda aega Linuxi servereid haldanud, avastad lõpuks, et keskpärase ja suure koormuse all töötava süsteemi erinevus seisneb selles, kui hästi oled kerneli häälestanud. Asi pole ainult suurema muutmälu või võimsama protsessori installimises: paljud kitsaskohad saab lahendada mõne hoolikalt valitud parameetri kohandamisega.
Kernel pakub sadu võrgu-, mälu-, failisüsteemi- ja protsesside ajastamise valikuid, mida saab reaalajas muuta. Selle tööriista abil sysctl ja mõned kohandused /procRiistvarast on võimalik maksimumi võtta ja saavutada madalam latentsus, suurem läbilaskevõime ja parem stabiilsus See kehtib nii veebiserverite ja andmebaaside kui ka reaalajas keskkondade ja Kubernetesi kohta. Siiski on oluline täpselt teada, mida te teete ja kuidas seda mõõta.
Mis on sysctl ja kuidas see kerneli parameetreid korraldab?
Utiliit sysctl See on värav kerneli parameetrite muutmiseks ilma uuesti kompileerimise või taaskäivitamiseta, võimaldades lugeda ja muuta väärtusi käitusajal konfiguratsioonide koheseks testimiseks. Need parameetrid on korraldatud madalas hierarhilises puus /proc/sys/ja igaüks neist kontrollib süsteemi teatud käitumist.
Seadistused on rühmitatud eraldi kategooriatesse, mis teeb konkreetse jõudluse või stabiilsuse probleemi korral vajaliku kohandamise kindlaksmääramise lihtsaks. See struktuur võimaldab teil keskenduda näiteks ainult võrgule (net.*), mälule (vm.*) või failisüsteemile (fs.*), ilma et peaksite ülejäänud kerneli valikutesse eksima.
Peamised kategooriad, mida leiate /proc/sys/ Nende hulka kuuluvad muuhulgas:
- tuum.*: üldised kerneli valikud (ajasti, PID, sõnumid, NUMA jne).
- vm.*virtuaalmälu haldus, swap, vahemälud ja üleliigse koormuse poliitikad.
- neto*IPv4/IPv6 võrgupinu, TCP/UDP puhvrid, järjekorrad, ummikute kontroll.
- fs.*: deskriptorite, inode'ide, inotify, AIO ja VFS käitumise piirid.
- areng*: teatud seadmete ja draiverite spetsiifilised parameetrid.
koos sysctl -a Saate loetleda kõik saadaolevad parameetrid ja selliste käskudega nagu sysctl vm.swappiness o sysctl net.ipv4.tcp_tw_reuse konkreetsete väärtuste lugemine, mis on võtmetähtsusega auditeeri praegust konfiguratsiooni enne millegi muutmist. Millegi konkreetse leidmiseks on tavaline filtreerida grepNäiteks: sysctl -a | grep tcp.
Parameetri muutmine lennult on sama lihtne kui selle kasutamine sysctl -w clave=valorSiiski on oluline mõista, et need muudatused on ajutised. Nende salvestamiseks pärast taaskäivitamist on oluline konfiguratsioonist varundada /etc/sysctl.conf või failides /etc/sysctl.d/, tavaliselt nummerdatud failide abil (näiteks 10-network.conf, 20-memory.conf, 99-custom.conf), mis määravad nende rakendamise järjekorra.
Mõõda enne puudutamist: võrdlusalused ja süsteemi baasväärtus
Enne kui hakkate nuppe näppima, on tark luua objektiivne toimivuse baasjoon . Ilma eelnevate andmeteta on võimatu teada, kas muudatused on süsteemi parandanud või halvendanud, ja langete klassikalisse lõksu „minu arvates parem“, mis on mõistlike otsuste tegemiseks kasutu.
Süsteemi tasandil on hea mõte koguda protsessori, koormuse, mälu, ketta ja võrgu statistikat mõne minuti jooksul representatiivse koormuse all. Tööriistad, näiteks uptime, mpstat, vmstat, iostat -x o sar -n DEV Need võimaldavad teil näha, kuidas tavaline kernel käitub, kui palju swap-mälu see kasutab, kuidas ketta sisend/väljund reageerib ja kas võrk on küllastunud või raiskab ribalaiust.
Lisaks sellele ülevaatele on oluline käivitada optimeeritava rakenduse jaoks konkreetsed võrdlustestid. Veebiserverites saate kasutada ab (Apache Bench) või sarnased mõõtmise tööriistad päringute arv sekundis, keskmine latentsus ja veadAndmebaasides kasutatakse selliseid utiliite nagu mysqlslap o sysbench Need aitavad hinnata tehingute arvu sekundis ja päringute aega.
Näiteks ilma häälestamiseta on tavaline leida numbreid nagu 500 HTTP-päringut sekundis keskmise reageerimisajaga 200 ms, umbes 250 SQL-päringut sekundis 40 ms latentsusega, võrgu kiirus umbes 500 Mbps ja süsteemi koormus stressi all oma piiri lähedal. Neid numbreid kasutatakse pärast kerneli muudatuste rakendamist selleks, et kontrollida, kas läbilaskevõime mõõdetav suurenemine ja latentsuse vähenemine tegelikult saavutatakse.
Lõpuks dokumenteerige käsud ja tulemused enne muudatuste tegemist. Ajaloo omamine võimaldab teil täpselt võrrelda erinevaid muudatuste partiisid ja aitab teil tuvastada regressioone pärast kerneli värskendamist või uue sysctl profiili juurutamist tootmiskeskkonnas.
Täiustatud mäluseaded: vm.*
Mälu on üks alamsüsteemidest, kus kerneli muudatused on kõige märgatavamad. Server, millel on palju muutmälu, kuid mis on halvasti konfigureeritud, võib lõpuks swap-ruumi tarbetult kasutada, põhjustades... Sisend-/väljundpinged ja drastilised jõudluslangusedSellepärast on parameetrid nagu vm.swappinessSama olulised on ka mustade lehtede suhted või VFS-i vahemälu käitumine.
Parameeter vm.swappiness See kontrollib, kui palju mälulehekülgi kernel swapimiseks saadab. Paljudes distributsioonides on see seatud väärtusele 60, mis on mõeldud segatud töölauakeskkondade jaoks. Andmebaasiserverite või madala latentsusega rakenduste puhul on tavaliselt eelistatav see langetada 10-ni või isegi vähem, mille tulemuseks on tõhusam süsteem. Eelista andmete hoidmist RAM-is ja vähenda vahetamistPärast seda korrigeerimist pole haruldane näha ketta liikluse järsku vähenemist ja rakenduste reageerimist palju väiksema värinaga.
Teine oluline ehituskivi on vm.dirty_ratio y vm.dirty_background_ratioNeed väärtused määravad, kui suur osa mälust saab täita määrdunud lehtedega enne, kui kernel hakkab neid kettale kirjutama. Liiga suured väärtused võivad põhjustada suuri kirjutamispurskeid, millel on tohutu latentsusaeg kõigis rakendustes kettale kirjutamise ajal. Nende protsentide vähendamine vastavalt 15 ja 5-ni annab tavaliselt tulemuseks järjepidevam ja prognoositavam sisend-/väljundmuster.
Seadistamine vm.vfs_cache_pressure See määrab, kui agressiivselt kernel inode'i ja kataloogide vahemälusid puhastab. Vaikimisi väärtus 100 kipub vahemälu kiiremini tühjendama, samas kui umbes 50 väärtused võimaldavad metaandmeid kauem säilitada, suurendades failitoimingute tabamuste määra ja parandades jõudlust. failisüsteemi tajutav jõudlus, mis on võtmetähtsusega serverites, mis haldavad miljoneid väikeseid faile.
Omalt vm.min_free_kbytes Reserveerige minimaalne vaba mälumaht, et süsteem saaks reageerida eraldamise purskedele ilma ootamatute käivitusprobleemideta. Selle suuruse määramine umbes 0,5–1%-le kogu RAM-ist on tavaliselt tõhus turvameede, mis hoiab ära kerneli ruumi otsa saamise äärmise koormuse korral ja kriitiliste protsesside peatamise, parandades seeläbi jõudlust. üldine peremeesorganismi stabiilsus.
Lõpuks väärib tähelepanu ülekulude poliitika: parameetrid, näiteks vm.overcommit_memory y vm.overcommit_ratio Need määravad, kui palju virtuaalmälu protsessidele eraldatakse võrreldes saadaoleva RAM-i ja swap-mäluga. Mõnel juhul (näiteks Redise või teatud andmebaaside puhul) on lubatud agressiivne ülekohustustamine, samas kui teistel juhtudel eelistatakse konservatiivsemat poliitikat, et piirata riski. OOM ja liigselt kahjustatud mälu olukorradKomplekssete juhtumite analüüsimise ja diagnoosimise tehnikate kohta konsulteerige mälu silumine Linuxis.
Täiustatud võrgu optimeerimine: net.* ja TCP/IP
Võrgustiku pinu puhul on häälestamine tootmiskeskkondades ehk kõige märgatavam. Lihtne muudatus ühendusjärjekordades või puhvrites võib teha vahet serveri vahel, mis lämbub kiirusel 500 Mbps, ja serveri vahel, mis... See küllastab gigabiti kergesti.Parameetrid all net.core.* y net.ipv4.* Selles valdkonnas on nad teie parimad liitlased.
Alustuseks mõjutavad sokli puhvri suurused otseselt ühenduse maksimaalset läbilaskevõimet, eriti kui on olemas kõrge latentsusaeg või suure mahutavusega ühendused. net.core.rmem_max y net.core.wmem_max heldete väärtusteni (kümned või sajad megabaiti) ja õigesti defineerida net.ipv4.tcp_rmem y net.ipv4.tcp_wmem (miinimum, vaikeväärtus ja maksimum) võimaldab igal soklil olla liiklusummikute summutamiseks vajalik ruum langemata kunstlikesse piirangutesse, mille on kehtestanud väga konservatiivsed tehaseväärtused.
Teine oluline punkt on ühendusjärjekordade suurus. Parameetrid, näiteks net.core.somaxconn, net.core.netdev_max_backlog y net.ipv4.tcp_max_syn_backlog Need piirangud määravad, mitu ootel ühendust süsteem enne pakettide katkestamist või käepigistuste tagasilükkamist käsitleda saab. Suure liiklusega veebiserverites aitab nende piirangute suurendamine vältida järjekordade üleküllastumist ja koormust drastiliselt vähendada. ühendusvead tippkoormuse ajal.
TCP-ühenduste käitumist saab ka mitmete valikute abil peenhäälestada: luba net.ipv4.tcp_window_scaling Suure ribalaiusega linkidel suurte akende toetamiseks lubage net.ipv4.tcp_sack y net.ipv4.tcp_timestamps kadude ja taasedastuse haldamise parandamiseks või kohandamiseks net.ipv4.tcp_fin_timeout ja juhtimine TIME_WAIT (net.ipv4.tcp_tw_reuse, net.ipv4.tcp_max_tw_buckets), et kontrollida ressursikasutust serverites, millel on miljoneid lühikesi ühendusi minutis.
Samuti on oluline ummikute juhtimise algoritmi valik. Kuigi cubic See jääb paljudes distributsioonides vaikeväärtuseks; see muutub väärtuseks bbr tänapäevastes kernelites (4.9 ja uuemad) net.ipv4.tcp_congestion_control y net.core.default_qdisc=fq See võib keeruliste kadude või latentsusega keskkondades TCP läbilaskevõimet mitmekordistada, saavutades teatud stsenaariumides 2–25-kordseid parandusi võrreldes klassikaliste konfiguratsioonidega, kuid hinnaga mõnevõrra erinev käitumine ülekoormatud võrkudes.
Me ei tohi unustada ohutus- ja töökindluse parameetreid, näiteks net.ipv4.tcp_syncookies, ümbersuunamiste käsitlemine (net.ipv4.conf.all.accept_redirects, send_redirects) või filtreerimine sildades (net.bridge.bridge-nf-call-iptables Kubernetes keskkondades). Õigesti konfigureerituna võimaldavad need teil süsteemi kaitsta levinud rünnakute (SYN-i üleujutus, võltsimine jne) eest, ohverdamata seejuures... kindel võrgu jõudlusReeglite ja tuvastamise praktilise juhendi leiate aadressilt Netfilteri ja Suricata rakendamine.
Failisüsteem, deskriptorid ja globaalsed piirangud: fs.* ja ulimit
Kaasaegsetes serverites on failideskriptori madal piirang kiireim viis süsteemi tipptundidel murda. Kui veebiserver, pöördproksi või andmebaas kohtab klassikalist viga „liiga palju avatud faile”, on see tavaliselt tingitud sellest, et kerneli parameetreid ja kasutajapiiranguid ei skaleeritud tegeliku koormuse jaoks.
Ülemaailmselt fs.file-max See määrab, mitu deskriptorit kernel kokku avatud võib olla. Rakenduste puhul, millel on tuhandeid samaaegseid ühendusi, on tavaline suurendada seda väärtust mitme miljonini koos ... suurendamisega. fs.nr_openmis kehtestab iga protsessi kirjelduste range ülemmäära. Lisaks on vaja kohandusi. /etc/security/limits.conf nii et kasutajatel (või systemd hallatavatel teenustel) on kerneli konfiguratsiooniga kooskõlas olevad pehmed ja kõvad väärtused.
Inotify alamsüsteemi, mida laialdaselt kasutavad IDE-d, veebiarendustööriistad ja failide jälgimissüsteemid, juhivad sellised parameetrid nagu fs.inotify.max_user_watches y fs.inotify.max_user_instancesKui ilmnevad vaatlejatega või protsessidega seotud vead, mis peatavad ketta muudatuste jälgimise, vajate tõenäoliselt Suurendage neid piiranguid, et vältida vaikseid kitsaskohti.
Teine oluline funktsioon on asünkroonne sisend/väljund (AIO), mille globaalne maksimum on defineeritud kui fs.aio-max-nrRakendustes, mis sõltuvad suuresti asünkroonsest sisend-/väljundist (teatud andmebaasimootorid, järjekorrasüsteemid jne), hoiab selle suurendamine ära kerneli AIO-operatsioonide jaoks mõeldud pesade otsa saamise tohutu päringute koormuse korral.
Lisaks neile parameetritele mõjutab ketta alamsüsteemi jõudlust ka I/O ajakava konfigureeritud igal plokkseadmel. SSD-de või NVMe-ketastega süsteemides on tavaliselt soovitatav kasutada kergeid ajastajaid, näiteks none o mq-deadline, samas kui mehaaniliste ketaste puhul võivad muud valikud olla mõistlikud, näiteks bfq olenevalt koormuse tüübist. Reguleerige ajakava läbi /sys/block/<disco>/queue/scheduler ja peenhäälestada valikuid, näiteks järjekorra sügavust (nr_requests) või read_ahead_kb võib märgatavat vahet teha lugemise/kirjutamise latentsus ja läbilaskevõimeSamuti on oluline arvestada, milliseid failisüsteeme ja draivereid kasutatakse; näiteks artiklid teemal NTFSplus Linuxis ja muud süsteemid võivad aidata heterogeensete koormuste kavandamisel.
Lõpuks ei tohiks unustada, et need kerneli piirangud peavad käima käsikäes süsteemi konfiguratsioonidega, näiteks ulimit ja süsteemitud üksused, et tagada teenuste võimalikkus määratletud lisaressursse kasutada ja et need ei oleks blokeeritud piirangud ülemistes kihtides.
Kernel üldiselt, NUMA, protsessori afiinsus ja suured lehed
Lisaks võrgustumisele, mälule ja failisüsteemidele pakub kernel ise mitmesuguseid häälestamisvõimalusi, mis mõjutavad protsesside ajastamist, töökoormuste jaotumist tuumade ja NUMA-sõlmede vahel ning mälu haldamist skaalal. Kaasaegsetes masinates, millel on palju tuumasid ja isegi mitu soklit, määravad need üksikasjad sageli tasakaalustatud serveri ja sellise serveri vahel, kus mõned tuumad on küllastunud, teised aga alakasutatud . Samuti tasub uurida alternatiivseid kerneleid, näiteks Liquorixi kernelit keskkondades, kus on soovitav erinev latentsusprofiil.
Parameetrid, näiteks kernel.pid_max Need määravad süsteemi määratavate protsesside ID-de maksimaalse vahemiku, mis on oluline sõlmede puhul, mis käitavad suurt hulka konteinereid või ajutisi protsesse. Kerneli logimisvalikute kohandamine (kernel.printk) aitab vähendada liigset müra dmesg-is, salvestades samal ajal kriitilisi sündmusi, mis mõjutab kaudselt ka diagnostiline võimekus ja stabiilsus.
Mälu topoloogia osas on parameeter kernel.numa_balancing See kontrollib, mil määral kernel automaatselt lehti NUMA-sõlmede vahel liigutab. Selle keelamine teatud keskkondades võimaldab protsesside ja mälu afiinsuse selgemat haldamist, kasutades selliseid tööriistu nagu numactl et tagada protsessori ja muutmälu nõudvate protsesside püsimine samas sõlmes, vähendades kaugjuurdepääsust tulenev latentsusRiistvara ja tuumade ajastamise vahelise vastastikmõju paremaks mõistmiseks on kasulik vaadata üle ka sellised tehnoloogiad nagu Inteli lõime direktor.
Suured lehed (vm.nr_hugepagesNeed on veel üks võtmekomponent andmebaasisüsteemides või muudes töökoormustes, mis käsitlevad suuri külgneva mälu piirkondi. Sobiva arvu hiiglaslike lehtede reserveerimine (2 MB või isegi 1 GB, olenevalt arhitektuurist) võib vähendada TLB üldkulu ja oluliselt parandada rakenduste jõudlust, mis töötavad palju toiminguid suurte mäluplokkidegaSelle efektiivsuseks peab kerneli konfiguratsioon olema rakenduse endaga kooskõlastatud, nii et see kasutaks seda mälu selgesõnaliselt.
Latentsuse ja ajastamise valdkonnas on olemas ajastamisparameetrid, näiteks kernel.sched_min_granularity_ns, kernel.sched_wakeup_granularity_ns o kernel.sched_migration_cost_nsNeed sätted peenhäälestavad igale ülesandele eraldatud protsessori "tükkide" suurust ja agressiivsust, millega kernel protsesse tuumade vahel liigutab. Väiksemad väärtused esindavad ennetavamat süsteemi, mis kipub pakkuma Parim vastus interaktiivsete ülesannete jaoks mõnikord vähese toorläbilaskevõime hinnaga.
Süsteemides, kus mälu on tundlik ressurss, otsustavad mõned administraatorid kohe pärast installimist ilmnenud vea korral aktiveerida paanikarežiimi (vm.panic_on_oom) ja kehtestada kernel.panic automaatse taaskäivitusajaga. See strateegia, ehkki mõnevõrra drastiline, võib olla kasulik kõrge käideldavusega keskkondades, kus Kiire ja kontrollitud taaskäivitus on eelistatavam hangunud ja ebastabiilsele hostile. tundide jooksul.
Spetsialiseeritud profiilid: veeb, andmebaasid, madal latentsusaeg ja Kubernetes
Ühe imerohu asemel on efektiivsem luua sysctl-profiile, mis on kohandatud erinevat tüüpi töökoormustele: veebiserverid, andmebaasid, konteinerplatvormid või madala latentsusega süsteemid. Nende sätete levitamine failides, näiteks 99-webserver.conf, 99-database.conf o 90-kubernetes.conf aidata säilitada korrastatud ja hõlpsasti versioonitavat konfiguratsiooniSamuti võite kaaluda jõudlusele orienteeritud jaotusi ja väljaandeid, näiteks CachyOS Serveri versioon väga spetsiifiliste keskkondade jaoks.
Veebiserverite (Nginx, Apache, proxyd jne) puhul on oluline toime tulla suure hulga samaaegsete ühendustega, millel on pikad järjekorrad ja reageerimisajad. FIN_WAIT Täppishäälestamise, laiendatud ajutise portide vahemiku ja väga kõrgete deskriptorite piirangute abil on tavaline, et HTTP-päringute arv sekundis tõuseb mõnesajast mitme tuhandeni, vähendades keskmist latentsusaega ja kõrvaldades vigu. küllastunud järjekorrad või täis pordid.
Andmebaasi poolel (MySQL, PostgreSQL ja sarnased) antakse prioriteet minimaalsele swap-kasutusele, määrdunud lehtede kirjutamise peenhäälestamisele ning mootori jaoks sobivatele jagatud mälu ja semafori sätetele. Parameetrid, näiteks kernel.shmmax, kernel.shmall, kernel.sem ja tohutu lehekonfiguratsioon muudab oluliselt tehinguid sekundis ja reageerimisaeg, korrutades jõudlust paljudes stsenaariumides vaikeväärtustega võrreldes kahe või kolmega.
Äärmiselt madala latentsusega rakenduste (kauplemine, online-mängud, reaalajas töötlemine) jaoks lisatakse veelgi spetsiifilisemad sätted: net.ipv4.tcp_low_latency, aeglase käivituse deaktiveerimine pärast tegevusetust, kasutamine tcp_fastopen, hõivatud küsitluse parameetrid (net.core.busy_poll, busy_read) ja paljudel juhtudel läbipaistvate hiiglaslike lehtede deaktiveerimine /sys/kernel/mm/transparent_hugepage/enabledKõige selle eesmärk on vähendada töötlemisjärjekorra ja latentsuse haripunktid kõrgetel protsentiilidel, saavutades P99-s suurepäraseid edusamme.
Konteiner- ja Kubernetes-keskkondades on võrgupinu ja ühenduste jälgimine eriti suure koormuse all. Parameetrid, näiteks net.ipv4.ip_forward, net.bridge.bridge-nf-call-iptables, net.netfilter.nf_conntrack_maxReserveeritud portide kasutamine NodePorti jaoks või ARP-tabelite kohandamine on tavaline sõlmedes, mis haldavad sadu või tuhandeid pode. Nende õige kohandamine hoiab ära probleemid. katkenud ühendused, ajalõpud või tabeli küllastumine conntrackiga.
Lisaks neile spetsiifilistele profiilidele valivad mõned organisatsioonid jõudlusele keskenduva arhiivi, millel on täiustatud turvalisus, kombineerides suuri võrgupuhvreid ja vähendatud vahetusvõimalusi selliste meetmetega nagu tcp_syncookies või ohtlike ümbersuunamiste blokeerimine. Eesmärk on saavutada tasakaalupunkt agressiivse jõudluse ja mõistliku karastamise vahel.
Kerneli profileerimise ja jälgimise tööriistad
Kerneli reguleerimine ilma mõõtmiseta on nagu helimikseri mängimine kinniseotud silmadega. Linux pakub laia tööriistade arsenali, et mõista, mida süsteem tegelikult teeb, alates lihtsatest loenduritest kuni kerneli funktsioonide detailsete jälgimisteni, mis võimaldavad teil konfiguratsioonimuudatusi mõõdetavate efektidega seostada.
Igapäevaste kommunaalteenuste hulka kuuluvad vmstat, iostat, sar, ss, slabtop, htop o pidstatmis pakuvad kiiret teavet protsesside, protsessori, sisend-/väljundvõimsuse, soklite ja vahemälu kasutuse kohta. Koos süsteemilogide ja mõõdikutega, mis on eksporditud Prometheusesse, Grafanasse või collectd-sse, ning ressurssidega, näiteks täiustatud süsteemimonitor LinuxileNeed annavad üsna täieliku pildi sellest, kuidas peremees enne ja pärast iga häälestamist käitub.
Täpsemalt öeldes, sellised tööriistad nagu perf Need võimaldavad profiilida protsessori kasutust funktsiooni tasandil, nii kasutaja kui ka kerneli tasandil, logida sündmusi mõneks sekundiks või minutiks ja seejärel esitada interaktiivse aruande. perf stat, perf record y perf report näete kus protsessori aega tegelikult tarbitakse ja milline osa vastab tuumale, tuvastades näiteks katkestuste tormi või halvasti kohandatud ajakava.
Kui vajate veelgi suuremat detailsust, ftrace Kerneli jälgimise alamsüsteem pakub võimalust aktiveerida konkreetseid jälgijaid (näiteks funktsiooni tracer) ja uurida reaalajas või pärast surma, millised kõned toimuvad. Sobiva jälgija lubamine ja selle sisu analüüsimine. /sys/kernel/debug/tracing/trace see paljastab sulle kernelis endas olevad levialadSee on väga kasulik, kui kõrgetasemelistest mõõdikutest ei piisa.
Paralleelselt on soovitatav rakendada automatiseeritud jälgimisskripte, mis perioodiliselt salvestavad põhiandmed (võrgustatistika, mäluloendurid, avatud failideskriptorite arv jne) vahelduvatesse logidesse. Kui teatud läved on saavutatud (näiteks avatud failideskriptorite arvu ületamisel), saavad need skriptid genereerida teateid e-posti või muude kanalite kaudu, aidates tuvastada ohtlikke trende enne probleemi eskaleerumist.
Lõpuks, pikemate stressitestimise etappide (24 tundi või rohkem) ajal kasutatakse selliseid tööriistu nagu stress-ng koos pideva näitajate kogumisega (via vmstat, iostat, sar) võimaldavad teil hinnata süsteemi stabiilsust uue kerneli konfiguratsiooniga, kontrollides, et pideva koormuse all ei esineks OOM-sündmusi, krahhe, ootamatuid taaskäivitusi ega progresseeruvat jõudluse halvenemist.
Linuxi kerneli optimeerimine sysctl ja muude mehhanismide abil ei ole ühekordne ülesanne, vaid pigem iteratiivne protsess, mis hõlmab tulemuste mõõtmist, parameetrite kohandamist ja kõige hoolikat dokumenteerimist. Selge metoodika, iga töökoormuse tüübi jaoks mõeldud spetsiifiliste profiilide, tugeva profileerimisvahendite komplekti ja range muudatuste kontrolli abil on võimalik saavutada servereid, mis kasutavad oma riistvara täielikult ära, suurendades läbilaskevõimet, vähendades latentsust ja oluliselt suuremat stabiilsust kui üldine tehasekonfiguratsioon.
