Avanceret Linux-kerneoptimering med sysctl

Informatic Digital » Recursos » Avanceret Linux-kerneoptimering med sysctl

Hvis du har administreret Linux-servere i et stykke tid, vil du før eller siden opdage forskellen mellem et almindeligt system og et, der flyver under tung belastning Det handler om, hvordan du har finjusteret din kerne. Det handler ikke kun om at installere mere RAM eller en kraftigere CPU: mange flaskehalse løses ved at finjustere et par omhyggeligt udvalgte parametre.

Kernen eksponerer hundredvis af netværks-, hukommelses-, filsystem- og procesplanlægningsmuligheder, der kan ændres undervejs. Med værktøjet sysctl og nogle justeringer i /procDet er muligt at få mest muligt ud af hardwaren og opnå lavere latenstid, højere gennemløbshastighed og bedre stabilitet Dette gælder både webservere og databaser, såvel som realtidsmiljøer og Kubernetes. Det er dog vigtigt at vide præcis, hvad man laver, og hvordan man måler det.

Hvad er sysctl, og hvordan organiserer det kerneparametre?

Hjælpeprogram sysctl Det er porten til at ændre kerneparametre uden at skulle rekompilere eller genstarte, hvilket giver mulighed for læse og ændre værdier under kørsel for at teste konfigurationer med det samme. Disse parametre er organiseret i et lavt hierarkisk træ /proc/sys/og hver enkelt styrer en specifik systemadfærd.

Indstillingerne er grupperet i forskellige kategorier, hvilket gør det nemt at finde ud af, hvad du skal justere, når du har et meget specifikt problem med ydeevne eller stabilitet. Takket være denne struktur kan du f.eks. fokusere kun på netværk (net.*), hukommelse (vm.*) eller filsystem (fs.*) uden at fare vild i resten af ​​kerneindstillingerne.

Hovedkategorierne finder du i /proc/sys/ Disse omfatter blandt andet:

• kerne.*generelle kerneindstillinger (scheduler, PID, meddelelser, NUMA osv.).
• vm.*: administration af virtuel hukommelse, swap, caches og overcommit-politikker.
• net.*IPv4/IPv6-netværksstak, TCP/UDP-buffere, køer, kontrol af overbelastning.
• fs.*: begrænsninger for deskriptorer, inoder, inotify, AIO og VFS-adfærd.
• udvikler*specifikke parametre for bestemte enheder og drivere.

med sysctl -a Du kan liste alle tilgængelige parametre, og med kommandoer som sysctl vm.swappiness o sysctl net.ipv4.tcp_tw_reuse aflæsning af specifikke værdier, hvilket er nøglen til revider den aktuelle konfiguration før du ændrer noget. For at finde noget specifikt er det almindeligt at filtrere med grepfor eksempel: sysctl -a | grep tcp.

Det er lige så simpelt at ændre en parameter undervejs som at bruge sysctl -w clave=valorDet er dog vigtigt at forstå, at disse ændringer er midlertidige. For at gemme dem efter en genstart er det vigtigt at sikkerhedskopiere konfigurationen til /etc/sysctl.conf eller i filer fra /etc/sysctl.d/, normalt ved hjælp af nummererede filer (f.eks. 10-network.conf, 20-memory.conf, 99-custom.conf) der bestemmer rækkefølgen, de anvendes i.

Mål før du rører: benchmarks og systembaseline

Før du begynder at dreje på hjulene som en gal, er det en god idé at etablere en objektiv præstationsgrundlinjeUden forudgående data er det umuligt at vide, om ændringerne har forbedret eller forværret systemet, og man vil falde i den klassiske "det ser ud til at gå bedre", hvilket er ubrugeligt til at træffe seriøse beslutninger.

På systemniveau er det en god idé at indsamle CPU-, belastnings-, hukommelses-, disk- og netværksstatistikker i et par minutter under en repræsentativ belastning. Værktøjer som f.eks. uptime, mpstat, vmstat, iostat -x o sar -n DEV De giver dig mulighed for at se, hvordan standardkernen opfører sig, hvor meget swap den bruger, hvordan disk I/O reagerer, og om netværket er mættet eller spilder båndbredde.

Ud over den oversigt er det afgørende at køre specifikke benchmarks for den applikation, du vil optimere. På webservere kan du bruge ab (Apache Bench) eller lignende værktøjer til måling anmodninger pr. sekund, gennemsnitlig latenstid og fejlI databaser bruges værktøjer som f.eks. mysqlslap o sysbench De hjælper med at evaluere transaktioner pr. sekund og forespørgselstider.

For eksempel, i et scenarie uden tuning, er det almindeligt at finde tal som 500 HTTP-anmodninger/s med en gennemsnitlig svartid på 200 ms, omkring 250 SQL-forespørgsler/s med 40 ms latenstid, en netværkshastighed på cirka 500 Mbps og en systembelastning, der nærmer sig sin grænse under stress. Disse tal vil blive brugt til at verificere, efter at kerneændringerne er implementeret, om der rent faktisk opnås en betydelig forbedring. målbar stigning i gennemløbshastighed og et fald i latenstid.

Dokumentér endelig kommandoerne og de opnåede resultater, før du rører ved noget. At have en historik giver dig mulighed for at sammenligne forskellige sæt justeringer nøje, og det vil også være nyttigt for Registrer regressioner efter en kerneopdatering eller efter introduktion af en ny sysctl-profil i produktion.

Avancerede hukommelsesindstillinger: vm.*

Hukommelse er et af de undersystemer, hvor kerneændringer er mest mærkbare. En server med masser af RAM, men dårligt konfigureret, kan ende med at bruge swap-plads unødvendigt, hvilket forårsager... I/O-stigninger og drastiske fald i ydeevnenDerfor er parametre som vm.swappinessForholdsgrader for snavsede sider eller VFS-cacheadfærd er lige så vigtige.

Parameter vm.swappiness Dette styrer, hvor mange hukommelsessider kernen sender til swap. I mange distributioner er den indstillet til 60, en værdi beregnet til blandede skrivebordsmiljøer. For databaseservere eller applikationer med lav latenstid er det normalt at foretrække at sænke den til 10 eller endnu mindre, hvilket resulterer i et mere effektivt system. Prioriter at gemme data i RAM og reducer swappingDet er ikke ualmindeligt at se disktrafikken falde kraftigt, og at applikationer reagerer med meget mindre jitter efter denne justering.

En anden grundlæggende byggesten er vm.dirty_ratio y vm.dirty_background_ratioDisse værdier bestemmer, hvor stor en procentdel af hukommelsen der kan fyldes med snavsede sider, før kernen begynder at skylle dem ned på disken. For høje værdier kan føre til store mængder skrivninger med enorme latenser for alle applikationer, når skylleprocessen finder sted. At reducere disse procenter til henholdsvis 15 og 5 resulterer typisk i en mere konsistent og forudsigeligt I/O-mønster.

Indstillingen af vm.vfs_cache_pressure Dette definerer, hvor aggressivt kernen renser inode- og mappecacher. En standardværdi på 100 har en tendens til at rense cachen hurtigt, mens indstillinger omkring 50 tillader, at metadata bevares længere, hvilket øger hitraten for filoperationer og forbedrer ydeevnen. filsystemets opfattede ydeevne, noget centralt på servere, der håndterer millioner af små filer.

For sin del, vm.min_free_kbytes Reserver en minimumsmængde ledig hukommelse for at sikre, at systemet kan reagere på allokeringsudbrud uden at opleve pludselige "out-of-box"-situationer (OOB). At dimensionere dette til cirka 0,5 % til 1 % af den samlede RAM er normalt en effektiv sikkerhedsforanstaltning for at forhindre, at kernen løber tør for plads under ekstrem belastning og begynder at dræbe kritiske processer, hvilket forbedrer ydeevnen. den samlede værtstabilitet.

Endelig fortjener overcommit-politikken opmærksomhed: parametre som f.eks. vm.overcommit_memory y vm.overcommit_ratio De bestemmer, hvor meget virtuel hukommelse der allokeres til processer i forhold til tilgængelig RAM og swap. I nogle tilfælde (for eksempel med Redis eller visse databaser) er aggressiv overcommitment tilladt, mens i andre tilfælde foretrækkes en mere konservativ politik for at begrænse risikoen for OOM og situationer med overdrevent kompromitteret hukommelseFor teknikker til analyse og diagnosticering af komplekse tilfælde, se hukommelsesfejlfinding i Linux.

Avanceret netværksoptimering: net.* og TCP/IP

Netværksstakken er måske det område, hvor finjustering er mest mærkbar i produktionsmiljøer. En simpel ændring i forbindelseskøer eller buffere kan gøre forskellen mellem en server, der hakker ved 500 Mbps, og en, der Det mætter nemt gigabitten.Parametrene under net.core.* y net.ipv4.* På dette område er de dine bedste allierede.

Til at begynde med påvirker socketbufferstørrelser direkte den maksimale gennemløbshastighed for en forbindelse, især når der er høje latenser eller links med høj kapacitet. net.core.rmem_max y net.core.wmem_max til generøse værdier (tiere eller hundreder af megabyte) og definere korrekt net.ipv4.tcp_rmem y net.ipv4.tcp_wmem (minimum, standardværdi og maksimum) tillader hver sokkel at have plads nødvendig for at afbøde trafikpropper uden at falde i kunstige restriktioner pålagt af meget konservative fabriksværdier.

Et andet vigtigt punkt er størrelsen på forbindelseskøerne. Parametre som f.eks. net.core.somaxconn, net.core.netdev_max_backlog y net.ipv4.tcp_max_syn_backlog Disse grænser definerer, hvor mange ventende forbindelser systemet kan håndtere, før pakker droppes eller handshakes afvises. På webservere med høj trafik kan en forøgelse af disse grænser forhindre overfyldte køer og drastisk reducere belastningen. forbindelsesfejl under spidsbelastninger.

TCP-forbindelsers opførsel kan også finjusteres med en lang række muligheder: aktiver net.ipv4.tcp_window_scaling For at understøtte store vinduer på links med høj båndbredde, skal du aktivere net.ipv4.tcp_sack y net.ipv4.tcp_timestamps for at forbedre håndteringen af ​​tab og retransmission, eller justere net.ipv4.tcp_fin_timeout og ledelsen af TIME_WAIT (net.ipv4.tcp_tw_reuse, net.ipv4.tcp_max_tw_buckets) for at kontrollere ressourceforbruget på servere med millioner af korte forbindelser i minuttet.

Valget af algoritme til kontrol af overbelastning har også betydning. cubic Det forbliver standardværdien i mange distributioner; ændres til bbr i moderne kerner (4.9 og senere) af net.ipv4.tcp_congestion_control y net.core.default_qdisc=fq Den kan mangedoble TCP-gennemstrømningen i miljøer med komplekse tab eller latenser og opnå forbedringer på mellem 2 og 25 gange sammenlignet med klassiske konfigurationer i visse scenarier, på bekostning af noget anderledes adfærd i overbelastede netværk.

Vi må ikke glemme sikkerheds- og pålidelighedsparametre som f.eks. net.ipv4.tcp_syncookies, håndteringen af ​​omdirigeringer (net.ipv4.conf.all.accept_redirects, send_redirects) eller filtrering i broer (net.bridge.bridge-nf-call-iptables i Kubernetes-miljøer). Korrekt konfigurerede giver de dig mulighed for at beskytte systemet mod almindelige angreb (SYN flood, spoofing osv.) uden at ofre en solid netværksydelseFor en praktisk vejledning om regler og detektion, se Netfilter og Suricata implementering.

Filsystem, deskriptorer og globale grænser: fs.* og ulimit

På moderne servere er en lav filbeskrivelsesgrænse den hurtigste måde at ødelægge et system i spidsbelastningsperioder. Når en webserver, reverse proxy eller database støder på den klassiske fejl "for mange åbne filer", skyldes det normalt... Kerneparametrene og brugergrænserne var ikke dimensioneret for den faktiske belastning.

Globalt fs.file-max Dette angiver, hvor mange deskriptorer kernen kan have åbne i alt. For applikationer med tusindvis af samtidige forbindelser er det almindeligt at øge denne værdi til flere millioner, sammen med en stigning på fs.nr_opensom fastlægger det faste loft for deskriptorer pr. proces. Derudover er der behov for justeringer. /etc/security/limits.conf så brugere (eller tjenester administreret af systemd) har bløde og hårde værdier i overensstemmelse med kernekonfigurationen.

Inotify-undersystemet, der er meget brugt af IDE'er, webudviklingsværktøjer og filovervågningssystemer, styres af parametre som f.eks. fs.inotify.max_user_watches y fs.inotify.max_user_instancesHvis du støder på fejl relateret til overvågere eller processer, der stopper med at overvåge diskændringer, har du sandsynligvis brug for Øg disse grænser for at undgå stille flaskehalse.

En anden relevant funktion er asynkron I/O (AIO), hvis globale maksimum er defineret med fs.aio-max-nrI applikationer, der er stærkt afhængige af asynkron I/O (visse databasemotorer, køsystemer osv.), forhindrer en forøgelse af den kernen i at løbe tør for slots til AIO-operationer under en massiv anmodningsbelastning.

Ud over disse parametre påvirkes diskundersystemets ydeevne af I/O-planlægger konfigureret på hver blokenhed. I systemer med SSD'er eller NVMe anbefales det normalt at bruge lette planlæggere som f.eks. none o mq-deadline, mens andre muligheder på mekaniske diske kan give mening, såsom bfq afhængigt af belastningstypen. Juster planlæggeren via /sys/block/<disco>/queue/scheduler og finjuster muligheder såsom kødybde (nr_requests) eller read_ahead_kb kan gøre en mærkbar forskel i læse-/skriveforsinkelse og gennemløbDet er også vigtigt at overveje, hvilke filsystemer og drivere der bruges; for eksempel artikler om NTFSplus på Linux og andre systemer kan hjælpe ved design af heterogene belastninger.

Endelig bør det ikke glemmes, at disse kernebegrænsninger skal gå hånd i hånd med systemkonfigurationer som f.eks. ulimit og systemd-enheder, for at sikre at tjenester rent faktisk kan bruge de definerede yderligere ressourcer og ikke blokeres af restriktioner i de øvre lag.

Kernel generelt, NUMA, CPU-affinitet og store sider

Ud over netværk, hukommelse og filsystemer tilbyder selve kernen en række justeringsmuligheder, der påvirker, hvordan processer planlægges, hvordan arbejdsbelastninger fordeles på tværs af kerner og NUMA-noder, og hvordan hukommelse administreres i stor skala. På moderne maskiner med mange kerner og endda flere sockets er disse detaljer ofte forskellen mellem en afbalanceret server og en med... Nogle kerner er mættede, mens andre er underudnyttedeDet er også værd at prøve alternative kerner som f.eks. kerne Liquorix i miljøer, hvor der søges en anden latensprofil.

Parametre som f.eks. kernel.pid_max De fastlægger det maksimale interval af proces-ID'er, som systemet kan tildele, hvilket er relevant for noder, der kører et stort antal containere eller kortvarige processer. Justering af kernelogningsindstillinger (kernel.printk) hjælper med at reducere overdreven støj i dmesg, samtidig med at kritiske hændelser stadig registreres, hvilket også indirekte påvirker diagnostisk kapacitet og stabilitet.

Med hensyn til hukommelsestopologi, parameteren kernel.numa_balancing Den styrer, i hvilket omfang kernen automatisk flytter sider mellem NUMA-noder. Deaktivering af den i visse miljøer giver mulighed for mere eksplicit styring af proces- og hukommelsesaffinitet ved hjælp af værktøjer som f.eks. numactl for at sikre, at CPU- og RAM-intensive processer forbliver på den samme node, hvilket reducerer latenstid som følge af fjernadgangFor bedre at forstå samspillet mellem hardware og kerneplanlægning er det også nyttigt at gennemgå teknologier som f.eks. Intel Thread Director.

De store sider (vm.nr_hugepagesDisse er en anden nøglekomponent i databasesystemer eller andre arbejdsbelastninger, der håndterer store områder af sammenhængende hukommelse. Reservation af et passende antal gigantiske sider (2 MB eller endda 1 GB, afhængigt af arkitekturen) kan reducere TLB-overhead og forbedre ydeevnen betydeligt for applikationer, der kører mange operationer på store hukommelsesblokkeFor at dette kan være effektivt, skal kernekonfigurationen koordineres med selve applikationen, så den bruger den pågældende hukommelse eksplicit.

Inden for latenstid og planlægning er der planlægningsparametre som f.eks. kernel.sched_min_granularity_ns, kernel.sched_wakeup_granularity_ns o kernel.sched_migration_cost_nsDisse indstillinger finjusterer størrelsen på de CPU-"chunks", der er allokeret til hver opgave, og den aggressivitet, hvormed kernen flytter processer mellem kerner. Mindre værdier repræsenterer et mere prægetablet system, hvilket har tendens til at tilbyde bedste svar til interaktive opgaver på bekostning, nogle gange, af en lille rå gennemstrømning.

I systemer, hvor hukommelse er en følsom ressource, vælger nogle administratorer at aktivere paniktilstand i tilfælde af en standardfejl (vm.panic_on_oom) og etablere kernel.panic med en automatisk genstartstidspunkt. Denne strategi, omend noget drastisk, kan være nyttig i miljøer med høj tilgængelighed, hvor En hurtig og kontrolleret genstart er at foretrække frem for en hængende og ustabil vært. i timevis.

Specialiserede profiler: web, databaser, lav latenstid og Kubernetes

I stedet for at anvende en enkelt magisk kugle er det mere effektivt at oprette sysctl-profiler, der er skræddersyet til forskellige typer arbejdsbelastninger: webservere, databaser, containerplatforme eller systemer med lav latenstid. Distribuering af disse indstillinger i filer som f.eks. 99-webserver.conf, 99-database.conf o 90-kubernetes.conf hjælp til opretholde en organiseret og brugervenlig konfigurationDu kan også overveje performanceorienterede distributioner og udgaver som f.eks. CachyOS Server-udgave til meget specifikke miljøer.

For webservere (Nginx, Apache, proxyer osv.) er det afgørende at håndtere store mængder samtidige forbindelser med lange køer og svartider. FIN_WAIT Med finjustering, et udvidet kortvarigt portinterval og meget høje deskriptorgrænser er det almindeligt at gå fra et par hundrede HTTP-anmodninger pr. sekund til flere tusinde, hvilket reducerer den gennemsnitlige latenstid og eliminerer fejl. mættede køer eller fulde porte.

På databasesiden (MySQL, PostgreSQL og lignende) prioriteres minimal brug af swaps, finjustering af dirty page-skrivning og passende delt hukommelse og semaforindstillinger for motoren. Parametre som f.eks. kernel.shmmax, kernel.shmall, kernel.sem og den enorme sidekonfiguration gør en forskel med hensyn til transaktioner pr. sekund og svartid, hvilket ganger ydeevnen med to eller tre sammenlignet med standardværdierne i mange scenarier.

For applikationer med ekstremt lav latenstid (handel, online spil, realtidsbehandling) tilføjes endnu mere specifikke indstillinger: net.ipv4.tcp_low_latency, deaktivering af langsom start efter inaktivitet, brug af tcp_fastopen, travle afstemningsparametre (net.core.busy_poll, busy_read) og i mange tilfælde deaktivering af gennemsigtige store sider ved /sys/kernel/mm/transparent_hugepage/enabledAlt dette har til formål at reducere behandlingskø og latenstid topper ved høje percentilerog opnåede spektakulære forbedringer i P99.

I container- og Kubernetes-miljøer er netværksstakken og forbindelsessporing under særligt pres. Parametre som f.eks. net.ipv4.ip_forward, net.bridge.bridge-nf-call-iptables, net.netfilter.nf_conntrack_maxBrugen af ​​reserverede porte til NodePort eller justering af ARP-tabeller er almindeligt i noder, der håndterer hundredvis eller tusindvis af pods. Korrekt justering af dem forhindrer problemer. afkortede forbindelser, timeouts eller tabelmætning med conntrack.

Udover disse specifikke profiler vælger nogle organisationer et performancefokuseret arkiv med forbedret sikkerhed, der kombinerer store netværksbuffere og reduceret swappiness med foranstaltninger som f.eks. tcp_syncookies eller blokering af farlige omdirigeringer. Målet er at opnå en balancepunkt mellem aggressiv ydeevne og rimelig hærdning.

Værktøjer til kerneprofilering og overvågning

At finjustere kernen uden at måle er som at spille en lydmixer med bind for øjnene. Linux tilbyder et arsenal af værktøjer til at forstå, hvad systemet rent faktisk laver, fra simple tællere til detaljerede spor af kernefunktioner, så du kan korreler konfigurationsændringer med målbare effekter.

Blandt de daglige forsyninger er vmstat, iostat, sar, ss, slabtop, htop o pidstatsom giver hurtig information om processer, CPU, I/O, sockets og cacheforbrug. Kombineret med systemlogfiler og metrikker eksporteret til Prometheus, Grafana eller Collectd, og med ressourcer som f.eks. avanceret systemovervågning til LinuxDe giver et ret fuldstændigt billede af, hvordan værten opfører sig før og efter hver tuning.

For at gå mere i detaljer, værktøjer som f.eks. perf De tillader profilering af CPU-forbrug på funktionsniveau, både bruger og kerne, logføring af hændelser i et par sekunder eller minutter og derefter levering af en interaktiv rapport. perf stat, perf record y perf report kan du se hvor CPU-tid rent faktisk forbruges, og hvilken del svarer til kernen, for eksempel identificere en afbrydelsesstorm eller en dårligt justeret planlægningsplan.

Hvis du har brug for endnu mere granularitet, ftrace Kernens sporingsundersystem giver mulighed for at aktivere specifikke sporingssystemer (f.eks. funktionssporingssystemet) og undersøge i realtid eller efter døden, hvilke kald der forekommer. Aktivering af det relevante sporingssystem og analyse af dets indhold /sys/kernel/debug/tracing/trace det afslører for dig hotspots i selve kernenDette er meget nyttigt, når overordnede målinger ikke er tilstrækkelige.

Parallelt hermed anbefales det at implementere automatiserede overvågningsscripts, der med jævne mellemrum dumper nøgledata (netværksstatistik, hukommelsestællere, antal åbne filbeskrivelser osv.) i roterende logfiler. Når bestemte tærskler er nået (f.eks. overskridelse af et bestemt antal åbne filbeskrivelser), kan disse scripts generere advarsler via e-mail eller andre kanaler, hvilket hjælper med at... opdage farlige tendenser, før problemet eksploderer.

Endelig, i længerevarende stresstestfaser (24 timer eller mere), værktøjer som f.eks. stress-ng kombineret med den løbende indsamling af målinger (via vmstat, iostat, sar) giver dig mulighed for at vurdere systemets stabilitet med den nye kernekonfiguration og verificere, at der ikke er nogen OOM-hændelser, nedbrud, uventede genstarter eller progressive ydeevneforringelser under vedvarende belastning.

Optimering af Linux-kernen med sysctl og andre mekanismer er ikke en engangsopgave, men snarere en iterativ proces, hvor resultater måles, parametre justeres, og alt dokumenteres grundigt. Med en klar metode, specifikke profiler for hver type arbejdsbyrde, en god række profileringsværktøjer og streng ændringskontrol er det muligt at opnå servere, der får mest muligt ud af deres hardware, med Højere gennemløbshastighed, lavere latenstid og langt bedre stabilitet i forhold til det, der tilbydes af den generiske fabrikskonfiguration.