Avansert veiledning for å optimalisere Linux-kjernen og redusere ventetid

Informatec Digital » Ressurser » Avansert veiledning for å optimalisere Linux-kjernen og redusere ventetid

Når vi snakker om ytelse i Linux, ender nesten alt opp med å peke mot samme sted: kjernen som den sentrale komponenten som kontrollerer latens, stabilitet og ressursbrukÅ finjustere det riktig kan utgjøre forskjellen mellom et system som bare «klarer seg» og et som reagerer jevnt på servere, stasjonære datamaskiner, skymiljøer eller til og med i veldig gammel maskinvare.

Denne veiledningen fokuserer på hvordan Optimaliser Linux-kjernen for å minimere ventetid uten at det går på bekostning av sikkerhet eller vedlikeholdbarhetVi vil dekke alt fra grunnleggende arkitekturkonsepter til finjustering med sysctl, kompilering av tilpassede kjerner, bruk av sanntidsoppdateringer, finjustering for nettverk med lav latens (som i EC2), og overvåkings- og benchmarkingteknikker for å måle om det du finjusterer faktisk forbedrer noe.

Linux-kjernearkitektur og viktige punkter for latens

Linux-kjernen fungerer som et mellomlag mellom applikasjoner og maskinvare, og administrerer minne, prosesser, avbrudd, drivere og filsystemer. hans monolittisk, men modulær designTakket være de lastbare modulene kan du fleksibelt aktivere eller deaktivere funksjoner uten å kompilere hele systemet på nytt.

For å forstå hvor latenser kommer fra, er det nøkkelen til å kjenne til flere delsystemer: prosessplanlegger (planlegger)Minnehåndtering og avbruddshåndtering er avgjørende. En dårlig konfigurert planlegger, en aggressiv minnepolicy eller et for stort antall ukontrollerte avbrudd kan føre til langsomme responstider, selv med kraftig maskinvare.

Kjernekonfigurasjon involverer alternativer som CONFIG_PREEMPT, CONFIG_PREEMPT_VOLUNTARY eller CONFIG_SMPDisse faktorene bestemmer i hvilken grad kjernen kan avbrytes for å ivareta mer presserende oppgaver og hvordan den utnytter flerkjernesystemer. Å velge riktig preempsjonsmodell endrer den opplevde latensen betydelig på stasjonære datamaskiner, servere med lav latens eller industrielle systemer.

I moderne servere er maskinvaretopologien også viktig: distribusjon av kjerner, sokkeler, NUMA og hurtigbufferhierarkiFinjustering av CPU-affiniteter og NUMA-policyer (f.eks. å fikse prosesser og minne til samme node) bidrar til å redusere tilgangstider og forbedre trefffrekvensen for hurtigbufferen, noe som er viktig når vi ønsker å minimere jitter og uforutsigbare latenser.

Videre er samspillet mellom CPU-planleggeren og delsystemer av I/O (disk og nettverk) bestemmer gjennomstrømning og ende-til-ende-forsinkelse som applikasjoner ser. Før du berører noe, anbefales det å dokumentere gjeldende tilstand (kjernekonfigurasjon, sysctl, GRUB, lastede moduler) slik at du raskt kan gå tilbake hvis en endring forverrer ytelsen.

Justeringer via sysctl for å forbedre latens og ytelse

grensesnittet sysctl lar deg endre kjerneparametere på farten gjennom /proc/sys, uten å måtte rekompilere. Det er det ideelle utgangspunktet for å begynne å finjustere uten å bli for opphengt i kompileringer ennå.

I nettverksfeltet, parametere som net.core.rmem_max, net.core.wmem_max eller net.ipv4.tcp_congestion_control De påvirker direkte gjennomstrømning, latens og TCP-tilkoblingsoppførsel. Riktig justering av buffere og overbelastningsalgoritmen er avgjørende for webservere med mye trafikk eller skyinstanser med lav latens.

For minne, verdier som vm.swappiness, vm.dirty_ratio, vm.vfs_cache_pressure eller vm.overcommit_memory De lar deg kontrollere hvor mye swap som brukes, hvordan sidebufferen administreres og hvordan virtuelt minne oppfører seg. Å redusere swappiness (for eksempel til 10) bidrar vanligvis til å forhindre at systemet bruker swap for ofte, noe som reduserer forsinkelsestopper for disk I/O.

Hvis du jobber med store databaser eller applikasjoner som bruker enorme mengder delt minne, er det viktig å justere kernel.shmmax, kernel.shmall og det maksimale antallet filer som er åpnet med fs.file-max og fs.nr_openDisse feil dimensjonerte grensene kan forårsake flaskehalser og feil som er vanskelige å diagnostisere under belastning.

Den beste tilnærmingen er å implementere små endringer, måle effekten med overvåkingsverktøy, og først deretter lagre dem i /etc/sysctl.conf eller i /etc/sysctl.d/I containeriserte miljøer må du huske at mange kjerneparametere er globale for verten: uforsiktig endring av dem kan påvirke alle tjenester, så det er nesten obligatorisk å kombinere sysctl med cgroups og navnerom.

Kompilering og vedlikehold av tilpassede kjerner

Kompilering av en tilpasset kjerne er fortsatt et svært kraftig verktøy når du vil redusere ventetid, fjerne unødvendig overhead eller støtte sjelden maskinvareSelv om distribusjoner kommer med ganske allsidige kjerner, utgjør en spesifikk kjerne i visse scenarier hele forskjellen.

Den klassiske arbeidsflyten innebærer å laste ned koden fra kernel.org eller oppdaterte trær som xanmod eller liquorixog bruke verktøy som make menuconfig for å velge alternativer. Ved å lagre .config-filen i ditt eget git-repository, sammen med byggeskript, kan du reprodusere bygg og opprettholde konsistens mellom versjoner.

Hvis du bruker Debian eller derivater, er det veldig praktisk å kompilere «Debian-stil"For å få tak i .deb-pakker av kjernen, overskrifter og tilhørende biblioteker. Dette lar deg distribuere den tilpassede kjernen på flere maskiner ved ganske enkelt å installere pakkene og administrere versjoner med ditt eget repository."

I den virkelige verden gir det ofte mening å kompilere manuelt når du jobber med gammel eller svært begrenset maskinvareEt typisk eksempel er en gammel netbook med en Atom-CPU og 1 GB RAM, der en moderne generisk kjerne, full av unødvendige drivere og serveralternativer, introduserer forsinkelser og ekstra CPU-forbruk som du ikke har råd til.

En vanlig strategi er å starte fra gjeldende kjernekonfigurasjon (for eksempel ved å kopiere /boot-konfigurasjon), og derfra beskjære eller justere. Du kan endre preempsjonsmodellen til «Forutsigbar kjerne (skrivebord med lav latens)"for å prioritere interaktiv skrivebordsrespons, eller legge til spesifikke I/O-planleggere som Bfq i form av en modul for å forbedre opplevelsen på mekaniske plater.

For å unngå å bruke halve livet på å kompilere, er det fornuftig å bygge på en kraftigere maskin og om nødvendig bruke krysskompilering (For eksempel å kompilere en 32-bits kjerne for en Atom fra en x86_64 PC ved ganske enkelt å justere ARCH og de tilhørende verktøykjedene). Deretter trenger du bare å installere .deb-filene på målmaskinen og legge til riktig oppføring i GRUB.

Den vanskelige delen er vedlikehold: det er tilrådelig tester den nye kjernen på noder på Kanariøyene, ha tydelige tilbakerullingsbaner i oppstartsbehandleren og registrere logger og beregninger under overgangen for å oppdage regresjoner i ytelse eller driverkompatibilitet.

Preemption-modeller og PREEMPT_RT-patcher for systemer med lav latens

Kjernens preempsjonsmodell dikterer hvor mye en kjørende oppgave kan avbrytes for å la en oppgave med høyere prioritet ta over, noe som direkte påvirker responsforsinkelseDette inkluderer både standard konfigurasjonsalternativer og sanntidsoppdateringer.

Generiske kjerner tilbyr flere alternativer: ingen preempsjon (mer fokusert på servergjennomstrømning), frivillig preempsjon og forhåndsberegnelig kjerne for skrivebordDette prioriterer den raske responstiden til interaktive applikasjoner. Justering av denne innstillingen kan forbedre ytelsen til stasjonære systemer, lyd eller til og med tungt belastede eldre maskiner betydelig.

Når du trenger å gå et skritt videre, vises følgende: PREEMPT- og PREEMPT_RT-oppdateringerDisse modifikasjonene endrer betydelige deler av kjernen for å minimere ikke-forutsigbare seksjoner. PREEMPT_RT er beregnet på systemer der verst tenkelige latens (ikke bare gjennomsnittet) må være svært lav og forutsigbar: industriell automatisering, profesjonell lyd, telekommunikasjon eller høyfrekvent handel.

Beslutningen om å introdusere PREEMPT_RT bør ikke være basert på mote, men på konkrete målinger av latens og jitterFor det første er det lurt å utnytte planleggerinnstillinger, CPU-affiniteter, sysctl og, hvis aktuelt, konfigurasjoner som dynamisk tickless fullt ut før vedlikehold kompliseres med et RT-tre.

Kompatibilitet må også vurderes: noen Drivere og delsystemer er ikke fullt tilpasset RT og kan kreve spesifikke versjoner eller tilleggsoppdateringer. Den fornuftige tilnærmingen er å utarbeide en vedlikeholdsplan som tydelig beskriver når og hvordan man skal integrere nye versjoner av hovedkjernen med RT-grenen, som synkroniseres med jevne mellomrom, men fortsatt henger noe etter.

CPU-planleggingstuning, tickless drift og kjerneisolering

I tillegg til å velge preemption-modellen, kan du finjustere latensen ved å leke med CPU-planlegging og kjernetimerens oppførsel, spesielt i bedriftsorienterte distribusjoner som RHEL.

Red Hat Enterprise Linux 8, for eksempel, kommer med en kjernefri som standard for inaktive CPUerDette reduserer energiforbruket ved å unngå periodiske avbrudd når kjernen er inaktiv. En modus kan aktiveres for latensfølsomme arbeidsbelastninger. dynamisk tickless i et sett med kjernerslik at bare én CPU ("hjemmekjernen") håndterer de fleste tidsbaserte oppgavene, og resten er så fri som mulig fra periodiske avbrudd.

Denne konfigurasjonen gjøres ved å legge til passende parametere til kjernekommandolinjen i GRUBregenerering av konfigurasjonen, og deretter justering av affiniteten til kritiske kjernetråder, for eksempel RCU-tråder eller tråder bdi-flush, slik at de befinner seg i kjernen som er reservert for vedlikehold.

Denne tilnærmingen kan suppleres med parameteren isolcpusDette gjør at kjerner kan isoleres fra vanlige brukerområdeoppgaver. Det er veldig vanlig i scenarier med lav latens å reservere flere kjerner utelukkende for en kritisk applikasjon, mens resten av systemet (daemoner, avbrudd osv.) håndteres av andre kjerner.

For å bekrefte at dynamisk tickless-modus fungerer, kan enkle tester kjøres med stress eller skript som holder CPU-en opptatt et sekund og observerer med timer-tellere Hvordan antallet avbrudd per sekund faller fra tusenvis til bare én i isolerte kjerner, et tegn på at den periodiske timeren har forsvunnet.

Minne- og lagringshåndtering med fokus på latens

Måten kjernen administrerer minne og disk-I/O på har stor innvirkning på latens oppfattet av applikasjonerspesielt i databaser og tjenester som utfører mange små og hyppige operasjoner.

På minnesiden, reduser vm.bytte minimere bruken av swap (som nesten alltid er mye tregere enn RAM), vm.vfs_cache_pressure Den kontrollerer hvor raskt systemet prøver å tømme inode- og dentry-cachen, og vm.nr_hugepages Det tillater reservering av statiske HugePages for tunge belastninger som databaser eller JVM-er, noe som reduserer TLB-overhead.

I lagring, velg passende I/O-planlegger i henhold til disktype Det er kritisk. På moderne SSD-er er det vanligvis lurt å bruke... none o mq-deadlineMens i mekaniske disker og multitasking-systemer kan algoritmer designet for rettferdighet være bedre, for eksempel BfqI tillegg montering av filsystemer med alternativer som noatime y nodiratime Unngå unødvendige skrivinger hver gang en fil eller katalog åpnes.

Når det gjelder filsystemer, ext4 og XFS Disse er fortsatt de vanligste alternativene: en godt innstilt ext4 er et trygt kort, mens XFS har en tendens til å skalere bedre under høy samtidighet. For svært krevende scenarier kan en kombinasjon av RAID (RAID 10 for databaser, RAID 0 for midlertidig lagring i scratch-modus) med en god scheduler redusere gjennomsnittlig latens og fremfor alt variasjon.

Nettverks- og kjerneoptimalisering for lav latens i Linux og EC2

I nettverksapplikasjoner med høy ytelse avhenger latensen ikke bare av maskinvare eller avstand, men også av hvordan TCP/IP-stakken og selve kjernen er konfigurertDette er spesielt synlig i skyinstanser som Amazon EC2 med ENA-grensesnitt.

Til å begynne med er det viktig å redusere eksterne faktorer som antall nettverkshopp som pakkene utfører: bruk av mer direkte topologier, lastbalanseringer nær backend eller optimaliserte tilgjengelighetssoner reduserer reisetider i millisekunder før de i det hele tatt berører operativsystemet.

Innenfor kjernen innebærer nettverkskonfigurasjon å øke filbeskrivelser (ulimit -n), størrelse mottaks- og sendebuffere med nett.core.rmem_max, nett.core.wmem_max, nett.ipv4.tcp_rmem, nett.ipv4.tcp_wmemog aktiver alternativer som TCP Fast Open for å redusere ventetiden ved etablering av forbindelse.

I AWS ENA-grensesnitt spiller avbruddsmoderering en viktig rolle: som standard grupperer driveren pakker for å redusere antall IRQ-er. Rx-usecs og tx-usecsHvis du vil redusere ventetiden til et absolutt minimum, kan du deaktivere denne modereringen ved å ethtool -CÅ sette rx-usecs og tx-usecs til null reduserer latensen, men øker avbruddsoverhead, så en balanse må finnes avhengig av belastningen.

Den kan også brukes irqbalance for å distribuere IRQ-er over flere kjerner, eller deaktiver den og angi manuelt avbrudds- og nettverkskø-affiniteter (RSS/RPS) til spesifikke kjerner, noe som er veldig typisk i miljøer med ultralav latens eller når man bruker DPDK og hopper over en god del av kjernestakken.

En annen parameter å vurdere er CPU C-tilstanderDype søvntilstander reduserer strømforbruket, men introduserer forsinkelser når kjernen «våkner». For å redusere responsforsinkelsen kan du begrense disse dype tilstandene, akseptere høyere strømforbruk og mindre kapasitet for Turbo Boost på andre kjerner. Hvert miljø har sitt eget optimale punkt mellom wattforbruk og mikrosekunder som er vunnet.

CPU-, tjeneste- og applikasjonsoptimalisering for å redusere ventetid

Foruten selve kjernen, har det omkringliggende miljøet mye å si om den generelle latensen: fra aktive tjenester i systemet ned til den spesifikke konfigurasjonen av hver applikasjon.

En høyytelsesserver bør bare kjøre demoner som virkelig er nødvendigeTjenester som Bluetooth, utskrift eller automatisk nettverksoppdaging (CUPS, Avahi osv.) på backend-maskiner bruker bare CPU, minne og I/O uten å gi noen fordeler. Se gjennom med systemctl list-unit-files --state=enabled Og å deaktivere unødvendige ting er noe av det billigste og mest effektive du kan gjøre.

For å prioritere kritiske prosesser kan du bruke verktøy som Renice, Chrt og TasksetÅ justere en prosess prioritet (renice), gi den sanntidsplanlegging (chrt -f 99), eller tilordne den til bestemte kjerner (oppgavesett) reduserer interferens med andre oppgaver, og forbedrer CPU-forutsigbarheten for databaser, VoIP, strømming eller handelstjenester.

På applikasjonsnivå er finjustering like viktig som kjernefinjustering. Webservere som f.eks. Nginx eller Apache De trenger finjustering av arbeidere, keepalive, mellomlagring og komprimering. Databaser som PostgreSQL eller MySQL De må gjennomgå bufferstørrelser, kontrollpunkter, tilkoblingsbasseng og synkrone skriveparametere for å oppnå lave og stabile latenser.

JVM-ene spiller også en rolle: å velge søppelsamlere som G1GC eller ZGC Justering av heap-størrelser kan redusere pauser som, fra et eksternt perspektiv, fremstår som latens. I virtualiserte og containeriserte miljøer er riktig distribusjon avgjørende. vCPU-, vRAM- og I/O-kvoter Det unngår stille strid som senere fremstår som endeløse køer på disken eller mettet CPU.

Kjerne- og systemovervåking og benchmarking

All denne finjusteringen er nytteløs hvis du ikke måler effekten. Nøkkelen ligger i å kombinere. kontinuerlig overvåking med reproduserbare ytelsestesterslik at hver endring i kjernen eller sysctl kan evalueres med objektive data.

For å se systemets generelle status kan du bruke klassiske verktøy som htop, vmstat, iotop o sarNår du trenger flere detaljer, kommer spesifikke kjerneverktøy inn i bildet, for eksempel ytelse og ftracesom lar deg spore oppførselen til planleggeren, avbrudd og interne anrop med betydelig nøyaktighet.

I produksjonsmiljøer anbefales det å distribuere målesystemer som Prometheus, samlet eller i system med eksportører som eksponerer CPU-tellere, I/O, disk- og nettverkslatenser, prosesskøer osv. Disse dataene, visualisert i Grafana eller lignende verktøy, bidrar til å oppdage regresjoner eller avvik før sluttbrukeren oppdager problemer.

For benchmarking er ideen å gjenskape den faktiske arbeidsmengden og sammenligne «før og etter» av hver endring. Verktøy som sysbench (for CPU-er og databaser), Fio (for plate) eller iperf3 (For nettverk) tillater de konstruksjon av repeterbare scenarier. Dokumentasjon er viktig. kjerneversjoner, sysctl-konfigurasjoner, maskinvare og testparametere slik at sammenligningene gir mening over tid.

I praksis er Linux-kjerneoptimalisering en iterativ prosess: du tester en rekke justeringer, måler resultatene, beholder det som gir reell nytte, og forkaster resten. Med god endringsstyring kan du oversette forbedringene i nye kjerneversjoner (som nyere serier med forbedringer av planlegger, grafikk, strøm eller nettverk) til målbare fordeler for applikasjonene dine, enten det er lokale servere, i skyen eller på krevende arbeidsstasjoner.

Kombinasjonen av kunnskap om kjernearkitektur, finjustering med sysctl, kontrollert kompilering, selektiv bruk av sanntidsoppdateringer og et godt metrikksystem lar en administrator eller et driftsteam oppnå Raskere respons, lavere latens og forbedret generell stabilitet uten å måtte bytte maskinvare ved den minste provokasjon eller kompromittere systemsikkerheten.