Avancerad Linuxkärnoptimering med sysctl

Informatec Digital » Resurser » Avancerad Linuxkärnoptimering med sysctl

Om du har hanterat Linux-servrar ett tag kommer du så småningom att upptäcka att skillnaden mellan ett mediokert system och ett som fungerar bra under tung belastning ligger i hur väl du har finjusterat kärnan. Det handlar inte bara om att installera mer RAM eller en kraftfullare processor: många flaskhalsar löses genom att justera några noggrant utvalda parametrar.

Kärnan exponerar hundratals alternativ för nätverk, minne, filsystem och processschemaläggning som kan ändras direkt. Med verktyget sysctl och vissa justeringar i /procDet är möjligt att få ut det mesta av hårdvaran och uppnå lägre latens, högre genomströmning och bättre stabilitet Detta gäller webbservrar och databaser, såväl som realtidsmiljöer och Kubernetes. Det är dock viktigt att veta exakt vad man gör och hur man mäter det.

Vad är sysctl och hur organiserar det kärnparametrar?

Verktyg sysctl Det är inkörsporten till att ändra kärnparametrar utan att behöva kompilera om eller starta om, vilket gör att läsa och ändra värden vid körning för att testa konfigurationer direkt. Dessa parametrar är organiserade i ett lågt hierarkiskt träd /proc/sys/och var och en styr ett specifikt beteende hos systemet.

Inställningarna är grupperade i distinkta kategorier, vilket gör det enkelt att identifiera vad du behöver justera när du upplever ett specifikt prestanda- eller stabilitetsproblem. Den här strukturen låter dig till exempel fokusera enbart på nätverk (net.*), minne (vm.*) eller filsystem (fs.*) utan att gå vilse i resten av kärninställningarna.

Huvudkategorierna hittar du i /proc/sys/ Dessa inkluderar bland annat:

• kärna.*allmänna kärninställningar (schemaläggare, PID, meddelanden, NUMA, etc.).
• vm.*: hantering av virtuellt minne, swap, cacheminne och overcommit-policyer.
• netto.*IPv4/IPv6-nätverksstack, TCP/UDP-buffertar, köer, kontroll av överbelastning.
• fs.*: gränser för deskriptorer, inoder, inotify, AIO och VFS-beteende.
• utvecklare*specifika parametrar för vissa enheter och drivrutiner.

med sysctl -a Du kan lista alla tillgängliga parametrar, och med kommandon som sysctl vm.swappiness o sysctl net.ipv4.tcp_tw_reuse avläsning av specifika värden, vilket är nyckeln till granska den aktuella konfigurationen innan man ändrar något. För att hitta något specifikt är det vanligt att filtrera med grep, till exempel: sysctl -a | grep tcp.

Att ändra en parameter i realtid är lika enkelt som att använda sysctl -w clave=valorDet är dock viktigt att förstå att dessa ändringar är tillfälliga. För att spara dem efter en omstart är det viktigt att säkerhetskopiera konfigurationen till /etc/sysctl.conf eller i filer från /etc/sysctl.d/, vanligtvis med numrerade filer (till exempel 10-network.conf, 20-memory.conf, 99-custom.conf) som avgör i vilken ordning de tillämpas.

Mät innan du rör vid: riktmärken och systembaslinje

Innan du börjar pilla med rattar är det klokt att etablera en objektiv prestandabaslinje . Utan förhandsdata är det omöjligt att veta om förändringarna har förbättrat eller försämrat systemet, och du kommer att falla i den klassiska "det verkar bättre för mig"-fällan, som är värdelös för att fatta välgrundade beslut.

På systemnivå är det en bra idé att samla in statistik över CPU, belastning, minne, disk och nätverk under några minuter under en representativ belastning. Verktyg som uptime, mpstat, vmstat, iostat -x o sar -n DEV De låter dig se hur standardkärnan beter sig, hur mycket swap den använder, hur disk-I/O svarar och om nätverket är mättat eller slösar bandbredd.

Utöver den översikten är det avgörande att köra specifika riktmärken för den applikation du vill optimera. På webbservrar kan du använda ab (Apache Bench) eller liknande verktyg för mätning förfrågningar per sekund, genomsnittlig latens och felI databaser, verktyg som mysqlslap o sysbench De hjälper till att utvärdera transaktioner per sekund och frågetider.

Till exempel, i ett scenario utan finjustering är det vanligt att hitta siffror som 500 HTTP-förfrågningar/s med en genomsnittlig svarstid på 200 ms, cirka 250 SQL-frågor/s med 40 ms latens, en nätverkshastighet på cirka 500 Mbps och en systembelastning som närmar sig sin gräns under stress. Dessa siffror kommer att användas för att verifiera, efter att kärnändringar har tillämpats, om en mätbar ökning av dataflödet och en minskning av latensen faktiskt uppnås.

Slutligen, dokumentera kommandona och resultaten innan du gör några ändringar. Att ha en historik gör att du kan jämföra olika justeringsbatchar korrekt och hjälper dig också att upptäcka regressioner efter en kärnuppdatering eller efter att du har introducerat en ny sysctl-profil i produktion.

Avancerade minnesinställningar: vm.*

Minne är ett av de delsystem där kärnförändringar är mest märkbara. En server med mycket RAM, men dåligt konfigurerad, kan använda swap-utrymme i onödan, vilket orsakar... I/O-toppar och drastiska prestandaminskningarDet är därför parametrar som vm.swappinessKvoter för smutsiga sidor eller VFS-cachebeteende är lika viktiga.

Parameter vm.swappiness Detta styr hur många minnessidor kärnan skickar för att byta. I många distributioner är det satt till 60, ett värde avsett för blandade skrivbordsmiljöer. För databasservrar eller applikationer med låg latens är det vanligtvis att föredra att sänka det till 10 eller ännu mindre, vilket resulterar i ett mer effektivt system. Prioritera att lagra data i RAM och minska utbytetDet är inte ovanligt att disktrafiken minskar kraftigt och att applikationer svarar med mycket mindre jitter efter denna justering.

En annan grundläggande byggsten är vm.dirty_ratio y vm.dirty_background_ratioDessa värden avgör hur stor andel av minnet som kan fyllas med smutsiga sidor innan kärnan börjar spola dem till disken. Alltför höga värden kan leda till stora skrivningsfrekvenser, med enorma latenser för alla applikationer när spolningen sker. Att minska dessa procentsatser till siffror som 15 respektive 5 resulterar vanligtvis i en mer konsekvent och förutsägbart I/O-mönster.

Inställningen av vm.vfs_cache_pressure Detta definierar hur aggressivt kärnan rensar inode- och katalogcacher. Ett standardvärde på 100 tenderar att rensa cachen snabbt, medan inställningar runt 50 gör att metadata kan behållas längre, vilket ökar träfffrekvensen för filoperationer och förbättrar prestandan. filsystemets upplevda prestanda, något viktigt i servrar som hanterar miljontals små filer.

För sin del, vm.min_free_kbytes Reservera en minimal mängd ledigt minne för att säkerställa att systemet kan reagera på allokeringsutbrott utan att plötsligt uppleva "out-of-box"-situationer (OOB). Att dimensionera detta till cirka 0,5 % till 1 % av det totala RAM-minnet är vanligtvis en effektiv säkerhetsåtgärd för att förhindra att kärnan får slut på utrymme under extrem belastning och börjar stoppa kritiska processer, vilket förbättrar prestandan. övergripande värdstabilitet.

Slutligen förtjänar överåtkomstpolicyn uppmärksamhet: parametrar som vm.overcommit_memory y vm.overcommit_ratio De avgör hur mycket virtuellt minne som allokeras till processer i förhållande till tillgängligt RAM och swap. I vissa fall (till exempel med Redis eller vissa databaser) tillåts aggressiv överåtkomst, medan i andra fall föredras en mer konservativ policy för att begränsa risken för OOM och situationer med alltför komprometterat minneFör tekniker för att analysera och diagnostisera komplexa fall, se minnesfelsökning i Linux.

Avancerad nätverksoptimering: net.* och TCP/IP

Nätverksstacken är kanske det område där finjustering är mest märkbar i produktionsmiljöer. En enkel förändring i anslutningsköer eller buffertar kan göra skillnaden mellan en server som halkar vid 500 Mbps och en som Det mättar lätt gigabiten.Parametrarna under net.core.* y net.ipv4.* På det här området är de dina bästa allierade.

Till att börja med påverkar socketbuffertstorlekar direkt den maximala dataflödet för en anslutning, särskilt när det finns höga latenser eller länkar med hög kapacitet. net.core.rmem_max y net.core.wmem_max till generösa värden (tiotals eller hundratals megabyte) och definiera korrekt net.ipv4.tcp_rmem y net.ipv4.tcp_wmem (minimum, standardvärde och maximum) tillåter varje uttag att ha utrymme som behövs för att dämpa trafikstockningar utan att falla in i artificiella begränsningar som införs av mycket konservativa fabriksvärden.

En annan viktig punkt är storleken på anslutningsköerna. Parametrar som net.core.somaxconn, net.core.netdev_max_backlog y net.ipv4.tcp_max_syn_backlog Dessa gränser definierar hur många väntande anslutningar systemet kan hantera innan paket släpps eller handskakningar avvisas. På webbservrar med hög trafik kan en ökning av dessa gränser förhindra överbelastade köer och drastiskt minska belastningen. anslutningsfel under toppbelastning.

Beteendet hos TCP-anslutningar kan också finjusteras med en mängd alternativ: aktivera net.ipv4.tcp_window_scaling För att stödja stora fönster på länkar med hög bandbredd, aktivera net.ipv4.tcp_sack y net.ipv4.tcp_timestamps för att förbättra hanteringen av förlust och återutsändning, eller justera net.ipv4.tcp_fin_timeout och ledningen av TIME_WAIT (net.ipv4.tcp_tw_reuse, net.ipv4.tcp_max_tw_buckets) för att kontrollera resursförbrukningen på servrar med miljontals korta anslutningar per minut.

Valet av algoritm för kontroll av överbelastning spelar också roll. cubic Det förblir standardvärdet i många distributioner; ändras till bbr i moderna kärnor (4.9 och senare) av net.ipv4.tcp_congestion_control y net.core.default_qdisc=fq Den kan mångdubbla TCP-genomströmningen i miljöer med komplexa förluster eller latenser, vilket i vissa scenarier ger förbättringar på mellan 2 och 25 gånger jämfört med klassiska konfigurationer, till bekostnad av något annorlunda beteende i överbelastade nätverk.

Vi får inte glömma säkerhets- och tillförlitlighetsparametrar som t.ex. net.ipv4.tcp_syncookies, hanteringen av omdirigeringar (net.ipv4.conf.all.accept_redirects, send_redirects) eller filtrering i bryggor (net.bridge.bridge-nf-call-iptables i Kubernetes-miljöer). Korrekt konfigurerade låter de dig skydda systemet från vanliga attacker (SYN-översvämning, förfalskning etc.) utan att offra en solid nätverksprestandaFör en praktisk guide om regler och upptäckt, kolla in Netfilter- och Suricata-implementering.

Filsystem, deskriptorer och globala gränser: fs.* och ulimit

På moderna servrar är en låg filbeskrivningsgräns det snabbaste sättet att få ett system att sluta fungera under högtrafik. När en webbserver, omvänd proxy eller databas stöter på det klassiska felet "för många öppna filer" beror det vanligtvis på att kärnparametrarna och användargränserna inte har skalats för den faktiska belastningen.

På global nivå fs.file-max Detta anger hur många deskriptorer kärnan kan ha öppna totalt. För applikationer med tusentals samtidiga anslutningar är det vanligt att öka detta värde till flera miljoner, tillsammans med en ökning av fs.nr_openvilket fastställer det hårda taket för deskriptorer per process. Dessutom behövs justeringar. /etc/security/limits.conf så att användare (eller tjänster som hanteras av systemd) har mjuka och hårda värden som överensstämmer med kärnkonfigurationen.

Delsystemet inotify, som används flitigt av IDE:er, webbutvecklingsverktyg och filövervakningssystem, styrs av parametrar som fs.inotify.max_user_watches y fs.inotify.max_user_instancesOm du stöter på fel relaterade till övervakare eller processer som slutar övervaka diskändringar behöver du förmodligen Öka dessa gränser för att undvika tysta flaskhalsar.

En annan relevant funktion är asynkron I/O (AIO), vars globala maximum definieras med fs.aio-max-nrI applikationer som är starkt beroende av asynkron I/O (vissa databasmotorer, kösystem etc.) förhindrar en ökning av den att kärnan får slut på platser för AIO-operationer under en massiv förfrågningsbelastning.

Utöver dessa parametrar påverkas diskundersystemets prestanda av I/O-schemaläggare konfigurerad på varje blockenhet. I system med SSD-diskar eller NVMe rekommenderas det vanligtvis att använda lättviktiga schemaläggare som none o mq-deadline, medan andra alternativ kan vara vettiga på mekaniska skivor, såsom bfq beroende på typ av belastning. Justera schemaläggaren genom /sys/block/<disco>/queue/scheduler och finjustera alternativ som ködjup (nr_requests) eller read_ahead_kb kan göra en märkbar skillnad i läs-/skrivlatens och dataflödeDet är också viktigt att överväga vilka filsystem och drivrutiner som används; till exempel artiklar om NTFSplus på Linux och andra system kan hjälpa till vid dimensionering av heterogena laster.

Slutligen bör man inte glömma att dessa kärnbegränsningar måste gå hand i hand med systemkonfigurationer som de för ulimit och systemd-enheter, för att säkerställa att tjänster faktiskt kan använda de definierade ytterligare resurserna och inte blockeras av begränsningar i övre lager.

Kärngeneral, NUMA, CPU-affinitet och enorma sidor

Utöver nätverk, minne och filsystem erbjuder själva kärnan en rad justeringsalternativ som påverkar hur processer schemaläggs, hur arbetsbelastningar fördelas mellan kärnor och NUMA-noder, och hur minne hanteras i stor skala. På moderna maskiner med många kärnor och till och med flera socklar, gör dessa detaljer ofta skillnaden mellan en balanserad server och en med vissa kärnor mättade medan andra är underutnyttjade . Det är också värt att utforska alternativa kärnor som Liquorix-kärnan i miljöer där en annan latensprofil önskas.

Parametrar som kernel.pid_max De fastställer det maximala intervallet av process-ID:n som systemet kan tilldela, vilket är relevant för noder som kör ett stort antal containrar eller tillfälliga processer. Justera kärnloggningsalternativ (kernel.printk) hjälper till att minska överdrivet brus i dmesg samtidigt som kritiska händelser registreras, vilket också indirekt påverkar diagnostisk förmåga och stabilitet.

Beträffande minnestopologi, parametern kernel.numa_balancing Den styr i vilken utsträckning kärnan automatiskt flyttar sidor mellan NUMA-noder. Att inaktivera den i vissa miljöer möjliggör mer explicit hantering av process- och minnestillhörighet med hjälp av verktyg som numactl för att säkerställa att CPU- och RAM-intensiva processer förblir på samma nod, vilket minskar latens till följd av fjärråtkomstFör att bättre förstå samspelet mellan hårdvara och kärnschemaläggning är det också bra att granska tekniker som Intel Thread Director.

De stora sidorna (vm.nr_hugepagesDessa är en annan viktig komponent i databassystem eller andra arbetsbelastningar som hanterar stora områden med sammanhängande minne. Att reservera ett lämpligt antal jättesidor (2 MB eller till och med 1 GB, beroende på arkitekturen) kan minska TLB-overhead och avsevärt förbättra prestandan för applikationer som körs många operationer på stora minnesblockFör att detta ska vara effektivt måste kärnkonfigurationen koordineras med själva applikationen, så att den använder det minnet explicit.

Inom området latens och schemaläggning finns det schemaläggningsparametrar som kernel.sched_min_granularity_ns, kernel.sched_wakeup_granularity_ns o kernel.sched_migration_cost_nsDessa inställningar finjusterar storleken på CPU-"bitarna" som allokeras till varje uppgift och aggressiviteten med vilken kärnan flyttar processer mellan kärnor. Mindre värden representerar ett mer förutsebart system, vilket tenderar att erbjuda bästa svaret för interaktiva uppgifter till bekostnad av, ibland, en liten rå genomströmning.

I system där minne är en känslig resurs väljer vissa administratörer att aktivera panikläge i händelse av ett fel vid leverans (vm.panic_on_oom) och upprätta kernel.panic med en automatisk omstartstid. Denna strategi, även om den är något drastisk, kan vara användbar i miljöer med hög tillgänglighet där En snabb och kontrollerad omstart är att föredra framför en hängande och instabil värd. under timmar.

Specialiserade profiler: webb, databaser, låg latens och Kubernetes

Istället för att använda en enda magisk kula är det mer effektivt att skapa sysctl-profiler anpassade till olika typer av arbetsbelastningar: webbservrar, databaser, containerplattformar eller system med låg latens. Att distribuera dessa inställningar i filer som 99-webserver.conf, 99-database.conf o 90-kubernetes.conf hjälp till upprätthålla en organiserad och lättversionerad konfigurationDu kan också överväga prestandaorienterade distributioner och utgåvor som CachyOS Server Edition för mycket specifika miljöer.

För webbservrar (Nginx, Apache, proxyservrar etc.) är det viktigaste att hantera stora volymer samtidiga anslutningar med långa köer och svarstider. FIN_WAIT Med finjustering, ett utökat intervall för kortlivade portar och mycket höga deskriptorgränser är det vanligt att gå från några hundra HTTP-förfrågningar per sekund till flera tusen, vilket minskar den genomsnittliga latensen och eliminerar fel. mättade köer eller fulla portar.

På databassidan (MySQL, PostgreSQL och liknande) prioriteras minimal swap-användning, finjustering av dirty page-skrivning och lämpliga delade minnes- och semaforinställningar för motorn. Parametrar som kernel.shmmax, kernel.shmall, kernel.sem och den enorma sidkonfigurationen gör skillnad när det gäller transaktioner per sekund och svarstid, vilket multiplicerar prestandan med två eller tre jämfört med standardvärdena i många scenarier.

För applikationer med extremt låg latens (handel, onlinespel, realtidsbearbetning) läggs ännu mer specifika inställningar till: net.ipv4.tcp_low_latency, avaktivering av långsam start efter inaktivitet, användning av tcp_fastopen, parametrar för upptagna omröstningar (net.core.busy_poll, busy_read) och, i många fall, inaktivering av transparenta stora sidor genom /sys/kernel/mm/transparent_hugepage/enabledAllt detta syftar till att minska bearbetningskö och latenstoppar vid höga percentiler, vilket uppnår spektakulära förbättringar i P99.

I container- och Kubernetes-miljöer är nätverksstacken och anslutningsspårning under särskild belastning. Parametrar som net.ipv4.ip_forward, net.bridge.bridge-nf-call-iptables, net.netfilter.nf_conntrack_maxAnvändningen av reserverade portar för NodePort eller justering av ARP-tabeller är vanligt i noder som hanterar hundratals eller tusentals poddar. Att justera dem korrekt förhindrar problem. avkortade anslutningar, timeouts eller tabellmättnad med conntrack.

Bortsett från dessa specifika profiler väljer vissa organisationer ett prestandafokuserat arkiv med förbättrad säkerhet, som kombinerar stora nätverksbuffertar och minskad swappiness med åtgärder som tcp_syncookies eller blockering av farliga omdirigeringar. Målet är att uppnå en balanspunkt mellan aggressiv prestanda och rimlig härdning.

Verktyg för kärnprofilering och övervakning

Att justera kärnan utan att mäta är som att spela en ljudmixer med förbundna ögon. Linux erbjuder en arsenal av verktyg för att förstå vad systemet faktiskt gör, från enkla räknare till detaljerade spår av kärnfunktioner, vilket gör att du kan korrelera konfigurationsändringar med mätbara effekter.

Bland de dagliga nyttigheterna finns vmstat, iostat, sar, ss, slabtop, htop o pidstatsom ger snabb information om processer, CPU, I/O, sockets och cacheanvändning. Kombinerat med systemloggar och mätvärden som exporteras till Prometheus, Grafana eller Collectd, och med resurser som avancerad systemövervakare för LinuxDe ger en ganska fullständig bild av hur värden beter sig före och efter varje stämning.

För att gå in mer på detaljer, verktyg som t.ex. perf De möjliggör profilering av CPU-användning på funktionsnivå, både användare och kärna, loggning av händelser i några sekunder eller minuter och sedan tillhandahållande av en interaktiv rapport. perf stat, perf record y perf report du kan se var CPU-tid faktiskt förbrukas och vilken del som motsvarar kärnan, identifiera till exempel en störningsstorm eller en dåligt justerad schemaläggningsprogramvara.

Om du behöver ännu mer detaljerad information, ftrace Kärnans spårningsundersystem erbjuder möjligheten att aktivera specifika spårare (till exempel funktionsspåraren) och undersöka i realtid eller efter döden vilka anrop som sker. Aktivera lämplig spårare och analysera dess innehåll. /sys/kernel/debug/tracing/trace det avslöjar för dig hotspots i själva kärnanDetta är mycket användbart när övergripande mätvärden inte räcker till.

Parallellt är det lämpligt att implementera automatiserade övervakningsskript som regelbundet dumpar viktig data (nätverksstatistik, minnesräknare, antal öppna filbeskrivningar etc.) i roterande loggar. När vissa tröskelvärden har uppnåtts (till exempel överskridande av ett visst antal öppna filbeskrivningar) kan dessa skript generera varningar via e-post eller andra kanaler, vilket hjälper till att upptäcka farliga trender innan ett problem eskalerar.

Slutligen, i långvariga stresstestfaser (24 timmar eller mer), verktyg som stress-ng kombinerat med kontinuerlig insamling av mätvärden (via vmstat, iostat, sar) låter dig bedöma systemets stabilitet med den nya kärnkonfigurationen och verifiera att det inte finns några OOM-händelser, krascher, oväntade omstarter eller progressiva prestandaförsämringar under ihållande belastning.

Att optimera Linuxkärnan med sysctl och andra mekanismer är inte en engångsuppgift, utan snarare en iterativ process som involverar mätning av resultat, justering av parametrar och noggrann dokumentation av allt. Med en tydlig metod, specifika profiler för varje typ av arbetsbelastning, en robust uppsättning profileringsverktyg och strikt ändringskontroll är det möjligt att uppnå servrar som utnyttjar sin hårdvara fullt ut, med ökad dataflöde, minskad latens och betydligt större stabilitet än den generiska fabrikskonfigurationen.