Napredna optimizacija jedra Linuxa s sysctl

Informatec Digital » Viri » Napredna optimizacija jedra Linuxa s sysctl

Če že nekaj časa upravljate strežnike Linux, boste sčasoma ugotovili, da je razlika med povprečnim sistemom in tistim, ki se pod veliko obremenitvijo spopada s težavami, v tem, kako dobro ste nastavili jedro. Ne gre le za namestitev več RAM-a ali zmogljivejšega procesorja: številna ozka grla se rešijo s prilagoditvijo nekaj skrbno izbranih parametrov.

Jedro razkriva na stotine možnosti za omrežje, pomnilnik, datotečni sistem in razporejanje procesov, ki jih je mogoče spreminjati sproti. Z orodjem sysctl in nekaj prilagoditev v /procIz strojne opreme je mogoče izvleči največ in doseči nižja latenca, večja prepustnost in boljša stabilnost To velja tako za spletne strežnike in baze podatkov kot tudi za okolja v realnem času in Kubernetes. Vendar je bistveno, da natančno veste, kaj počnete in kako to meriti.

Kaj je sysctl in kako organizira parametre jedra?

Uporabnost sysctl To je prehod za spreminjanje parametrov jedra brez potrebe po ponovnem prevajanju ali ponovnem zagonu, kar omogoča branje in spreminjanje vrednosti med izvajanjem za takojšnje testiranje konfiguracij. Ti parametri so organizirani v nizko hierarhično drevo /proc/sys/in vsak od njih nadzoruje specifično vedenje sistema.

Nastavitve so združene v ločene kategorije, kar olajša natančno določitev, kaj morate prilagoditi, ko imate določeno težavo z zmogljivostjo ali stabilnostjo. Ta struktura vam omogoča, da se na primer osredotočite izključno na omrežje (net.*), pomnilnik (vm.*) ali datotečni sistem (fs.*), ne da bi se izgubili v preostalih možnostih jedra.

Glavne kategorije, ki jih boste našli v /proc/sys/ Med njimi so med drugim:

• jedro.*splošne možnosti jedra (razporejevalnik, PID, sporočila, NUMA itd.).
• vm.*: upravljanje virtualnega pomnilnika, swap, predpomnilniki in pravilniki o preobremenitvi.
• neto.*Omrežni sklad IPv4/IPv6, medpomnilniki TCP/UDP, čakalne vrste, nadzor preobremenjenosti.
• fs.*: omejitve deskriptorjev, inodes, inotify, AIO in VFS vedenja.
• razvoj.*: specifični parametri določenih naprav in gonilnikov.

z sysctl -a Vse razpoložljive parametre lahko naštejete z ukazi, kot je sysctl vm.swappiness o sysctl net.ipv4.tcp_tw_reuse branje specifičnih vrednosti, kar je ključnega pomena za pregled trenutne konfiguracije preden karkoli spremenite. Za iskanje nečesa specifičnega je običajno filtriranje z grep, na primer: sysctl -a | grep tcp.

Spreminjanje parametra sproti je tako preprosto kot uporaba sysctl -w clave=valorVendar je pomembno razumeti, da so te spremembe začasne. Če jih želite shraniti po ponovnem zagonu, je nujno, da varnostno kopirate konfiguracijo na /etc/sysctl.conf ali v datotekah /etc/sysctl.d/, običajno z uporabo oštevilčenih datotek (na primer 10-network.conf, 20-memory.conf, 99-custom.conf), ki določajo vrstni red njihove uporabe.

Izmerite, preden se dotaknete: merila uspešnosti in osnovni sistem

Preden se začnete igrati s številčnicami, je pametno določiti objektivno izhodišče delovanja . Brez predhodnih podatkov je nemogoče vedeti, ali so spremembe izboljšale ali poslabšale sistem, in padli boste v klasično past »meni se zdi bolje«, ki je neuporabna za sprejemanje premišljenih odločitev.

Na ravni celotnega sistema je dobro, da nekaj minut pod reprezentativno obremenitvijo zbirate statistiko procesorja, obremenitve, pomnilnika, diska in omrežja. Orodja, kot so uptime, mpstat, vmstat, iostat -x o sar -n DEV Omogočajo vam, da vidite, kako se obnaša osnovno jedro, koliko swap-a porabi, kako se odziva vhodno/izhodni pogon diska in ali je omrežje prenasičeno ali zapravlja pasovno širino.

Poleg tega pregleda je ključnega pomena, da za aplikacijo, ki jo želite optimizirati, izvedete posebne primerjalne teste. Na spletnih strežnikih lahko uporabite ab (Apache Bench) ali podobna orodja za merjenje zahteve na sekundo, povprečna zakasnitev in napakeV podatkovnih bazah so pripomočki, kot so mysqlslap o sysbench Pomagajo oceniti transakcije na sekundo in čase poizvedb.

Na primer, v scenariju brez optimizacije je običajno najti številke, kot so 500 zahtev HTTP/s s povprečnim odzivnim časom 200 ms, približno 250 poizvedb SQL/s z zakasnitvijo 40 ms, hitrost omrežja približno 500 Mbps in obremenitev sistema, ki se pod obremenitvijo bliža svoji meji. Te številke bodo uporabljene za preverjanje, ali sta po uporabi sprememb jedra dejansko dosežena merljiva povečava prepustnosti in zmanjšanje zakasnitve.

Nazadnje dokumentirajte ukaze in rezultate, preden izvedete kakršne koli spremembe. Zgodovina vam bo omogočila natančno primerjavo različnih serij prilagoditev in vam bo pomagala tudi pri odkrivanju regresij po posodobitvi jedra ali po uvedbi novega profila sysctl v produkciji.

Napredne nastavitve pomnilnika: vm.*

Pomnilnik je eden od podsistemov, kjer so spremembe jedra najbolj opazne. Strežnik z veliko RAM-a, a slabo konfiguriran, lahko po nepotrebnem uporablja swap prostor, kar povzroči ... Konice V/I in drastični padci zmogljivostiZato parametri, kot so vm.swappinessRazmerja umazanih strani ali vedenje predpomnilnika VFS so prav tako pomembna.

Parameter vm.swappiness To nadzoruje, koliko pomnilniških strani jedro pošlje v swap. V mnogih distribucijah je nastavljena na 60, vrednost, namenjena mešanim namiznim okoljem. Za strežnike baz podatkov ali aplikacije z nizko zakasnitvijo je običajno bolje, da jo znižate na 10 ali celo manj, kar ima za posledico učinkovitejši sistem. dati prednost shranjevanju podatkov v RAM-u in zmanjšati zamenjavoNi neobičajno, da se po tej prilagoditvi promet na disku močno zmanjša in da se aplikacije odzivajo z veliko manj tresenja.

Drug temeljni gradnik je vm.dirty_ratio y vm.dirty_background_ratioTe vrednosti določajo, kolikšen odstotek pomnilnika je mogoče zapolniti z umazanimi stranmi, preden jih jedro začne brisati na disk. Pretirano visoke vrednosti lahko povzročijo velike sunke zapisovanja z ogromnimi zakasnitvami za vse aplikacije, ko pride do brisanja. Zmanjšanje teh odstotkov na številke, kot sta 15 oziroma 5, običajno povzroči ... bolj dosleden in predvidljiv vzorec V/I.

Nastavitev vm.vfs_cache_pressure To določa, kako agresivno jedro čisti predpomnilnike inode in imenikov. Privzeta vrednost 100 običajno hitro izbriše predpomnilnik, medtem ko nastavitve okoli 50 omogočajo daljše shranjevanje metapodatkov, kar poveča stopnjo zadetkov za operacije z datotekami in izboljša zmogljivost. zaznana zmogljivost datotečnega sistema, kar je ključnega pomena pri strežnikih, ki obdelujejo milijone majhnih datotek.

Na svoji strani vm.min_free_kbytes Rezervirajte minimalno količino prostega pomnilnika, da zagotovite, da se sistem lahko odzove na izbruhe dodeljevanja, ne da bi pri tem prišlo do nenadnih situacij »out-of-box« (OOB). Določitev velikosti približno od 0,5 % do 1 % celotnega RAM-a je običajno učinkovit varnostni ukrep, ki preprečuje, da bi jedru pri ekstremni obremenitvi zmanjkalo prostora in začelo ustavljati kritične procese, s čimer se izboljša zmogljivost. splošna stabilnost gostitelja.

Končno si pozornost zasluži tudi politika prekomerne potrditev: parametri, kot so vm.overcommit_memory y vm.overcommit_ratio Določajo, koliko virtualnega pomnilnika je dodeljenega procesom glede na razpoložljivi RAM in swap. V nekaterih primerih (na primer pri Redisu ali nekaterih bazah podatkov) je dovoljena agresivna prekomerna dodelitev, v drugih pa je zaželena bolj konzervativna politika za omejitev tveganja. OOM in situacije prekomerno ogroženega spominaZa tehnike analize in diagnosticiranja kompleksnih primerov glejte odpravljanje napak v pomnilniku v Linuxu.

Napredna optimizacija omrežja: net.* in TCP/IP

Omrežni sklad je morda področje, kjer je prilagajanje v produkcijskih okoljih najbolj opazno. Preprosta sprememba čakalnih vrst za povezave ali medpomnilnikov lahko naredi razliko med strežnikom, ki se duši pri 500 Mbps, in strežnikom, ki Z lahkoto nasiči gigabit.Parametri pod net.core.* y net.ipv4.* Na tem področju so vaši najboljši zavezniki.

Za začetek, velikosti medpomnilnikov vtičnic neposredno vplivajo na največjo prepustnost povezave, zlasti kadar so prisotne visoke latence ali povezave z visoko zmogljivostjo. Prilagodite net.core.rmem_max y net.core.wmem_max do velikodušnih vrednosti (desetine ali stotine megabajtov) in jih pravilno definirajte net.ipv4.tcp_rmem y net.ipv4.tcp_wmem (minimalna, privzeta vrednost in maksimalna) omogoča, da ima vsaka vtičnica prostor, potreben za blaženje prometnih zastojev ne da bi se znašli v umetnih omejitvah, ki jih nalagajo zelo konzervativne tovarniške vrednosti.

Druga ključna točka je velikost čakalnih vrst za povezave. Parametri, kot so net.core.somaxconn, net.core.netdev_max_backlog y net.ipv4.tcp_max_syn_backlog Te omejitve določajo, koliko čakajočih povezav lahko sistem obdela, preden zavrne pakete ali rokovanje. Na spletnih strežnikih z veliko prometa lahko povečanje teh omejitev prepreči nasičene čakalne vrste in drastično zmanjša obremenitev. napake v povezavi med koničnimi obremenitvami.

Obnašanje TCP povezav je mogoče natančno nastaviti tudi z množico možnosti: omogoči net.ipv4.tcp_window_scaling Za podporo velikim oknom na povezavah z visoko pasovno širino omogočite net.ipv4.tcp_sack y net.ipv4.tcp_timestamps za izboljšanje upravljanja izgub in ponovnega prenosa ali prilagoditev net.ipv4.tcp_fin_timeout in upravljanje TIME_WAIT (net.ipv4.tcp_tw_reuse, net.ipv4.tcp_max_tw_buckets) za nadzor porabe virov na strežnikih z milijone kratkih povezav na minuto.

Pomembna je tudi izbira algoritma za nadzor preobremenjenosti. Čeprav cubic V mnogih distribucijah ostaja privzeta vrednost; spreminja se v bbr v sodobnih jedrih (4.9 in novejših) z net.ipv4.tcp_congestion_control y net.core.default_qdisc=fq V okoljih s kompleksnimi izgubami ali zakasnitvami lahko pomnoži prepustnost TCP in v nekaterih scenarijih doseže izboljšave od 2 do 25-krat v primerjavi s klasičnimi konfiguracijami, vendar za ceno... nekoliko drugačno vedenje v preobremenjenih omrežjih.

Ne smemo pozabiti na varnostne in zanesljivostne parametre, kot so net.ipv4.tcp_syncookies, obravnava preusmeritev (net.ipv4.conf.all.accept_redirects, send_redirects) ali filtriranje v mostovih (net.bridge.bridge-nf-call-iptables v okoljih Kubernetes). Pravilno konfigurirani vam omogočajo zaščito sistema pred pogostimi napadi (SYN poplava, ponarejanje itd.) brez žrtvovanja solidno delovanje omrežjaZa praktični vodnik o pravilih in odkrivanju si oglejte Implementacija Netfilterja in Suricate.

Datotečni sistem, deskriptorji in globalne omejitve: fs.* in ulimit

Na sodobnih strežnikih je nizka omejitev deskriptorjev datotek najhitrejši način za prekinitev delovanja sistema v času največje obremenitve. Ko spletni strežnik, obratni proxy ali baza podatkov naleti na klasično napako »preveč odprtih datotek«, je to običajno zato, ker parametri jedra in omejitve uporabnikov niso bili prilagojeni dejanski obremenitvi.

Globalno, fs.file-max To določa, koliko deskriptorjev ima lahko jedro skupno odprtih. Za aplikacije s tisoči hkratnih povezav je običajno, da se ta vrednost poveča na nekaj milijonov, skupaj s povečanjem fs.nr_openki določa fiksno zgornjo mejo za deskriptorje na proces. Poleg tega so potrebne prilagoditve. /etc/security/limits.conf tako da imajo uporabniki (ali storitve, ki jih upravlja systemd) mehke in trde vrednosti, skladne s konfiguracijo jedra.

Podsistem inotify, ki ga pogosto uporabljajo IDE, orodja za spletni razvoj in sistemi za spremljanje datotek, nadzirajo parametri, kot so fs.inotify.max_user_watches y fs.inotify.max_user_instancesČe naletite na napake, povezane z opazovalci ali procesi, ki prenehajo spremljati spremembe na disku, boste verjetno morali Povečajte te omejitve, da se izognete tihim ozkim grlom.

Druga pomembna značilnost je asinhroni V/I (AIO), katerega globalni maksimum je definiran z fs.aio-max-nrV aplikacijah, ki se močno zanašajo na asinhroni V/I (določeni mehanizmi baz podatkov, sistemi čakalnih vrst itd.), povečanje prepreči, da bi jedru zmanjkalo rež za operacije AIO pri ogromni obremenitvi zahtev.

Poleg teh parametrov na delovanje diskovnega podsistema vplivajo tudi Razporejevalnik V/I konfigurirano na vsaki blokovni napravi. V sistemih s SSD-ji ali NVMe je običajno priporočljiva uporaba lahkih razporejevalnikov, kot je none o mq-deadline, medtem ko bi bile pri mehanskih diskih morda smiselne druge možnosti, kot na primer bfq odvisno od vrste obremenitve. Prilagodite razporejevalnik prek /sys/block/<disco>/queue/scheduler in natančneje prilagodite možnosti, kot je globina čakalne vrste (nr_requests) ali read_ahead_kb lahko naredi opazno razliko v zakasnitev in prepustnost branja/pisanjaPomembno je tudi upoštevati, kateri datotečni sistemi in gonilniki se uporabljajo; na primer članki o NTFSplus v Linuxu in drugi sistemi lahko pomagajo pri načrtovanju heterogenih obremenitev.

Nenazadnje ne smemo pozabiti, da morajo te omejitve jedra iti z roko v roki s konfiguracijami sistema, kot so tiste od ulimit in enote systemd, da se zagotovi, da lahko storitve dejansko uporabljajo definirane dodatne vire in da jih ne blokirajo omejitve v zgornjih plasteh.

Splošno o jedru, NUMA, afiniteta CPU in ogromne strani

Poleg omrežja, pomnilnika in datotečnih sistemov samo jedro ponuja vrsto možnosti nastavljanja, ki vplivajo na razporejanje procesov, porazdelitev delovnih obremenitev med jedri in vozlišči NUMA ter upravljanje pomnilnika v velikem obsegu. Na sodobnih računalnikih z veliko jedri in celo več vtičnicami te podrobnosti pogosto pomenijo razliko med uravnoteženim strežnikom in strežnikom, pri katerem so nekatera jedra nasičena, druga pa premalo izkoriščena . Prav tako je vredno raziskati alternativna jedra, kot je jedro Liquorix, v okoljih, kjer je zaželen drugačen profil latence.

Parametri, kot so kernel.pid_max Določajo največji obseg ID-jev procesov, ki jih lahko sistem dodeli, kar je pomembno za vozlišča, ki izvajajo veliko število vsebnikov ali kratkotrajnih procesov. Prilagajanje možnosti beleženja jedra (kernel.printk) pomaga zmanjšati prekomerni šum v dmesg, hkrati pa še vedno beleži kritične dogodke, kar posredno vpliva tudi na diagnostične zmogljivosti in stabilnost.

Glede topologije pomnilnika je parameter kernel.numa_balancing Nadzoruje obseg, v katerem jedro samodejno premika strani med vozlišči NUMA. Onemogočanje v določenih okoljih omogoča bolj eksplicitno upravljanje afinitete procesov in pomnilnika z uporabo orodij, kot so numactl da se zagotovi, da procesi, ki intenzivno uporabljajo CPU in RAM, ostanejo na istem vozlišču, s čimer se zmanjša zakasnitev zaradi oddaljenega dostopaZa boljše razumevanje interakcije med strojno opremo in razporejanjem jeder je koristno pregledati tudi tehnologije, kot so Intel Thread Director.

Ogromne strani (vm.nr_hugepagesTo so še ena ključna komponenta v sistemih baz podatkov ali drugih delovnih obremenitvah, ki obdelujejo velika območja sosednjega pomnilnika. Rezerviranje ustreznega števila velikih strani (2 MB ali celo 1 GB, odvisno od arhitekture) lahko zmanjša stroške TLB in znatno izboljša delovanje aplikacij, ki se izvajajo. veliko operacij na velikih blokih pomnilnikaDa bi to delovalo, mora biti konfiguracija jedra usklajena s samo aplikacijo, tako da ta pomnilnik uporablja eksplicitno.

Na področju zakasnitve in razporejanja obstajajo parametri razporejevalnika, kot so kernel.sched_min_granularity_ns, kernel.sched_wakeup_granularity_ns o kernel.sched_migration_cost_nsTe nastavitve natančno prilagodijo velikost "kosov" procesorja, dodeljenih vsaki nalogi, in agresivnost, s katero jedro premika procese med jedri. Manjše vrednosti predstavljajo bolj preprečljiv sistem, ki ponavadi ponuja najboljši odgovor za interaktivne naloge za ceno, včasih, majhne surove prepustnosti.

V sistemih, kjer je pomnilnik občutljiv vir, se nekateri skrbniki odločijo za aktiviranje paničnega načina v primeru napake ob namestitvi (vm.panic_on_oom) in vzpostaviti kernel.panic z avtomatskim časom ponovnega zagona. Ta strategija, čeprav nekoliko drastična, je lahko uporabna v okoljih z visoko razpoložljivostjo, kjer Hiter in nadzorovan ponovni zagon je boljši od zataknjenega in nestabilnega gostitelja. med urami.

Specializirani profili: splet, podatkovne baze, nizka latenca in Kubernetes

Namesto uporabe ene same čarobne kroglice je učinkoviteje ustvariti profile sysctl, prilagojene različnim vrstam delovnih obremenitev: spletnim strežnikom, bazam podatkov, platformam vsebnikov ali sistemom z nizko zakasnitvijo. Distribucija teh nastavitev v datoteke, kot so 99-webserver.conf, 99-database.conf o 90-kubernetes.conf pomagati vzdržujte organizirano in enostavno konfiguracijo za spreminjanje različicUpoštevate lahko tudi distribucije in izdaje, usmerjene v zmogljivost, kot so Strežniška izdaja CachyOS za zelo specifična okolja.

Za spletne strežnike (Nginx, Apache, posredniki itd.) je bistveno, da obvladujejo velike količine hkratnih povezav z velikimi čakalnimi vrstami in odzivnimi časi. FIN_WAIT Z natančnim uglaševanjem, razširjenim obsegom kratkotrajnih vrat in zelo visokimi omejitvami deskriptorjev je običajno, da se število zahtev HTTP na sekundo poveča z nekaj sto na nekaj tisoč, kar zmanjša povprečno zakasnitev in odpravi napake. nasičene čakalne vrste ali polna vrata.

Na strani podatkovnih baz (MySQL, PostgreSQL in podobno) se daje prednost minimalni uporabi swap-a, natančnemu nastavljanju pisanja umazanih strani ter ustreznim nastavitvam skupnega pomnilnika in semaforja za mehanizem. Parametri, kot so kernel.shmmax, kernel.shmall, kernel.sem in konfiguracija ogromnih strani naredi razliko v smislu transakcij na sekundo in odzivnega časa, pri čemer se zmogljivost v mnogih primerih pomnoži z dva ali tri v primerjavi s privzetimi vrednostmi.

Za aplikacije z izjemno nizko latenco (trgovanje, spletne igre, obdelava v realnem času) so dodane še bolj specifične nastavitve: net.ipv4.tcp_low_latency, deaktivacija počasnega zagona po neaktivnosti, uporaba tcp_fastopen, parametri ankete o zasedenosti (net.core.busy_poll, busy_read) in v mnogih primerih deaktivacija prozornih ogromnih strani z /sys/kernel/mm/transparent_hugepage/enabledVse to ima za cilj zmanjšanje Vrhovi čakalne vrste za obdelavo in zakasnitve pri visokih percentilih, s čimer je dosegel izjemne izboljšave v P99.

V kontejnerskih in Kubernetes okoljih sta omrežni sklad in sledenje povezavam še posebej obremenjena. Parametri, kot so net.ipv4.ip_forward, net.bridge.bridge-nf-call-iptables, net.netfilter.nf_conntrack_maxUporaba rezerviranih vrat za NodePort ali prilagajanje tabel ARP sta pogosta v vozliščih, ki obravnavajo stotine ali tisoče podov. Pravilno prilagajanje preprečuje težave. skrajšane povezave, časovne omejitve ali nasičenost tabel s conntrack.

Poleg teh specifičnih profilov se nekatere organizacije odločijo za arhiv, osredotočen na zmogljivost, z izboljšano varnostjo, ki združuje velike omrežne medpomnilnike in zmanjšano možnost zamenjave z ukrepi, kot so tcp_syncookies ali blokiranje nevarnih preusmeritev. Cilj je doseči ravnotežna točka med agresivnim delovanjem in razumnim utrjevanjem.

Orodja za profiliranje in spremljanje jedra

Prilagajanje jedra brez merjenja je kot igranje avdio mešalnika z zavezanimi očmi. Linux ponuja arzenal orodij za razumevanje, kaj sistem dejansko počne, od preprostih števcev do podrobnih sledi funkcij jedra, kar vam omogoča, da spremembe konfiguracije povežete z merljivimi učinki.

Med vsakodnevnimi pripomočki so vmstat, iostat, sar, ss, slabtop, htop o pidstatki zagotavljajo hitre informacije o procesih, CPE-ju, V/I, vtičnicah in uporabi predpomnilnika. V kombinaciji s sistemskimi dnevniki in metrikami, izvoženimi v Prometheus, Grafana ali collectd, in z viri, kot so napredni sistemski nadzornik za LinuxDajejo dokaj popolno sliko o tem, kako se gostitelj obnaša pred in po vsaki nastavitvi.

Če gremo podrobneje, orodja, kot so perf Omogočajo profiliranje uporabe procesorja na ravni funkcij, tako uporabnika kot jedra, beleženje dogodkov za nekaj sekund ali minut in nato zagotavljanje interaktivnega poročila. perf stat, perf record y perf report lahko vidite kje se dejansko porablja čas procesorja in kateri del ustreza jedru, pri čemer se na primer prepozna nevihta prekinitev ali slabo prilagojen razporejevalnik.

Če potrebujete še več podrobnosti, ftrace Sledilni podsistem jedra ponuja možnost aktiviranja določenih sledilnikov (na primer sledilnika funkcij) in preverjanja klicev v realnem času ali naknadno. Omogočanje ustreznega sledilnika in analiza njegove vsebine /sys/kernel/debug/tracing/trace razkriva ti vroče točke znotraj samega jedraTo je zelo uporabno, kadar meritve na visoki ravni niso dovolj.

Vzporedno je priporočljivo implementirati avtomatizirane nadzorne skripte, ki periodično izpisujejo ključne podatke (statistiko omrežja, števce pomnilnika, število odprtih deskriptorjev datotek itd.) v rotirajoče dnevnike. Ko so doseženi določeni pragovi (na primer preseženo določeno število odprtih deskriptorjev datotek), lahko ti skripti ustvarijo opozorila po e-pošti ali drugih kanalih, kar pomaga odkriti nevarne trende, preden se težava stopnjuje.

Končno, v daljših fazah stresnega testiranja (24 ur ali več) se uporabljajo orodja, kot so stress-ng v kombinaciji z nenehnim zbiranjem meritev (prek vmstat, iostat, sar) vam omogočajo, da ocenite stabilnost sistema z novo konfiguracijo jedra in preverite, ali ni dogodkov OOM, zrušitev, nepričakovanih ponovnih zagonov ali postopnega upadanja zmogljivosti pri dolgotrajni obremenitvi.

Optimizacija jedra Linuxa s sysctl in drugimi mehanizmi ni enkratna naloga, temveč iterativni proces, ki vključuje merjenje rezultatov, prilagajanje parametrov in natančno dokumentiranje vsega. Z jasno metodologijo, specifičnimi profili za vsako vrsto delovne obremenitve, robustnim naborom orodij za profiliranje in strogim nadzorom sprememb je mogoče doseči strežnike, ki v celoti izkoriščajo svojo strojno opremo, z večjo prepustnostjo, zmanjšano zakasnitvijo in bistveno večjo stabilnostjo kot generična tovarniška konfiguracija.