Avansert Linux-kjerneoptimalisering med sysctl

Informatec Digital » Ressurser » Avansert Linux-kjerneoptimalisering med sysctl

Hvis du har administrert Linux-servere en stund, vil du etter hvert oppdage at forskjellen mellom et middelmådig system og et som fungerer under tung belastning ligger i hvor godt du har finjustert kjernen. Det handler ikke bare om å installere mer RAM eller en kraftigere CPU: mange flaskehalser løses ved å justere noen få nøye utvalgte parametere.

Kjernen eksponerer hundrevis av nettverks-, minne-, filsystem- og prosessplanleggingsalternativer som kan endres underveis. Med verktøyet sysctl og noen justeringer i /procDet er mulig å få mest mulig ut av maskinvaren og oppnå lavere latens, høyere gjennomstrømning og bedre stabilitet Dette gjelder webservere og databaser, så vel som sanntidsmiljøer og Kubernetes. Det er imidlertid viktig å vite nøyaktig hva du gjør og hvordan du måler det.

Hva er sysctl og hvordan organiserer det kjerneparametere?

Nytte sysctl Det er inngangsporten til å endre kjerneparametere uten å måtte kompilere på nytt eller starte på nytt, slik at lese og endre verdier under kjøring for å teste konfigurasjoner umiddelbart. Disse parameterne er organisert i et lavt hierarkisk tre /proc/sys/og hver av dem styrer en spesifikk oppførsel i systemet.

Innstillingene er gruppert i forskjellige kategorier, noe som gjør det enkelt å finne ut hva du trenger å justere når du opplever et spesifikt ytelses- eller stabilitetsproblem. Denne strukturen lar deg for eksempel fokusere utelukkende på nettverk (net.*), minne (vm.*) eller filsystem (fs.*) uten å gå deg vill i resten av kjernealternativene.

Hovedkategoriene du finner i /proc/sys/ Disse inkluderer blant annet:

• kjerne.*generelle kjernealternativer (planlegger, PID, meldinger, NUMA, osv.).
• vm.*: administrasjon av virtuelt minne, bytte, hurtigbuffer og overcommit-policyer.
• nett.*IPv4/IPv6-nettverksstakk, TCP/UDP-buffere, køer, kontroll av overbelastning.
• fs.*begrensninger for deskriptorer, inoder, inotify, AIO og VFS-oppførsel.
• utvikler*: spesifikke parametere for bestemte enheter og drivere.

med sysctl -a Du kan liste opp alle tilgjengelige parametere, og med kommandoer som sysctl vm.swappiness o sysctl net.ipv4.tcp_tw_reuse lesing av spesifikke verdier, noe som er nøkkelen til revidere gjeldende konfigurasjon før du endrer noe. For å finne noe spesifikt er det vanlig å filtrere med grep, for eksempel: sysctl -a | grep tcp.

Å endre en parameter på farten er like enkelt som å bruke sysctl -w clave=valorDet er imidlertid viktig å forstå at disse endringene er midlertidige. For å lagre dem etter en omstart er det viktig å sikkerhetskopiere konfigurasjonen til /etc/sysctl.conf eller i filer av /etc/sysctl.d/, vanligvis ved bruk av nummererte filer (for eksempel 10-network.conf, 20-memory.conf, 99-custom.conf) som bestemmer rekkefølgen de brukes i.

Mål før du berører: referanseverdier og systemgrunnlinje

Før du begynner å fikle med brytere, er det lurt å etablere en objektiv ytelsesbaseline . Uten forhåndsdata er det umulig å vite om endringene har forbedret eller forverret systemet, og du vil falle i den klassiske «det virker bedre for meg»-fellen, som er ubrukelig for å ta fornuftige beslutninger.

På systemnivå er det lurt å samle inn statistikk over CPU, belastning, minne, disk og nettverk i noen minutter under en representativ belastning. Verktøy som uptime, mpstat, vmstat, iostat -x o sar -n DEV De lar deg se hvordan standardkjernen oppfører seg, hvor mye swap den bruker, hvordan disk I/O reagerer, og om nettverket er mettet eller sløser med båndbredde.

I tillegg til denne oversikten er det viktig å kjøre spesifikke benchmarks for applikasjonen du vil optimalisere. På webservere kan du bruke ab (Apache Bench) eller lignende verktøy for måling forespørsler per sekund, gjennomsnittlig ventetid og feilI databaser brukes verktøy som mysqlslap o sysbench De hjelper med å evaluere transaksjoner per sekund og spørretider.

For eksempel, i et scenario uten finjustering, er det vanlig å finne tall som 500 HTTP-forespørsler/s med en gjennomsnittlig responstid på 200 ms, rundt 250 SQL-spørringer/s med 40 ms latens, en nettverkshastighet på omtrent 500 Mbps og en systembelastning som nærmer seg grensen under stress. Disse tallene vil bli brukt til å bekrefte, etter at kjerneendringer er utført, om en målbar økning i gjennomstrømning og en reduksjon i latens faktisk oppnås.

Til slutt, dokumenter kommandoene og resultatene før du gjør noen endringer. Å ha en historikk vil tillate deg å nøyaktig sammenligne ulike grupper med justeringer og vil også hjelpe deg med å oppdage regresjoner etter en kjerneoppdatering eller etter å ha introdusert en ny sysctl-profil i produksjon.

Avanserte minneinnstillinger: vm.*

Minne er et av delsystemene der kjerneendringer er mest merkbare. En server med mye RAM, men dårlig konfigurert, kan ende opp med å bruke unødvendig swap-plass, noe som forårsaker... I/O-topper og drastiske ytelsesfallDerfor er parametere som vm.swappinessForholdstall for skitne sider eller VFS-hurtigbufferoppførsel er like viktige.

Parameter vm.swappiness Dette kontrollerer hvor mange minnesider kjernen sender for å bytte. I mange distribusjoner er den satt til 60, en verdi beregnet for blandede skrivebordsmiljøer. For databaseservere eller applikasjoner med lav latens er det vanligvis å foretrekke å senke den til 10 eller enda mindre, noe som resulterer i et mer effektivt system. prioriter å lagre data i RAM og reduser bytteDet er ikke uvanlig å se disktrafikken synke kraftig, og applikasjoner reagerer med mye mindre jitter etter denne justeringen.

En annen grunnleggende byggestein er vm.dirty_ratio y vm.dirty_background_ratioDisse verdiene bestemmer hvor stor prosentandel av minnet som kan fylles med skitne sider før kjernen begynner å tømme dem til disk. For høye verdier kan føre til store skriveutbrudd, med enorme latenser for alle applikasjoner når tømmingen skjer. Å redusere disse prosentene til tall som henholdsvis 15 og 5 resulterer vanligvis i en mer konsistent og forutsigbart I/O-mønster.

Innstillingen av vm.vfs_cache_pressure Dette definerer hvor aggressivt kjernen renser inode- og katalogbuffere. En standardverdi på 100 renser vanligvis hurtigbufferen, mens innstillinger rundt 50 lar metadata beholdes lenger, noe som øker treffraten for filoperasjoner og forbedrer ytelsen. den oppfattede ytelsen til filsystemet, noe som er viktig i servere som håndterer millioner av små filer.

For sin del, vm.min_free_kbytes Reserver en minimumsmengde ledig minne for å sikre at systemet kan reagere på allokeringsutbrudd uten å oppleve plutselige «out-of-box»-situasjoner (OOB). Å dimensjonere dette til omtrent 0,5 % til 1 % av total RAM er vanligvis et effektivt sikkerhetstiltak for å forhindre at kjernen går tom for plass under ekstrem belastning og begynner å drepe kritiske prosesser, og dermed forbedre ytelsen. generell vertsstabilitet.

Til slutt fortjener overcommit-policyen oppmerksomhet: parametere som vm.overcommit_memory y vm.overcommit_ratio De bestemmer hvor mye virtuelt minne som allokeres til prosesser i forhold til tilgjengelig RAM og swap. I noen tilfeller (for eksempel med Redis eller visse databaser) er aggressiv overcommitment tillatt, mens i andre tilfeller foretrekkes en mer konservativ policy for å begrense risikoen for OOM og situasjoner med overdrevent kompromittert minneFor teknikker for å analysere og diagnostisere komplekse tilfeller, se minnefeilsøking i Linux.

Avansert nettverksoptimalisering: net.* og TCP/IP

Nettverksstakken er kanskje det området der finjustering er mest merkbar i produksjonsmiljøer. En enkel endring i tilkoblingskøer eller buffere kan utgjøre forskjellen mellom en server som kveles ved 500 Mbps og en som Den metter lett gigabiten.Parametrene under net.core.* y net.ipv4.* På dette området er de dine beste allierte.

For det første påvirker socketbufferstørrelser direkte den maksimale gjennomstrømningen til en tilkobling, spesielt når det er høy latens eller koblinger med høy kapasitet. net.core.rmem_max y net.core.wmem_max til generøse verdier (titalls eller hundrevis av megabyte) og definer riktig net.ipv4.tcp_rmem y net.ipv4.tcp_wmem (minimum, standardverdi og maksimum) lar hver sokkel ha plass som trengs for å dempe trafikkork uten å falle inn i kunstige restriksjoner pålagt av svært konservative fabrikkverdier.

Et annet viktig punkt er størrelsen på tilkoblingskøene. Parametere som net.core.somaxconn, net.core.netdev_max_backlog y net.ipv4.tcp_max_syn_backlog Disse grensene definerer hvor mange ventende tilkoblinger systemet kan håndtere før det slipper pakker eller avviser håndtrykk. På webservere med mye trafikk kan det å øke disse grensene forhindre overfylte køer og redusere belastningen drastisk. Tilkoblingsfeil under toppbelastning.

Oppførselen til TCP-tilkoblinger kan også finjusteres med en rekke alternativer: aktiver net.ipv4.tcp_window_scaling For å støtte store vinduer på lenker med høy båndbredde, aktiver net.ipv4.tcp_sack y net.ipv4.tcp_timestamps for å forbedre håndteringen av tap og retransmisjon, eller justere net.ipv4.tcp_fin_timeout og ledelsen av TIME_WAIT (net.ipv4.tcp_tw_reuse, net.ipv4.tcp_max_tw_buckets) for å kontrollere ressursforbruket på servere med millioner av korte forbindelser per minutt.

Valget av algoritme for kontroll av overbelastning har også betydning. cubic Det er fortsatt standardverdien i mange distribusjoner; endres til bbr i moderne kjerner (4.9 og senere) av net.ipv4.tcp_congestion_control y net.core.default_qdisc=fq Den kan mangedoble TCP-gjennomstrømningen i miljøer med komplekse tap eller latenser, og oppnå forbedringer på mellom 2 og 25 ganger sammenlignet med klassiske konfigurasjoner i visse scenarier, på bekostning av noe annerledes oppførsel i overbelastede nettverk.

Vi må ikke glemme sikkerhets- og pålitelighetsparametere som f.eks. net.ipv4.tcp_syncookies, håndteringen av omdirigeringer (net.ipv4.conf.all.accept_redirects, send_redirects) eller filtrering i broer (net.bridge.bridge-nf-call-iptables i Kubernetes-miljøer). Riktig konfigurert lar de deg beskytte systemet mot vanlige angrep (SYN-flod, forfalskning osv.) uten å ofre en solid nettverksytelseFor en praktisk veiledning om regler og deteksjon, sjekk ut Netfilter- og Suricata-implementering.

Filsystem, deskriptorer og globale grenser: fs.* og ulimit

På moderne servere er en lav filbeskrivelsesgrense den raskeste måten å ødelegge et system i rushtiden. Når en webserver, omvendt proxy eller database støter på den klassiske feilen «for mange åpne filer», skyldes det vanligvis at kjerneparameterne og brukergrensene ikke ble skalert for den faktiske belastningen.

Globalt, fs.file-max Dette spesifiserer hvor mange deskriptorer kjernen kan ha åpne totalt. For applikasjoner med tusenvis av samtidige tilkoblinger er det vanlig å øke denne verdien til flere millioner, sammen med en økning på fs.nr_opensom etablerer det harde taket for beskrivelser per prosess. I tillegg er det behov for justeringer. /etc/security/limits.conf slik at brukere (eller tjenester som administreres av systemd) har myke og harde verdier i samsvar med kjernekonfigurasjonen.

Inotify-undersystemet, som er mye brukt av IDE-er, webutviklingsverktøy og filovervåkingssystemer, styres av parametere som fs.inotify.max_user_watches y fs.inotify.max_user_instancesHvis du støter på feil relatert til overvåkere eller prosesser som slutter å overvåke diskendringer, trenger du sannsynligvis Øk disse grensene for å unngå stille flaskehalser.

En annen relevant funksjon er asynkron I/O (AIO), hvis globale maksimum er definert med fs.aio-max-nrI applikasjoner som er sterkt avhengige av asynkron I/O (visse databasemotorer, køsystemer osv.), forhindrer det å øke den at kjernen går tom for spor for AIO-operasjoner under en massiv forespørselsbelastning.

I tillegg til disse parameterne påvirkes ytelsen til diskundersystemet av I/O-planlegger konfigurert på hver blokkenhet. I systemer med SSD-er eller NVMe anbefales det vanligvis å bruke lette planleggere som none o mq-deadline, mens det på mekaniske skiver kan være andre alternativer som gir mening, for eksempel bfq avhengig av lasttype. Juster planleggeren gjennom /sys/block/<disco>/queue/scheduler og finjuster alternativer som kødybde (nr_requests) eller read_ahead_kb kan gjøre en merkbar forskjell i lese-/skriveforsinkelse og gjennomstrømningDet er også viktig å vurdere hvilke filsystemer og drivere som brukes; for eksempel artikler om NTFSplus på Linux og andre systemer kan hjelpe ved utforming av heterogene laster.

Til slutt bør man ikke glemme at disse kjernegrensene må gå hånd i hånd med systemkonfigurasjoner som de til ulimit og systemd-enheter, for å sikre at tjenester faktisk kan bruke de definerte tilleggsressursene og ikke blokkeres av restriksjoner i øvre lag.

Kjerne generelt, NUMA, CPU-tilhørighet og store sider

Utover nettverk, minne og filsystemer tilbyr selve kjernen en rekke justeringsalternativer som påvirker hvordan prosesser planlegges, hvordan arbeidsbelastninger fordeles på tvers av kjerner og NUMA-noder, og hvordan minne administreres i stor skala. På moderne maskiner med mange kjerner og til og med flere sokler, utgjør disse detaljene ofte forskjellen mellom en balansert server og en med noen kjerner mettet mens andre er underutnyttet . Det er også verdt å utforske alternative kjerner som Liquorix-kjernen i miljøer der en annen latensprofil er ønsket.

Parametere som kernel.pid_max De etablerer det maksimale utvalget av prosess-ID-er som systemet kan tilordne, noe som er relevant for noder som kjører et stort antall containere eller flyktige prosesser. Justering av kjerneloggingsalternativer (kernel.printk) bidrar til å redusere overdreven støy i dmesg samtidig som kritiske hendelser registreres, noe som også indirekte påvirker diagnostisk evne og stabilitet.

Når det gjelder minnetopologi, parameteren kernel.numa_balancing Den kontrollerer i hvilken grad kjernen automatisk flytter sider mellom NUMA-noder. Deaktivering av den i visse miljøer gir mer eksplisitt styring av prosess- og minnetilhørighet, ved hjelp av verktøy som numactl for å sikre at CPU- og RAM-intensive prosesser forblir på samme node, noe som reduserer latens som følge av fjerntilgangFor å bedre forstå samspillet mellom maskinvare og kjerneplanlegging, er det også nyttig å gjennomgå teknologier som Intel Thread Director.

De store sidene (vm.nr_hugepagesDette er en annen nøkkelkomponent i databasesystemer eller andre arbeidsbelastninger som håndterer store områder med sammenhengende minne. Å reservere et passende antall gigantiske sider (2 MB eller til og med 1 GB, avhengig av arkitekturen) kan redusere TLB-overhead og forbedre ytelsen til applikasjoner som kjører betydelig. mange operasjoner på store minneblokkerFor at dette skal være effektivt, må kjernekonfigurasjonen koordineres med selve applikasjonen, slik at den bruker det minnet eksplisitt.

Innenfor latens og planlegging finnes det planleggingsparametere som kernel.sched_min_granularity_ns, kernel.sched_wakeup_granularity_ns o kernel.sched_migration_cost_nsDisse innstillingene finjusterer størrelsen på CPU-"bitene" som er tildelt hver oppgave og aggressiviteten som kjernen flytter prosesser mellom kjerner med. Mindre verdier representerer et mer forutsigbart system, noe som har en tendens til å tilby beste svaret for interaktive oppgaver på bekostning av, noen ganger, litt rå gjennomstrømning.

I systemer der minne er en sensitiv ressurs, velger noen administratorer å aktivere panikkmodus i tilfelle en feil som oppstår før bruk (vm.panic_on_oom) og etablere kernel.panic med en automatisk omstartstid. Denne strategien, selv om den er noe drastisk, kan være nyttig i miljøer med høy tilgjengelighet der En rask og kontrollert omstart er å foretrekke fremfor en fastlåst og ustabil vert. i løpet av timer.

Spesialiserte profiler: web, databaser, lav latens og Kubernetes

I stedet for å bruke én magisk kule, er det mer effektivt å lage sysctl-profiler skreddersydd for ulike typer arbeidsbelastninger: webservere, databaser, containerplattformer eller systemer med lav latens. Distribusjon av disse innstillingene i filer som 99-webserver.conf, 99-database.conf o 90-kubernetes.conf hjelp til opprettholde en organisert og enkel versjonsvennlig konfigurasjonDu kan også vurdere ytelsesorienterte distribusjoner og utgaver som CachyOS Server Edition for svært spesifikke miljøer.

For webservere (Nginx, Apache, proxyer osv.) er det viktigste å håndtere store mengder samtidige tilkoblinger med lange køer og responstider. FIN_WAIT Med finjustering, et utvidet flyktig portområde og svært høye deskriptorgrenser, er det vanlig å gå fra noen få hundre HTTP-forespørsler per sekund til flere tusen, noe som reduserer gjennomsnittlig latens og eliminerer feil. mettede køer eller fulle porter.

På databasesiden (MySQL, PostgreSQL og lignende) prioriteres minimal bruk av swap-data, finjustering av dirty page-skriving og passende innstillinger for delt minne og semafor for motoren. Parametere som kernel.shmmax, kernel.shmall, kernel.sem og den enorme sidekonfigurasjonen utgjør en forskjell når det gjelder transaksjoner per sekund og responstid, og multipliserer ytelsen med to eller tre sammenlignet med standardverdiene i mange scenarier.

For applikasjoner med ekstremt lav latens (handel, online spilling, sanntidsbehandling) legges det til enda mer spesifikke innstillinger: net.ipv4.tcp_low_latency, deaktivering av langsom start etter inaktivitet, bruk av tcp_fastopen, opptatt avstemningsparametere (net.core.busy_poll, busy_read) og i mange tilfeller deaktivering av gjennomsiktige store sider ved /sys/kernel/mm/transparent_hugepage/enabledAlt dette har som mål å redusere behandlingskø og latenstopper ved høye persentiler, og oppnådde spektakulære forbedringer i P99.

I container- og Kubernetes-miljøer er nettverksstakken og tilkoblingssporing under spesielt press. Parametere som net.ipv4.ip_forward, net.bridge.bridge-nf-call-iptables, net.netfilter.nf_conntrack_maxBruk av reserverte porter for NodePort eller justering av ARP-tabeller er vanlig i noder som håndterer hundrevis eller tusenvis av pods. Å justere dem riktig forhindrer problemer. avkortede tilkoblinger, tidsavbrudd eller tabellmetning med conntrack.

Bortsett fra disse spesifikke profilene, velger noen organisasjoner et ytelsesfokusert arkiv med forbedret sikkerhet, som kombinerer store nettverksbuffere og redusert bytte med tiltak som tcp_syncookies eller blokkering av farlige viderekoblinger. Målet er å oppnå en balansepunkt mellom aggressiv ytelse og rimelig herding.

Verktøy for kjerneprofilering og overvåking

Å justere kjernen uten å måle er som å spille en lydmikser med bind for øynene. Linux tilbyr et arsenal av verktøy for å forstå hva systemet faktisk gjør, fra enkle tellere til detaljerte spor av kjernefunksjoner, slik at du kan korrelere konfigurasjonsendringer med målbare effekter.

Blant de daglige verktøyene er vmstat, iostat, sar, ss, slabtop, htop o pidstatsom gir rask informasjon om prosesser, CPU, I/O, sockets og hurtigbufferbruk. Kombinert med systemlogger og målinger eksportert til Prometheus, Grafana eller collectd, og med ressurser som avansert systemmonitor for LinuxDe gir et ganske komplett bilde av hvordan verten oppfører seg før og etter hver stemming.

For å gå mer i detalj, verktøy som perf De tillater profilering av CPU-bruk på funksjonsnivå, både bruker og kjerne, logge hendelser i noen sekunder eller minutter og deretter gi en interaktiv rapport. perf stat, perf record y perf report du kan se hvor CPU-tid faktisk blir brukt og hvilken andel som tilsvarer kjernen, og identifiserer for eksempel en avbruddsstorm eller en dårlig justert planlegger.

Hvis du trenger enda mer granularitet, ftrace Kjernens sporingsundersystem gir muligheten til å aktivere spesifikke sporere (for eksempel funksjonssporeren) og undersøke i sanntid eller etter døden hvilke kall som skjer. Aktivering av riktig sporer og analyse av innholdet /sys/kernel/debug/tracing/trace det åpenbarer for deg hotspots i selve kjernenDette er veldig nyttig når overordnede målinger ikke er nok.

Parallelt anbefales det å implementere automatiserte overvåkingsskript som med jevne mellomrom dumper viktige data (nettverksstatistikk, minnetellere, antall åpne filbeskrivelser osv.) i roterende logger. Når visse terskler er nådd (for eksempel overskridelse av et spesifisert antall åpne filbeskrivelser), kan disse skriptene generere varsler via e-post eller andre kanaler, noe som bidrar til å oppdage farlige trender før et problem eskalerer.

Til slutt, i langvarige stresstestfaser (24 timer eller mer), verktøy som stress-ng kombinert med kontinuerlig innsamling av målinger (via vmstat, iostat, sar) lar deg vurdere systemets stabilitet med den nye kjernekonfigurasjonen, og bekrefte at det ikke er noen OOM-hendelser, krasj, uventede omstarter eller progressive ytelsesforringelser under vedvarende belastning.

Optimalisering av Linux-kjernen med sysctl og andre mekanismer er ikke en engangsoppgave, men snarere en iterativ prosess som involverer måling av resultater, justering av parametere og omhyggelig dokumentasjon av alt. Med en tydelig metodikk, spesifikke profiler for hver type arbeidsbelastning, en robust samling profileringsverktøy og streng endringskontroll er det mulig å oppnå servere som utnytter maskinvaren fullt ut, med økt gjennomstrømning, redusert latens og betydelig større stabilitet enn den generiske fabrikkkonfigurasjonen.