Servrar och virtuella maskiner

Linux Scheduler CFS: Funktionalitet och alternativ inom serverhosting

Linux-schemaläggaren CFS styr hur serverkärnorna fördelar sin tid till processer och påverkar därmed direkt latens, genomströmning och rättvisa i serverhosting. I den här guiden förklarar jag hur den fungerar, inställningsspakarna och användbara alternativ som ULE, BFS och EEVDF för Hosting med webbservrar.

Centrala punkter

Rättvisa och vruntime avgöra vilken uppgift som får CPU.
C-grupper reglera kvoter och cpu.aktier för kundisolering.
Justering av kärnan via sched_latency_ns och Granularitet.
Alternativa lösningar såsom BFS, ULE, EEVDF för speciella Arbetsbelastning.
ÖvningCore affinity, I/O-planerare och Tester kombinera.

Hur CFS fungerar i det dagliga värdskapet

Med Completely Fair Scheduler bestämmer en virtuell runtime vilken uppgift som ska köras härnäst, vilket resulterar i en rättvis och förutsägbar Tilldelning skapas. Varje uppgift får CPU-tid som är proportionell mot nice-värdet, så att ett lågt nice-värde får fler andelar. I hostingmiljöer delar många små webbförfrågningar, cronjobs och säkerhetskopior upp CPU-tiden mellan sig utan att en process tar upp allt. Interaktiva arbetsbelastningar som NGINX-förfrågningar drar nytta av frekventa, korta tidsskivor, medan batchuppgifter får längre block. Detta innebär att svarstiderna förblir tillförlitliga för användarna, även om många webbplatser bearbetar förfrågningar parallellt.

Jag använder Cgroups för att begränsa kunder och tjänster, eftersom cpu.shares och cpu.max säkerställer tydliga Aktier totalt och hårt Gränser. Ett standardvärde på 1024 andelar för “normal” och 512 för “mindre viktig” fördelar kärnorna på ett begripligt sätt. Med cpu.max ställer jag till exempel in 50 ms under en period på 100 ms, vilket i praktiken motsvarar 50% CPU-andel. Den här inställningen ger förutsägbara reserver för värdarbetsbelastningar med varierande belastningar. Jag kan hitta en kompakt förklaring av principen på rättvis CPU-fördelning.

CFS-mekaniken förklaras tydligt

I grunden hanterar CFS alla uppgifter som är redo att köras i ett rött/svart träd, sorterat efter vruntime och med effektiva Urval av den minsta virtuella runtimen. Denna uppgift körs härnäst och ökar sin vruntime i proportion till den CPU-tid som förbrukas och viktas via nice-värdet. Detta skapar en flytande balans utan hårda köer, vilket ger rena resultat, särskilt med blandade arbetsbelastningar. På flerkärniga system flyttar schemaläggaren uppgifter mellan körköer, men tar hänsyn till cache-lokalitet via kärnaffinitet. På så sätt kombinerar CFS lastbalansering med så få dyra migreringar som möjligt.

För finjustering kan parametrar som sched_latency_ns och sched_min_granularity_ns ange riktningen för Fördröjning och Genomströmning. Mindre latensvärden gynnar korta, interaktiva jobb, medan större värden stärker batchjobb. I tester med verktyg som stress-ng och fio kontrollerar jag effekten på svarstider och CPU-användning. I takt med att antalet uppgifter ökar, ökar också trädets administrativa overhead, vilket kan visa sig i form av höga latenstider. Korrekt inställda kvoter och gränser håller dock dessa effekter i schack i hostingmiljöer.

CFS styrkor inom serverhosting

Den största styrkan ligger i Rättvisa, jämnt och begripligt Resurser distribuerad. För delade miljöer innebär detta att ingen kund permanent tränger undan andra eftersom kvoter och andelar tydligt definierar viktningen. Interaktiva tjänster får snabba svarstider, medan backuper får köras utan brådska. Prioritering via fina värden kompletterar bilden och ger mig utrymme för samordning beroende på vilken roll en tjänst har. Lastbalansering över alla kärnor gör att jag kan utnyttja den tillgängliga datorkraften på ett bra sätt utan att ge Jeff moments enskilda trådar för mycket utrymme.

I praktiken blir styrkan hos CFS tydlig när webbservern har toppar och många korta förfrågningar kommer, eftersom CFS tilldelar frekventa slots till dessa typer av uppgifter. Rena C-grupper hjälper till att sätta hårda övre gränser per kund eller container. Mätningar av medelvärden och percentiler visar tillförlitliga svarstider, vilket lönar sig i den dagliga verksamheten. Det här tillvägagångssättet är särskilt användbart för applikationsstackar med många komponenter. Det är just här som blandningen av förutsägbar rättvisa och tillräcklig flexibilitet ger höga poäng.

Gränser och typiska stötestenar

Med ett extremt stort antal samtidiga uppgifter ökar overhead för trädoperationerna, vilket inte är fallet med Tips som Fördröjning kan driva upp prestandan. I hostingkonfigurationer med många mycket korta förfrågningar sker det ibland frekventa kontextändringar. Ett sådant “thrashing”-beteende minskar effektiviteten om granularitetsvärdena väljs felaktigt. Färre men längre tidsintervall kan hjälpa, så länge som interaktiviteten bibehålls. CFS reagerar känsligt på felaktiga kvoter, vilket är anledningen till att jag konsekvent kontrollerar gränserna med belastningstester.

Även affinitetsvänliga arbetsbelastningar blir lidande om uppgifter hoppar mellan kärnor för ofta. Ett rent affinitetskoncept håller cacheminnet varmt och minskar migrationskostnaderna. Jag gillar också att binda bullriga batchjobb till sina egna kärnor så att webbförfrågningar körs tyst på deras kärnor. För latenskritiska tjänster är det värt att sätta låga nice-värden och en finjusterad latency. Det som räknas i slutändan är att mätningarna bekräftar de valda parametrarna.

Jämförelse av alternativen: ULE, BFS och EEVDF

För speciella arbetsbelastningar tittar jag på alternativ för att Fördröjning eller . Skalning prioriterar på olika sätt. ULE använder enklare köer och får poäng med mindre administrativa insatser, BFS prioriterar respons och glänser med få uppgifter, och EEVDF kombinerar rättvis fördelning med tidsfrister. Särskilt EEVDF utlovar kortare väntetider för interaktiva belastningar eftersom schemaläggaren tar större hänsyn till “tidigaste tillåtna deadline”. För mycket stora serverfält är det som verkligen räknas i slutändan vilken mix av effektivitet och planeringsbarhet som verkligen vinner i din egen stack. En strukturerad genomgång av styrkor, svagheter och användningsområden underlättar urvalet.

schemaläggare	Komplexitet	Styrkor i värdskapet	Svagheter	Lämplig för
CFS	Hög	Rättvis fördelning, C-grupper	Fördröjningstoppar	Delad hosting, blandade belastningar
ULE	Låg	Enkla ledtrådar, låg Last	Mindre isolering	Virtuella datorer, HPC-liknande mönster
BFS	Medium	Interaktivitet, Hastighet	Svag skalning	Stationära datorer, små servrar
EEVDF	Medium	Låg latenstid, Deadlines	Fortfarande lite övning	Moderna hosting-stackar

Kernel tuning: praktiska steg för CFS

För CFS ändrar jag ofta sched_autogroup_enabled=0 så att inga implicita grupper förvränger bilden och Lastfördelning klar kvarlevor. Med sched_latency_ns vill jag börja på 20 ms, vilket gynnar interaktiva tjänster, och justera sched_min_granularity_ns för att tämja kontextförändringar. Värdena beror på profilen: många korta webbförfrågningar kräver andra finjusteringar än säkerhetskopieringsfönster. Jag testar ändringar seriellt och mäter percentiler i stället för att bara titta på medelvärden. Detta säkerställer inte bara att medelvärdena ser bra ut, utan också att de långa köerna krymper.

Om du vill gå djupare in på sysctl-parametrarna hittar du en bra introduktion här: sysctl-trimning. Jag ställer också in IRQ-distributionen, CPU-guvernören och energiprofilerna så att CPU:n inte ständigt tippar över till ekonomiska tillstånd. Jag använder prestandaregulatorer för latensdrivna stackar, medan rena batchboxar lever med balanserad kontroll. Jag separerar tydligt test- och produktionsfaserna så att det inte blir några överraskningar. Efter varje steg kontrollerar jag loggar och mätvärden innan jag går vidare.

Använd cgroups och kvoter på ett förnuftigt sätt

Med cpu.shares tilldelar jag relativa Vikter medan cpu.max är svårt Gränser uppsättningar. En kund med 512 aktier får hälften så mycket beräkningstid som en kund med 1024, om båda genererar belastning samtidigt. Jag använder cpu.max för att begränsa toppar på ett snyggt sätt, till exempel 50 ms i 100 ms. För dedikerade jobb är cpuset.cpus värdefullt så att en tjänst använder fasta kärnor och cacheminnet håller sig varmt. Allt som allt resulterar detta i en motståndskraftig separation mellan kunder och tjänster.

Jag dokumenterar varje förändring och jämför den med de servicenivåer jag vill uppnå. Utan uppmätta värden leder andelar snabbt till feltolkningar, vilket är anledningen till att jag alltid följer upp justeringar med belastningstester. För containrar föreslår jag realistiska kvoter som klarar av toppar men inte saktar ner värden. Det är fortfarande viktigt att ha en förutsägbar felbudget så att märkbara latensstoppar upptäcks. Om du gör detta konsekvent kommer du att undvika överraskningar vid toppar.

Övning: Webbserver och databaser under CFS

Händelsedrivna webbservrar minskar antalet kontextbyten och harmoniserar med CFS, vilket resulterar i märkbart konstanta Svarstider och bättre Skalning genererad. I tester ser jag att NGINX upprätthåller högre förfrågningshastigheter med mindre jitter på samma hårdvara. Databaser reagerar positivt på kärnaffinitet när bakgrundsjobb hålls borta från de heta kärnorna. Enkla regler hjälper: Webb på kärna A-B, batch på C-D och DB på E-F. På så sätt håller stacken pipelinen ren och cacherna varma.

Många små PHP FPM-arbetare orsakar för många switchar med aggressiv granularitet. Jag ökar sedan den minsta tidsskivan och kontrollerar om svarstiderna förblir stabila. Samtidigt stryper jag chattande loggar så att I/O inte blir en broms. CFS utgör grunden här, men topprestanda uppnås genom att finjustera hela stacken. På så sätt samverkar alla kuggar utan att ta andan ur värden.

Minne I/O och CPU-planering: samspelet

CPU-schemaläggare och I/O-schemaläggare påverkar varandra, och därför kan en harmoniserad installation göra en märkbar skillnad. Fördelar med Fördröjning ger. För NVMe använder jag vanligtvis Noop eller mq-deadline, medan mq-deadline är bättre för långa köer på hårddiskar. Om CPU:n allokerar tid i tid men I/O-vägen stannar upp, upphävs den övergripande effekten. Jag kontrollerar därför I/O-schemaläggaren parallellt med CFS-parametrarna. Jag ger en översikt över Noop, mq-deadline och BFQ här: I/O-planerare i jämförelse.

För databasvärdar justerar jag ködjup och read-ahead så att CFS-schemalagda slots inte försvinner på grund av blockerande I/O. Webbserverboxar med många små filer drar nytta av låg latens i I/O-stacken. I virtualiseringsscenarier förlitar jag mig på konsekventa schemaläggare på värd och gäst för att undvika oförutsägbara mönster. Så här interagerar CPU-schemaläggaren med lagringssubsystemet. I slutändan är det den sammanhängande kedjan från begäran till svar som räknas.

SMP-balansering, kärnaffinitet och NUMA

Jag styr trådar till fasta kärnor så att Cacher kostnader för uppvärmning och migration liten förbli. För NUMA-värdar kopplar jag ihop minne och CPU eftersom fjärråtkomst till minne ökar latensen. CFS balanserar belastningen mellan körköer, men medvetna affinitetsregler ger ofta mer. Tjänster med frekvent cacheåtkomst drar nytta av stabila kärngrupper. Batchjobb får röra sig fritt så länge de inte stör de heta kärnorna.

I praktiken ställer jag in alternativen cpuset.cpus och numactl och testar sedan svarstider och CPU-missfrekvenser. Ju färre onödiga migreringar, desto bättre blir svarstiden. Jag utvärderar också avbrottsfördelningen så att hårda IRQ-toppar inte blockerar en kärna. På så sätt uppnår jag en jämn klockning av de viktiga trådarna. Detta lugn betalar sig i den övergripande stackprestandan.

Gruppschemaläggning: trevligt, viktning och hierarkier

En vanlig stötesten när det gäller hosting är Interaktion mellan trevlig-Prioriteringar och C-gruppens vikter. CFS fördelar först rättvist mellan grupper och sedan inom gruppen mellan olika uppgifter. Det innebär att en process med nice -5 ändå kan få mindre CPU än en annan med nice 0 om dess grupp (client/container) har en lägre vikt. För att få konsekventa resultat ställer jag därför först in Gruppens vikter och använd "nice" endast för finjustering inom en tjänst.

I praktiken arbetar jag med några tydliga nivåer (t.ex. 512/1024/2048 aktier för “låg/normal/hög”) och dokumenterar vilka tjänster som körs i vilken grupp. Detta håller Rättvisa spårbara i hierarkin. De som arbetar mycket med kortlivade processer (t.ex. CGI/CLI-jobb) har också nytta av cgruppbaserad kontroll, eftersom flyktiga uppgifter annars skulle kringgå gruppkorsetten oavsiktligt. Jag använder regelbundet runtime-metriker för att kontrollera om den interna allokeringen fortfarande matchar belastningsprofilen.

Containrar och orkestrering: förfrågningar, gränser och strypning

I containermiljöer motsvarar en “begäran” vanligtvis relativ vikt (andelar/vikt), en “limit” på Kvotering (cpu.max). Interaktionen beslutar om Strypning: Om kvoten är för snäv saktas containerprocessorn ner inom perioden - vilket syns i p95/p99-latenscy studsar. Jag håller därför kvoterna på ett sådant sätt att normala utbrott passar in i perioden och att tjänsterna sällan stryps hårt. Där det är tillgängligt använder jag en Burst-reserve (t.ex. cpu.max.burst) för att dämpa korta toppar utan störningar.

Det är viktigt att inte ställa in kraven för lågt: Om vikterna är för låga kommer de interaktiva tjänsterna att hamna efter batchbruset. Jag kalibrerar förfrågningar baserat på den uppmätta basbelastningen och säkra gränser så att Felbudgetar upprätthålls under topptider. För noder med flera hyresgäster planerar jag också buffertkärnor så att belastningstoppar för enskilda containrar inte påverkar grannarna.

Mätmetoder och felsökning i schemaläggningssammanhang

Jag bedömer aldrig CFS-tuning i blindo, utan mäter den på ett målinriktat sätt. Jag använder för överblicken:

Längd på körkön per CPU (belastning vs. aktiva kärnor),
Förändrad kontext per sekund och antal trådar,
CPU-stöld och SoftIRQ-aktier,
Percentil av svarstider (p50/p95/p99),
Fördelning av vruntime eller planeringsfördröjningar.

Om det uppstår fördröjningstoppar letar jag först efter Strypning (kvoten är förbrukad), sedan efter Migrationer (cache kall) och slutligen efter I/O-blockeringar (ködjup, lagringsmättnad). Jag tittar på väckningsmönster: Frekventa korta väckningar av många arbetare indikerar för fin granularitet eller chatty I/O. En ökad andel ksoftirqd på en kärna indikerar heta IRQ-köer - i det här fallet fördelar jag IRQ:er och aktiverar RPS/XPS så att nätverksbelastningen sprids mer.

Realtidsklasser, förköpsrätt och tick-kontroll

Förutom CFS finns följande realtidsklasser SCHED_FIFO/RR. De åsidosätter CFS: en felaktigt konfigurerad RT-tråd kan bokstavligen ta luften ur systemet. Jag tilldelar därför RT-Prio endast mycket selektivt (t.ex. för ljud/telemetri) och definierar tydliga vakthundar. För hosting är CFS med rena vikter vanligtvis tillräckligt.

Till FöreträdesrättValet av förköpsmodell (t.ex. “frivillig” kontra “full/dynamisk förköp”) ändrar förhållandet mellan latens och genomströmning. För webbstackar föredrar jag mer preemption, för rena batchvärdar mindre. Tick-optimeringar (nohz-modes) kan minska jitter, men bör användas med försiktighet. På isolerade kärnor kombinerar jag ibland nohz_full och Affinity så att heta trådar körs så ostört som möjligt - det är viktigt att system- och IRQ-belastningar inte oavsiktligt flyttas till dessa kärnor.

Virtualisering: KVM, vCPU-pinning och steal time

I hypervisor-miljön bestämmer värdschemaläggaren när vCPU:er kan köra. Skapa överbokningar Stöld-Tid i gästerna, vilket fungerar som “osynlig latens”. För latens-kritiska hyresgäster kopplar jag vCPU:er till fysiska kärnor och håller overcommit måttligt. Jag separerar också emulatortrådar (IO-trådar, vhost) från gästernas heta kärnor så att de inte stör varandra.

Jag undviker dubbel strypning: Om gästen redan använder cpu.max ställer jag inte in några ytterligare hårda kvoter för samma arbetsbelastning på värden. Frekvensstyrningen förblir värdens uppgift; gästerna gynnas indirekt om värdguvernören skalar rent med den faktiska arbetsbelastningen. För jämna latenser anser jag att stabilitet utöver rena maximala frekvenskörningar är viktigare än topp-GHz på papperet.

AutoNUMA, minneslokalisering och THP

NUMA kan vara en prestandaförbättring eller en prestandafälla. AutoNUMA hjälper ofta, men kan skapa ytterligare overhead om det finns många roamingtrådar. I hosting-stackar med tydliga tjänstegränser sätter jag CPU och Minne (cpuset.cpus och cpuset.mems) tillsammans. Detta innebär att heta data förblir lokala och CFS måste kompensera för färre migreringar.

Stora sidor (THP) sänker TLB-trycket, men passar inte alla profiler. För databaser kan “madvise” vara mer meningsfullt än ett allmänt “alltid”. Blockerande sidfel slår hårt mot interaktiv latens; jag planerar därför buffertar (sidcache, delad buffert) så att CFS-platser används produktivt och inte väntar på I/O- eller MMU-händelser. Detta kan mätas via sidfelsfrekvenser och cache miss-kurvor.

Nätverkssökväg: IRQ-styrning, RPS/XPS och busy polling

Många arbetsbelastningar på webben är NIC-dominerade. Jag distribuerar IRQ-köer på nätverkskortet över flera kärnor och behåller dem affin till arbetstrådarna så att väckningarna förblir lokala. RPS/XPS hjälper till att lösa soft hotspots om enskilda RX/TX-köer bär för mycket belastning. Om ksoftirqd blir synligt varm är detta en indikation på överflödiga SoftIRQs - jag utjämnar då flöden och ökar budgetparametrarna om det behövs utan att förlora rättvisan.

Valfri upptagen pollning kan vara meningsfull i mycket speciella inställningar med låg latens, men det kostar CPU-tid. Jag använder det sällan och bara om jag kan bevisa genom mätning att p99 sjunker avsevärt utan att stressa värden överlag. Normalt ger ren IRQ-affinitet, C-grupper och CFS-granularitet det bättre kostnads-nyttoförhållandet.

Outlook: Från CFS till EEVDF och metoder för användarutrymme

EEVDF utökar rättvis fördelning till att omfatta deadlines, vilket är märkbart kortare och mer förutsägbara Svar på frågor löften. Speciellt med interaktiva latensmål kan detta göra hela skillnaden. Jag håller ett vakande öga på kärnversionerna och testar EEVDF separat innan jag byter. Samtidigt blir schemaläggning i användarutrymmet via eBPF-mönster allt vanligare, vilket kan ge ytterligare kontroll beroende på arbetsbelastningen. CFS är fortfarande relevant för värdinfrastrukturer, men EEVDF kommer att etablera sig snabbt.

En tydlig migreringsväg är fortfarande viktig: tester, utrullning på utvalda värdar och sedan expansion. Detta är det enda sättet att hålla percentiler och felfrekvenser under kontroll. Jag håller benchmarks nära verkligheten, inklusive burst-faser och långsamma backends. Först därefter ingriper jag i live-miljöer. På så sätt kan framsteg göras utan obehagliga överraskningar.

Kortfattat sammanfattat

Linux Scheduler CFS ger rättvis distribution, bra integrationer och bra Kontroll om C-grupper. Med lämpliga sysctl-parametrar, ren affinitet och realistiska kvoter håller jag latenserna låga och genomströmningen hög. ULE, BFS eller EEVDF ger ytterligare hävstångseffekt för speciella mönster. Jag mäter, jämför och rullar ut förändringar stegvis för att begränsa riskerna. På så sätt förblir hostingen förutsägbar - och prestandan där den hör hemma.