Linux-kärnan 6.x: Viktiga nyheter för webbhotellsservrar

Att korrekt klassificera kärnstatus

Beteckningen Linux 6.x sammanfattar många huvudutgåvor, inte en enhetlig funktionsnivå. Som ”mainline” betraktas den huvudgren som underhålls av Linus Torvalds: Efter ”merge window” följer vanligtvis release candidates fram till den slutgiltiga huvudutgåvan. Dessa ska skiljas från Stable- och LTS-grenarna, som fortsätter att underhålla publicerade kärnor med utvalda korrigeringar. Distributionskärnor följer i sin tur egna paketversioner, supportåtaganden och integrationsbeslut.

Särskilt för webbservrar är Backportar Avgörande: En distribution kan införliva enskilda funktioner, drivrutinsförbättringar eller säkerhetskorrigeringar i en äldre kärna som underhålls på lång sikt. Omvänt kan den inaktivera funktioner, anpassa patchar eller begränsa dem genom konfiguration. Utifrån ett versionsnummer går det därför varken att avläsa den fullständiga funktionsomfattningen eller den konkreta driftspåverkan.

Kommandot uname -r identifierar den aktuella versionssträngen och utgör en bra utgångspunkt för inventering och paketjämförelse. Den bevisar dock inte att en funktion är inkompilerad, aktiverad vid körning eller tillgänglig för en applikation. Inte heller en ny kärnversion ersätter en kontroll av den konfiguration och dokumentation som distributören tillhandahåller.

För en tillförlitlig klassificering bör du granska flera nivåer: distribution och paketstatus, kärnkonfiguration, startparametrar och befintliga körningsgränssnitt. Därtill kommer hårdvara, firmware och drivrutiner, till exempel vid lagring eller virtualisering. Slutligen måste den använda applikationen faktiskt utnyttja ett gränssnitt; en befintlig kärnfunktion förändrar inte automatiskt en webbserver.

Denna artikel följer därför inte någon fullständig utvecklingshistorik. Den behandlar funktioner som är relevanta för driften av dagens 6.x-kärnor. Inte alla av dessa funktioner introducerades först i 6.x-serien; det avgörande är den funktionsnivå som finns tillgänglig i den specifika kärnan, möjliga utökningar samt effekterna på minnesbeteende, CPU-konkurrens, processisolering och underhåll.

Fyra verksamhetsområden inom webbhotell

När det gäller webbservrar är fyra driftsområden särskilt relevanta: minnesutskrift, CPU-konkurrens, ytterligare processisolering och underhåll. Det handlar inte om att ha så många aktiverade kärnfunktioner som möjligt, utan om lämpliga verktyg för ett specifikt problem. PHP-FPM-pooler, databaser, cacher, batchjobb och specialiserade arbetare ställer olika krav som inte kan härledas enbart utifrån kärnversionen.

cgrupp v2 är ett övergripande tema, men ingen nyhet i 6.x-serien. Hierarkin strukturerar minnes- och CPU-resurser för tjänster, containrar eller kundgrupper. Vilka styrenheter som är tillgängliga och aktiverade i en underhierarki måste kontrolleras vid respektive cgroup-v2-mount. En dedikerad webbserver kräver därför en annan bedömning än en container- eller VM-värd.

Tabellen skiljer medvetet mellan byggkonfiguration, startaktivering, körningsgränssnitt och faktisk användning. En funktion kan finnas i kärnan men vara inaktiverad eller irrelevant för applikationen. På samma sätt kan distributioner portas tillbaka. Utvärdera därför ändringar utifrån belastningshistorik, cgroup-uppbyggnad, hårdvara och applikationsmätvärden istället för utifrån det högsta tillgängliga versionsnumret.

Lagringstryck och sidåtervinning

Linux använder gärna ledigt arbetsminne som filcache. Att en stor del av RAM-minnet är upptaget är därför i sig inget fel och inte heller något tecken på slöseri med minne: cachelagrade filsidor kan återvinnas vid behov. För diagnosen är det snarare belastningens utveckling och konsekvenser som är viktiga, till exempel svarstider, swap-aktivitet, felprotokoll och avbrutna processer.

Det avgörs av lagringstrycket Återvinning av sidor , vilka sidor som kan tas bort från cachen eller, i förekommande fall, flyttas ut. Kärnan kan utföra detta arbete asynkront via kswapd utföra. Om en process själv måste återta sidor vid en minnesbegäran talar kärndokumentationen om direkt återtagning; detta kan påverka den begärande processen och därmed de observerade fördröjningarna.

Varningssignaler uppstår oftast som en kombination: ihållande in- eller utlagring till swap, OOM-händelser, ökande väntetider och fel på applikationsnivå bör sammanställas på en gemensam tidsaxel. En engångsavvikelse kan däremot vara ett planerat batchjobb. Inte heller är en cachetjänst som använder mycket RAM automatiskt orsaken, om dess cgroup och de övriga processerna förblir tillräckligt funktionsdugliga.

cgroup v2 kompletterar den globala översikten med gränser för tjänster eller containrar. Lagringskontrollern tillhandahåller händelseräknare; memory.events är hierarkisk, medan memory.events.local visar endast lokala händelser i respektive cgroup. På så sätt går det att avgöra om ett problem beror på den egna tjänstens gränsvärde eller på belastningen i en överordnad struktur.

Dessa grundläggande faktorer talar ännu inte för prestandajustering. Innan du ändrar gränsvärden, swap-strategi eller kärngränssnitt bör du kartlägga belastningskällor, cgroup-tilldelning och tidsmässig korrelation. Särskilt en strikt minnesgräns kan få en tjänst att krascha i förtid, istället för att lösa den underliggande arbetsbelastningstoppen. Först efter en diagnos framgår det om en ändring överhuvudtaget har en lämplig teknisk justeringsmöjlighet.

Genomföra riktade kontroller av Multi-Gen LRU

Multi-Gen LRU är en alternativ implementering av Återvinning av sidor och beskrivs i den kärndokumentation som behandlas här från och med Linux 6.1. Vid minnesbrist måste kärnan avgöra vilka filcache- eller anonyma minnessidor som kan återvinnas. Multi-Gen LRU sorterar sidorna i generationer utifrån hur länge sedan de användes och tar hänsyn till åtkomstmönster, så att sidor som används ofta är mindre benägna att väljas ut för återvinning.

Detta är relevant för en hårt belastad webbhotellserver där PHP-FPM-pooler, en databas och en cachedienst samtidigt belaster RAM-minnet. Funktionen kan påverka valet vid återvinning, men är varken en minnesutökning eller en garanti för kortare svarstider. Arbetsbelastning, RAM-kapacitet, swap, masslagring och tjänsternas cgroup-gränser avgör fortfarande om och hur en effekt märks.

Innan varje utvärdering ska du först kontrollera om runtime-gränssnittet finns och är läsbart. I den aktuella kärndokumentationen anges följande konfigurationsalternativ för detta CONFIG_LRU_GEN och CONFIG_LRU_GEN_ENABLED samt sökvägen under /sys/kernel/mm/lru_gen/. En distributionskärna kan porta tillbaka funktionsnivåer eller konfigurera dem på annat sätt; versionsnumret i sig är därför inget tillförlitligt bevis.

test -r /sys/kernel/mm/lru_gen/enabled && cat /sys/kernel/mm/lru_gen/enabled

Ett utdata bevisar inledningsvis endast att det dokumenterade sysfs-gränssnittet finns och går att läsa. För aktiveringsstatusen är bitvärdet avgörande: 0x0001 är huvudbrytaren för Multi-Gen LRU. Om detta bit saknas kan filen visa att huvudbrytaren är avstängd trots att gränssnittet är tillgängligt; övriga bitar avser ytterligare komponenter. Även om huvudbiten är aktiverad är det inte en allmän rekommendation att ändra värdet i produktionsmiljön.

Skrivåtkomst till sysfs är därför inte en standardåtgärd vid optimering. Samla först in tidsserier om Reclaim, Swap, latenser och cgroup-händelser, dokumentera utgångsvärdet vid en välmotiverad ändring och fastställ en återgångsplan. På så sätt går det att spåra om det observerade problemet faktiskt har förändrats eller om det bara är flera styrvariabler som har justerats samtidigt.

Du bör vara särskilt försiktig när lagringsutrymmet är begränsat och tjänsterna är överbokade. En ändrad återvinningsalgoritm korrigerar inte för stora PHP-arbetspooler, olämpliga databascacher eller bristande åtskillnad mellan konkurrerande kunder. Den lämpliga ordningen är: fastställa orsaken och den berörda c-gruppen, begränsa eller fördela belastningen och först därefter utvärdera en tillgänglig kärnfunktion som möjlig påverkande faktor.

Att på ett säkert sätt avgränsa minnesproblem

Använt RAM är i sig inte ett fel: Linux använder ledigt minne specifikt som filcache. Det är snarare när kraven i direkt återvinning körs, swap-aktiviteten ökar, OOM-händelser inträffar eller förfrågningarna samtidigt blir långsammare. Asynkron återvinning genom kswapd fungerar i bakgrunden; direkt återvinning sker däremot i samband med den uppgift som kräver minnesutrymme och kan fördröja dess utförande.

Händelsefilen memory.events räknar händelser hierarkiskt, det vill säga inklusive underordnade cgroups. För den uteslutande lokala vyn gäller memory.events.local klar. high betyder strypning och direkt återvinning efter att memory.high, medan oom en allokering som riskerar att misslyckas på grund av cgroup-gränsen räknas. oom_kill räknar däremot processer i denna cgroup som har avslutats av någon form av OOM-killer.

Börja felsökningen med en tydlig kartläggning: Vilken tjänst eller vilken container tillhör den misstänkta c-gruppen, när inträffade händelserna och vilka applikationssignaler förekom samtidigt? Jämför därefter lokala räknare med hierarkiska räknare, systemloggen, swap-historiken samt HTTP-fördröjningar, databasväntetider eller felprocent. Vid ett OOM-fall måste man dessutom klargöra om data pekar på en cgroup-relaterad händelse eller en möjlig global minnesbrist.

Värdet memory.max är en strikt cgroup-gräns och inte en första standardåtgärd. En lägre gräns kan skydda klienter, men också leda till att en applikation hamnar i OOM-situationer tidigare; en högre gräns kan förvärra trängseln hos angränsande tjänster. Kontrollera därför först antalet arbetare, cache-storlekar, belastningstoppar och cgroup-strukturen. Ändra därefter endast en välmotiverad inställning med en observationsperiod och en plan för återgång till tidigare inställningar.

Att förstå EEVDF och konkurrensen mellan CPU:er

Den aktuella officiella kärndokumentationen anger att övergången inleds den EEVDF Linux 6.6. Algoritmen ”Earliest Eligible Virtual Deadline First” förändrar urvalet av vanliga, rättvist schemalagda uppgifter: Hänsyn tas till virtuell körtid, fördröjning som avvikelse från den ideala fördelningen samt virtuella tidsfrister. Berättigade uppgifter med den tidigaste virtuella tidsfristen kan därmed få CPU-tid först.

Formuleringen „övergång“ är viktig. EEVDF ersätter inte valet av Fair Scheduling-klass i den meningen att alla datastrukturer, gränssnitt och begrepp som historiskt sett har benämnts CFS därmed försvinner. Även den aktuella dokumentationen fortsätter att jämföra EEVDF med CFS. För en specifik distributionskärna måste därför dess integrerade patch- och funktionsstatus kontrolleras, istället för att enbart utgå från 6.6 eller högre för att dra slutsatsen att beteendet är helt enhetligt.

När det gäller webbhotell är denna förändring framför allt relevant vid blandad belastning. Webbförfrågningar, databasbearbetning och övervakning konkurrerar till exempel med importer, komprimering eller säkerhetskopiering. Det är möjligt att få en annan latensprofil mellan olika kärnversioner, men det innebär inte automatiskt högre total genomströmning. Schemaläggaren löser inte problem som kontinuerligt utnyttjade kärnor, blockerade processer, I/O-väntetider och olämpliga applikationskonfigurationer.

Den operativa uppdelningen sker fortfarande utifrån tjänst- och plattformsgränser. CPU-vikter påverkar den relativa fördelningen vid konkurrens, medan kvoter kan begränsa den tillgängliga beräkningstiden. Om webbtrafik där latens är avgörande måste separeras på ett tillförlitligt sätt från omfattande batchjobb kan även en egen virtuell maskin (VM) eller en separat värd vara lämpligt. EEVDF ersätter dessa Resursplanering inte.

Innan man hämtar cgroup.controllers måste du ta reda på om och var cgroup v2 är monterad. Följande läsningssekvens söker efter cgroup-v2-monteringspunkten istället för den vanliga sökvägen /sys/fs/cgroup förutsätts. På ett system som enbart använder cgroup v1 förblir variabeln tom; i en hybridhierarki visar den endast den v2-montering som hittats.

uname -r
findmnt -t cgroup2 -o TARGET,FSTYPE,OPTIONS
CG2=$(findmnt -n -t cgroup2 -o TARGET | head -n 1)
if [ -n "$CG2" ] && [ -r "$CG2/cgroup.controllers" ]; then
    printf 'cgroup-v2 mount: %s\n' "$CG2"
    cat "$CG2/cgroup.controllers"
    test -r "$CG2/cgroup.subtree_control" && cat "$CG2/cgroup.subtree_control"
fi
systemd-cgtop

uname -r anger endast den aktuella versionssträngen. cgroup.controllers visar en lista över de styrenheter som är tillgängliga för aktivering i just denna cgroup; det bekräftar inte att de har aktiverats i de relevanta underhierarkierna. För detta finns bland annat cgroup.subtree_control kontrolleras på respektive hierarkinivå. Controllers godkänns uppifrån och ner, vilket innebär att en underordnad cgroup endast kan vidarebefordra controllers som tillhandahålls av den överordnade noden.

systemd-cgtop ger också endast en ögonblicksbild och utgör ingen orsaksanalys. Samla in uppgifter om CPU-utnyttjande per tjänstegrupp, fördröjningar vid förfrågningar, körtider för batchjobb och, vid behov, I/O-väntetider under flera jämförbara belastningsfaser. Om fördröjningar endast uppstår under en säkerhetskopiering är dess tidsfönster, CPU-vikt eller kvot oftast mer konkreta första justeringspunkter än en förmodad schemaläggningsjustering.

Landlock för specialiserade arbetstagare

Landlock introducerades först i Linux 5.13 och är därför inte en nyhet som infördes i 6.x-serien. I 6.x-kärnor finns olika, utökade ABI-nivåer tillgängliga, beroende på version och distributionskärna. Funktionen är en kompletterande säkerhetsmekanism som gör det möjligt för en process att ytterligare begränsa sig själv.

Som ett stapelbart Linux-säkerhetsmodul fungerar Landlock som ett komplement till de redan gällande åtkomstbesluten; det ersätter varken Unix-filrättigheter, SELinux, AppArmor, namnutrymmen eller containrar. Reglerna kan bland annat begränsa åtkomsten till filsystemet och överförs till efterföljande barnprocesser. Den praktiska funktionsomfattningen beror på den tillgängliga ABI:n och kärnkonfigurationen.

Det är lämpligt att Landlock framför allt för egenutvecklade eller specifikt utvalda enskilda processer. En konverterare för kunduppladdningar skulle kunna läsa in filer endast från en inmatningsmapp och skriva ut resultaten uteslutande till en utmatningsmapp. Även om tjänsten skulle fungera felaktigt ska den varken kunna läsa SSH-nycklar, applikationshemligheter eller allmänna systemvägar. Denna begränsning kompletterar en noggrann behörighetstilldelning, men gör den inte överflödig.

En produktiv regel får inte utgå enbart från en aktuell kärna. Landlock har flera ABI-versioner; en applikation bör vid körning kontrollera vilken ABI som är tillgänglig och endast begära åtkomsträttigheter eller funktioner som denna ABI stöder. På så sätt kan den fungera i begränsad omfattning på äldre system, istället för att helt sluta fungera på grund av ett gränssnitt som inte finns tillgängligt.

Därifrån avskilt ligger handled_access_fs fastställer uttryckligen vilka åtkomster till filsystemet som en regelsamling hanterar och som, utan motsvarande regel, nekas som standard. Detta uttryckliga avtal mellan applikationen och kärnan förhindrar att en sandlåda blir strängare utan att man märker det enbart på grund av en systemuppdatering, vilket skulle leda till att applikationer slutar fungera. ABI-frågor och uttryckligen hanterade rättigheter hör därför ihop, men löser olika kompatibilitetsuppgifter.

För filkonverteraren innebär detta en stegvis implementering: att utgå från den faktiska processen för att fastställa vilka läs-, skriv- och arbetskataloger som behövs, ta hänsyn till felhantering och först testa i en testmiljö. En kortfattad exempelpolicy skulle inte utgöra en tillförlitlig produktionslösning, eftersom tillfälliga filer, externa bibliotek och startade hjälpprogram kan kräva ytterligare åtkomst. Ytterligare åtgärder för tjänsteisolering behandlas även i artikeln om Kärnhärdning för webbhotellsservrar.

Särskild försiktighet krävs vid OverlayFS. Regler för ett överläggsskikt begränsar inte automatiskt den sammanslagna monteringshierarkin och vice versa. Container- och byggmiljöer med överlägg kräver därför en separat granskning av de konkreta monteringspunkterna och åtkomstvägarna. Landlock är där ett möjligt tilläggslager, men ingen generell klientseparering och ingen ersättning för ett hållbart container- eller behörighetskoncept.

DAMON endast för särskilda fall

DAMON och de Reclaim-mekanismer som bygger på det kan inte generellt betraktas som funktioner som först introducerades i Linux 6.x. För administratörer är det funktionsnivån hos den specifika 6.x-kärnan eller distributionskärnan som används som är avgörande. DAMON övervakar minnesåtkomst i syfte att kunna klassificera områden utifrån deras användningsbeteende.

Med utgångspunkt i detta försöker DAMON_RECLAIM, att proaktivt återvinna minne som inte använts på länge genom att utöva ett lätt tryck. Metoden kompletterar den vanliga LRU-baserade återvinningen; den är inte avsedd att ersätta den. I kärndokumentationen klassificeras den som gällande allmänna överbokade minnessystem, och virtualisering baserad på rapportering av lediga sidor nämns som exempel.

I detta virtualiseringsscenario är nivån avgörande: gästerna rapporterar lediga minnessidor till värden, som värden kan tilldela andra gäster. Om en gäst rapporterar endast lite ledigt minne, trots att den håller kvar sidor som inte använts på länge, kan proaktiv återvinning som gäst bidra till att rapportera fler lediga sidor till värden. DAMON_RECLAIM är därför inte, utan ytterligare granskning, en värdbaserad lösning för gästers outnyttjade arbetsminne.

För en enskild webb- eller databasserver är detta därför ingen standardåtgärd. Även i virtualiserade miljöer måste man först klargöra på vilken nivå belastningen uppstår och om det verkligen är områden som varit oanvända under lång tid som är orsaken. CPU-flaskhalsar, långsam lagring, olämpliga cgroup-gränser eller aktiva applikationscacher kan förklara samma symptom, utan att proaktiv återvinning skulle vara den rätta lösningen.

Kvoter, åldersgränser och vattenmärken styr när och i vilken utsträckning DAMON_RECLAIM är aktivt. Det rör sig inte om överförbara standardvärden: Ett alltför aggressivt urval kan för tidigt tränga undan användbar filcache eller minnessidor som återkommande behövs. Detta kan utlösa ytterligare I/O-operationer och ta upp CPU-tid för ombearbetning, trots att det nominellt lediga minnet ökar.

Ett välgrundat beslut kräver därför mätningar med tydliga jämförelsevärden, till exempel ledigt lagringsutrymme som rapporterats av gästen, återvinningsaktivitet, swap-beteende, lagringslatens och applikationens svarstider. Testa först ändringarna i en jämförbar staging-miljö, fastställ en återgångsplan och observera dem under representativa belastningsfaser. Om dessa förutsättningar saknas eller om orsaken till lagringsbelastningen är oklar förblir DAMON medvetet inaktiverat.

Uppdateringar, livepatching och omstarter

Kärnunderhåll inleds med att man jämför säkerhetsmeddelandet, det installerade paketet och den kärna som faktiskt körs. Kontrollera därefter i anvisningarna för din egen distribution vilken korrigering som är avsedd för just denna kärngren och om en omstart krävs. Ett högre versionsnummer i 6.x-serien i sig bevisar varken att patchen ingår eller att en lämplig livepatch finns tillgänglig; säkerhetskorrigeringar kan även portas tillbaka till äldre distributionskärnor.

Dessutom Livepatching infördes inte först som koncept med Linux 6.x. Den infrastruktur som är relevant för 6.x-kärnor gör det möjligt att tillämpa vissa kärnändringar under körning. Kumulativa livepatchar kan då ersätta en äldre patch atomärt med en nyare. De dokumenterade begränsningarna gäller bland annat tillståndsändringar, callbacks och återgång mellan patchar.

Om det finns en lämplig livepatch för en specifik distributionskärna måste detta kontrolleras utifrån leverantörens aktuella utbud och godkännanden. Av den allmänna kärninfrastrukturen följer varken att varje säkerhetskorrigering är tillgänglig direkt, eller att en installerad patch permanent ersätter en fullständig kärnuppdatering. Planera därför fortsatt in regelbundna underhållsfönster.

Bedöm först hur brådskande en uppdatering är och vilka konsekvenser den får, jämför sedan paketstatus och den aktuella kärnan och granska det konkreta Livepatch-förslaget. Efter en vanlig kärnuppdatering med omstart kontrollerar du om den förväntade kärnan är aktiv och att de kritiska tjänsterna, nätverksvägarna, säkerhetskopiorna och övervakningen fungerar korrekt. Denna kontroll ingår i underhållsrutinerna och bör inte endast baseras på serverns tillgänglighet.

En planerad nystart kan fortfarande vara nödvändigt trots livepatching. Ändringar av kärnans startparametrar träder vanligtvis i kraft först vid nästa omstart. När det gäller drivrutiner, enhetsfirmware och hårdvara beror tillvägagångssättet däremot på komponenten, hur den är integrerad och tillverkarens procedur: ibland räcker det med att starta om en modul, en enhet eller en tjänst, medan det i andra fall krävs en fullständig omstart av värddatorn.

Den kompletterande artikeln om Livepatching på AlmaLinux-servrar handlar om en konkret distributionsberoende implementering. Överför inte sådana processer utan att först kontrollera dem till andra kärngrener eller leverantörer. Det är paketen, de stödda kärnversionerna och driftsanvisningarna för den faktiskt använda plattformen som är avgörande.

• Gör medvetet inga ändringar om den observerade störningen ännu inte har någon identifierbar orsak.
• Planera inte in några Livepatch- eller kärnändringar utan lämplig staging-testning och en dokumenterad återställningsprocess.
• Aktivera inte någon funktion om det berörda programmet eller den berörda plattformen inte använder dess gränssnitt.
• Man ska inte ersätta ett uteblivet underhållsfönster med antagandet att livepatching täcker alla kärnuppdateringar.