{"id":20578,"date":"2026-08-12T13:59:33","date_gmt":"2026-08-12T11:59:33","guid":{"rendered":"https:\/\/webhosting.de\/cfs-scheduler-fair-scheduling-hosting\/"},"modified":"2026-08-12T13:59:33","modified_gmt":"2026-08-12T11:59:33","slug":"cfs-scheduler-fair-scheduling-hosting","status":"publish","type":"post","link":"https:\/\/webhosting.de\/da\/cfs-scheduler-fair-scheduling-hosting\/","title":{"rendered":"Kernel-scheduler CFS: S\u00e5dan forst\u00e5r du fair scheduling p\u00e5 hosting-servere"},"content":{"rendered":"<p>Jeg forklarer, hvordan <strong>CFS<\/strong> Scheduleren p\u00e5 hosting-serverne fordeler CPU-tiden retf\u00e6rdigt og sikrer, at svartiderne kan planl\u00e6gges. Her viser jeg konkret, hvordan <strong>vruntime<\/strong>, hvordan prioriteter og systemgr\u00e6nser spiller sammen, og hvilke justeringsmuligheder der virker i produktive ops\u00e6tninger.<\/p>\n\n<h2>Centrale punkter<\/h2>\n\n<p>For at give et godt overblik vil jeg sammenfatte de vigtigste aspekter, inden jeg g\u00e5r mere i dybden. Den <strong>Helt og holdent<\/strong> Fair Scheduler fordeler regnetiden retf\u00e6rdigt og prioriterer opgaver efter behov. P\u00e5 hosting-servere p\u00e5virker den latenstid, gennemstr\u00f8mning og fornemmelsen af stabilitet. Jeg vurderer praktiske tuningparametre, typiske arbejdsbelastninger og fornuftige gr\u00e6nser. Desuden viser jeg, hvordan jeg kombinerer Cgroups, CPU-quota og affinity. P\u00e5 den m\u00e5de forst\u00e5r jeg \u00e5rsagerne til ventetider og reagerer m\u00e5lrettet p\u00e5 <strong>\u00c6ndring af konteksten<\/strong>.<\/p>\n<p>F\u00f8lgende punkter hj\u00e6lper med hurtigt at f\u00e5 overblik:<\/p>\n<ul>\n  <li><strong>Retf\u00e6rdighed<\/strong> F\u00f8r toppr\u00e6station: retf\u00e6rdig CPU-fordeling frem for maksimal individuel ydeevne.<\/li>\n  <li><strong>vruntime<\/strong> styrer r\u00e6kkef\u00f8lgen: opgaver, der har lavere prioritet, behandles f\u00f8rst.<\/li>\n  <li><strong>C-grupper<\/strong> Begr\u00e6nsede budgetter: Tjenesterne fordeler ressourcerne p\u00e5 en kontrolleret m\u00e5de.<\/li>\n  <li><strong>Forsinkelse<\/strong> og granularitet: Finjustering af reaktion og effektivitet.<\/li>\n  <li><strong>Prioritet<\/strong> og nice: V\u00e6gtningen bestemmer r\u00e6kkef\u00f8lgen af udf\u00f8relsen.<\/li>\n<\/ul>\n\n\n<figure class=\"wp-block-image size-full is-resized\">\n  <img fetchpriority=\"high\" decoding=\"async\" src=\"https:\/\/webhosting.de\/wp-content\/uploads\/2026\/08\/serverraum-fair-scheduling-8247.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>S\u00e5dan fordeler CFS retf\u00e6rdigt: vruntime, v\u00e6gtning og r\u00f8d-sort-tr\u00e6<\/h2>\n\n<p>Bag retf\u00e6rdigheden ligger <strong>vruntime<\/strong>, alts\u00e5 en virtuel k\u00f8retid, der registrerer forbruget pr. opgave p\u00e5 en v\u00e6gtet m\u00e5de. Hver opgave akkumulerer vruntime, n\u00e5r den k\u00f8rer, og den, der har akkumuleret mindst, f\u00e5r lov til at k\u00f8re f\u00f8rst. Kernen placerer udf\u00f8rbare opgaver i et r\u00f8d-sort-tr\u00e6 og finder dermed hurtigt den opgave med det mindste \u201eeftersl\u00e6b\u201c. Dermed sparer jeg faste tidsintervaller og reducerer administrationsbyrden i den normale proces. Det vigtige er stadig <strong>v\u00e6gtning<\/strong>, som jeg p\u00e5virker via nice-v\u00e6rdier og dermed finjusterer den retf\u00e6rdige r\u00e6kkef\u00f8lge.<\/p>\n\n<p>P\u00e5 flerkernede systemer fordeler CFS opgaver pr. CPU-k\u00f8 og balancerer mellem kernerne. I den forbindelse observerer jeg, hvordan affinitet og NUMA-topologi p\u00e5virker k\u00f8retiderne. Hvis tr\u00e5de forbliver p\u00e5 \u00e9n kerne, reducerer de cache-misses og spilder mindre tid p\u00e5 migration. Skifter jeg for ofte kerne, stiger omkostningerne ved kontekstskift og cache. En velgennemt\u00e6nkt CPU-tildeling giver her m\u00e6rkbare <strong>Accenter<\/strong>.<\/p>\n\n<h2>Retf\u00e6rdighed kontra ydeevne p\u00e5 hosting-servere<\/h2>\n\n<p>P\u00e5 t\u00e6tbelastede servere konkurrerer webservere, databaser og worker-processer om de samme kerner, hvilket s\u00e6tter fokus p\u00e5 retf\u00e6rdighed. CFS sikrer en retf\u00e6rdig fordeling, men kan ved mange aktive opgaver kr\u00e6ve yderligere <strong>\u00c6ndring af konteksten<\/strong> generere. Hvis antallet af k\u00f8rende processer stiger kraftigt, \u00f8ges administrationsbyrden m\u00e6rkbart. Jeg s\u00f8rger derfor for en realistisk grad af parallelitet og holder antallet af tr\u00e5de inden for rammerne af I\/O- eller CPU-profilen. Hvis man \u00f8nsker at vurdere alternativer og supplerende l\u00f8sninger, kan man finde baggrundsinformation under <a href=\"https:\/\/webhosting.de\/da\/linux-scheduler-cfs-alternativ-hosting-kernelperf-boost\/\">Alternativer til CFS<\/a>, for at kunne indordne beslutninger.<\/p>\n\n<p>En retf\u00e6rdig fordeling betyder ikke, at man skal fordele blindt og j\u00e6vnt. Kritiske tjenester skal reagere mere p\u00e5lideligt i spidsbelastningsperioder end baggrundsopgaver. Det er netop derfor, jeg bruger prioriteter, kvoter og servicegrupper. P\u00e5 den m\u00e5de forbliver reaktionen fra <strong>API<\/strong> smidigt, mens batch-arbejdsbelastninger forts\u00e6tter \u2013 blot med nedsat ydeevne. Denne balance g\u00f8r de produktive v\u00e6rter m\u00e6rkbare <strong>mere konstant<\/strong>.<\/p>\n\n\n<figure class=\"wp-block-image size-full is-resized\">\n  <img decoding=\"async\" src=\"https:\/\/webhosting.de\/wp-content\/uploads\/2026\/08\/meeting_scheduler_server_8972.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Cgroups, CPU-kvote og affinitet i samspil<\/h2>\n\n<p>Jeg inddeler tjenesterne pr. kunde, container eller rolle i <strong>C-grupper<\/strong>, s\u00e5 hver klynge f\u00e5r et klart budget. Med CPU-kvoter og CPU-andele s\u00e6tter jeg faste gr\u00e6nser eller relative v\u00e6gtninger. P\u00e5 den m\u00e5de forhindrer jeg, at en st\u00f8jende nabo overbelaster maskinen. Derudover tildeler jeg tr\u00e5de til bestemte kerner via affinitet, n\u00e5r det er n\u00f8dvendigt, for at udnytte cacherne bedre. En god introduktion til <a href=\"https:\/\/webhosting.de\/da\/politikker-for-serverplanlaegning-retfaerdighed-ydeevne-hostingoptimering\/\">Planl\u00e6gningspolitikker<\/a> hj\u00e6lper med at strukturere strategier p\u00e5 en overskuelig m\u00e5de.<\/p>\n\n<p>N\u00e5r det g\u00e6lder web-stacks, opdeler jeg frontend, PHP-workere og databasen i grupper med passende andele. Cachesystemer som Redis eller Memcached f\u00e5r tilstr\u00e6kkelig CPU-kapacitet til elegant at h\u00e5ndtere spidsbelastninger. Sikkerhedskopieringer og komprimering k\u00f8rer i baggrunden med mindre andele. P\u00e5 noder med heterogen belastning indf\u00f8rer jeg kvoter pr. kunde, s\u00e5 hver kunde f\u00e5r en forudsigelig regnetid. Denne klarhed g\u00f8r det lettere <strong>Planl\u00e6gning af kapacitet<\/strong> og mindsker uventede h\u00e6ndelser.<\/p>\n\n<h2>Vigtige kerneparametre: latenstid og granularitet<\/h2>\n\n<p>N\u00e5r jeg finjusterer, bruger jeg is\u00e6r parametre, der vedr\u00f8rer <strong>Forsinkelse<\/strong> og granularitet. De bestemmer, hvor ofte CFS skifter, og hvor store de effektive tidsintervaller bliver. Mindre latenstider forbedrer reaktionstiden, men \u00f8ger overheadet. St\u00f8rre v\u00e6rdier sparer administrationstid, men kan forl\u00e6nge de enkelte svar. Jeg arbejder mig frem til profiler, m\u00e5ler og afstemmer resultatet i forhold til belastningsspidser, f\u00f8r jeg planl\u00e6gger yderligere skridt.<\/p>\n\n<p>Den f\u00f8lgende tabel viser centrale indstillinger med deres virkning og typiske anbefalinger til hostingmilj\u00f8er. V\u00e6rdierne er retningslinjer, ikke faste regler. Jeg tester altid \u00e6ndringer ved hj\u00e6lp af belastningstest og overv\u00e5gning. Hver platform reagerer lidt forskelligt, is\u00e6r n\u00e5r der er mange containere og virtuelle maskiner. Netop derfor dokumenterer jeg tilpasningerne omhyggeligt og implementerer dem trin for trin for at <strong>Risici<\/strong> til at s\u00e6nke.<\/p>\n\n<table>\n  <thead>\n    <tr>\n      <th>Parametre<\/th>\n      <th>Effekt<\/th>\n      <th>Bem\u00e6rkning vedr\u00f8rende hosting<\/th>\n    <\/tr>\n  <\/thead>\n  <tbody>\n    <tr>\n      <td>kernel.sched_latency_ns<\/td>\n      <td>Fastl\u00e6gger den m\u00e5l-k\u00f8retid for en fuld cyklus for alle opgaver<\/td>\n      <td>Forkort sm\u00e5 tal <strong>reaktion<\/strong>, \u00f8ger omkostningerne til planl\u00e6gning<\/td>\n    <\/tr>\n    <tr>\n      <td>kernel.sched_min_granularity_ns<\/td>\n      <td>Minimal varighed pr. opgave inden for latenstiden<\/td>\n      <td>Lidt st\u00f8rre ved CPU-kr\u00e6vende opgaver, mindre ved Web-Mix<\/td>\n    <\/tr>\n    <tr>\n      <td>kernel.sched_wakeup_granularity_ns<\/td>\n      <td>T\u00e6rskel, hvorfra opv\u00e5gnende opgaver f\u00e5r forrang<\/td>\n      <td>Jo h\u00f8jere, desto lavere preemption-frekvens; god mod thrash<\/td>\n    <\/tr>\n    <tr>\n      <td>kernel.sched_migration_cost_ns<\/td>\n      <td>Omkostningsfaktor ved kernel-migrering mellem kerner<\/td>\n      <td>En forh\u00f8jelse d\u00e6mper vandringen og fremmer cachen\u2014<strong>Hits<\/strong><\/td>\n    <\/tr>\n    <tr>\n      <td>kernel.sched_cfs_bandwidth_slice_us<\/td>\n      <td>Tidsinterval til CFS-b\u00e5ndbreddekontrol via kvote<\/td>\n      <td>Tilpas til arbejdsbelastning og kvotefrekvens<\/td>\n    <\/tr>\n    <tr>\n      <td>kernel.sched_autogroup_enabled<\/td>\n      <td>Grupperer interaktive opgaver automatisk<\/td>\n      <td>Test m\u00e5lrettet p\u00e5 servere; effekten afh\u00e6nger af belastningen<\/td>\n    <\/tr>\n  <\/tbody>\n<\/table>\n\n\n<figure class=\"wp-block-image size-full is-resized\">\n  <img decoding=\"async\" src=\"https:\/\/webhosting.de\/wp-content\/uploads\/2026\/08\/kernel-scheduler-cfs-hosting-7481.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Korrekt klassificering af arbejdsbelastningstyper<\/h2>\n\n<p>Jeg skelner mellem CPU-intensive, hukommelsesafh\u00e6ngige og I\/O-dominerede <strong>Arbejdsbyrder<\/strong>. CFS udm\u00e6rker sig ved blandede serveropgaver og klassisk CPU-belastning. Ved hukommelseskr\u00e6vende m\u00f8nstre er det ofte b\u00e5ndbredden eller latenstiden i hukommelsessystemet, der s\u00e6tter gr\u00e6nser, ikke scheduleren. I s\u00e5danne tilf\u00e6lde hj\u00e6lper det mere at bevare hukommelseslokaliteten og undg\u00e5 swapping. I meget st\u00e6rkt paralleliserede scenarier unders\u00f8ger jeg, om tr\u00e5dene udnytter kernerne fornuftigt eller blokerer hinanden. Hvis jeg reducerer un\u00f8dvendig parallelitet, falder overheadet, og maskinen virker m\u00e6rkbart <strong>mere flydende<\/strong>.<\/p>\n\n<p>Til web-frontends planl\u00e6gger jeg antallet af tr\u00e5de til lidt over antallet af kerner, da mange foresp\u00f8rgsler venter p\u00e5 I\/O. Databaser drager fordel af fornuftig parallelisering og veldefineret affinitet. Batch-jobs samler jeg i tidsvinduer, hvor brugertrafikken er lav. CPU-intensiv komprimering eller transkodning placerer jeg i egne grupper, s\u00e5 interaktiviteten ikke lider under det. Disse m\u00f8nstre begr\u00e6nser uventede h\u00e6ndelser og giver mig <strong>Kontrol<\/strong> om virkningen af hver enkelt \u00e6ndring.<\/p>\n\n<h2>At forst\u00e5 prioriteter, vigtighed og v\u00e6gtninger<\/h2>\n\n<p>Jeg bruger nice-v\u00e6rdier til at <strong>v\u00e6gtning<\/strong> at fasts\u00e6tte en prioritet for en proces og dermed dens andel af CPU-tid. Lavere \u00bbnice\u00ab-v\u00e6rdier betyder h\u00f8jere prioritet, mens h\u00f8jere \u00bbnice\u00ab-v\u00e6rdier begr\u00e6nser baggrundsopgaver. P\u00e5 den m\u00e5de sikrer jeg, at centrale tjenester reagerer p\u00e5lideligt, mens vedligeholdelsesopgaver tr\u00e6der i baggrunden. Derudover holder jeg \u00f8je med, hvor mange opgaver pr. gruppe der er aktive samtidigt, da dette yderligere p\u00e5virker fordelingen. Et overblik over klassificeringen af <a href=\"https:\/\/webhosting.de\/da\/server-cpu-scheduler-klasseplanlaegning\/\">Scheduler-klasser<\/a> bruger jeg til klart at skelne mellem CFS og realtidsklasser.<\/p>\n\n<p>Det er vigtigt at v\u00e6re konsekvent: Jeg dokumenterer indstillingerne og s\u00f8rger for, at de forbliver ens p\u00e5 tv\u00e6rs af deployments. Forskellige v\u00e6gtninger pr. fase skaber ellers effekter, der er sv\u00e6re at forklare. Hvis jeg s\u00f8rger for konsistens, finder jeg hurtigere \u00e5rsagerne til afvigelser. Sm\u00e5, overskuelige trin g\u00f8r det lettere at rulle tilbage, hvis det bliver n\u00f8dvendigt. P\u00e5 den m\u00e5de forbliver effekten af <strong>Prioriteringer<\/strong> gennemsigtig.<\/p>\n\n\n<figure class=\"wp-block-image size-full is-resized\">\n  <img loading=\"lazy\" decoding=\"async\" src=\"https:\/\/webhosting.de\/wp-content\/uploads\/2026\/08\/fair_scheduling_server_2390.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Virtualisering og containere: To niveauer for retf\u00e6rdig fordeling<\/h2>\n\n<p>P\u00e5 hypervisorer konkurrerer virtuelle maskiner om v\u00e6rts-CPU\u2019er, mens CFS koordinerer processer i g\u00e6stinstansen. Jeg fasts\u00e6tter vCPU\u2019er p\u00e5 et realistisk grundlag i stedet for at komme med tomme l\u00f8fter, der under pres <strong>stj\u00e6le<\/strong>. I containere anvender jeg CPU-andele og kvoter, s\u00e5 spidsbelastninger fra enkelte tjenester ikke p\u00e5virker hele noden. Kombinationen af v\u00e6rtsallokering og g\u00e6st-fairness sikrer, at latenstiderne kan planl\u00e6gges. Kun med klare budgetter forbliver brugeroplevelsen behagelig og <strong>P\u00e5lidelig<\/strong>.<\/p>\n\n<p>P\u00e5 NUMA-systemer tager jeg desuden h\u00f8jde for hukommelseslokalitet. N\u00e5r containere flytter sig vilk\u00e5rligt mellem sockets, stiger hukommelsesforsinkelserne og neds\u00e6tter gennemstr\u00f8mningen. Derfor binder jeg f\u00f8lsomme tjenester til bestemte noder og s\u00f8rger for passende memory-binding. Dette samspil reducerer bivirkninger og bidrager til ensartede svartider. CFS forbliver herved det centrale <strong>Forekomst<\/strong> pr. CPU-k\u00f8.<\/p>\n\n<h2>Overv\u00e5gning og gradvis finjustering i praksis<\/h2>\n\n<p>Jeg starter med standardkonfigurationen, m\u00e5ler og foretager f\u00f8rst derefter \u00e6ndringer. N\u00f8gletal som run-queue-l\u00e6ngde, kontekstskiftefrekvens, CPU-udnyttelse og procentandele pr. Cgroup viser, hvor der er plads til forbedring. Mange kontekstskift med moderat CPU-belastning tyder p\u00e5 for fin granularitet. Lange k\u00f8er med h\u00f8j latenstid tyder p\u00e5 for mange aktive tr\u00e5de. I sidste ende er det afg\u00f8rende, om brugerhandlinger virker hurtigere, og om graferne viser den forventede <strong>Tendens<\/strong> vise.<\/p>\n\n<p>Jeg noterer hver eneste tilpasning med tidspunkt, omfang og m\u00e5l. Belastningstests f\u00f8r og efter \u00e6ndringen bekr\u00e6fter, at ideen holder. Hvis en tilgang sl\u00e5r fejl, fortryder jeg \u00e6ndringen og pr\u00f8ver en anden kombination. Jeg benytter separate testmilj\u00f8er, f\u00f8r jeg r\u00f8rer ved produktive systemer. Denne disciplin koster n\u00e6sten ingenting og sparer meget senere hen <strong>Tid<\/strong>.<\/p>\n\n<h2>Ydelsesprofiler for hosting: Praktiske scenarier<\/h2>\n\n<p>I en typisk WordPress-stack tildeler jeg Nginx\/Apache, PHP-FPM og Redis klare andele og holder antallet af PHP-workere lidt over antallet af kerner. Databasen prioriteres frem for batch-eksport, s\u00e5 betalingsprocessen og s\u00f8gningen forbliver flydende. Medietranskodning flytter jeg til \u201estille\u201c tidsvinduer eller indstiller strengere kvoter. P\u00e5 API-noder begr\u00e6nser jeg baggrundsjob mere for at d\u00e6mpe tail-latenstider. I alle tilf\u00e6lde tjekker jeg, om <strong>Svartid<\/strong> mere stabil, og gennemstr\u00f8mningen forbliver j\u00e6vn.<\/p>\n\n<p>I delte milj\u00f8er pr\u00e6senterer jeg kunderne for budgetter i euro pr. m\u00e5ned og oms\u00e6tter dem til klare CPU-andele. Gennemsigtighed forhindrer skuffelser og letter opsalg, n\u00e5r spidsbelastningerne stiger. M\u00e5linger underbygger disse samtaler, ikke mavefornemmelse. Jeg kan se, hvorn\u00e5r en kunde b\u00f8r \u00f8ge antallet af vCPU\u2019er eller gr\u00e6nserne. P\u00e5 den m\u00e5de udnyttes serverne p\u00e5 en fair m\u00e5de, og den samlede ydeevne forbliver <strong>konstant<\/strong>.<\/p>\n\n<h2>K\u00f8bsbeslutning og valg af hosting<\/h2>\n\n<p>N\u00e5r jeg vurderer tilbud, unders\u00f8ger jeg, hvor retf\u00e6rdigt CPU-tiden fordeles under belastning, og om isoleringen fungerer konsekvent. Den, der sammenligner hosting-, server- eller WordPress-pakker, skal v\u00e6re opm\u00e6rksom p\u00e5 klare kvoter, velordnede Cgroups og p\u00e5lidelige overv\u00e5gningsdata. Erfaringsrapporter og benchmarks viser, hvordan platformene reagerer i spidsbelastningsperioder. I sammenligninger dukker webhoster.de ofte op som testvinder, n\u00e5r CPU-retf\u00e6rdighed og isolering overbeviser p\u00e5 en synlig m\u00e5de. Jeg vurderer dette objektivt og s\u00f8rger for, at pris og <strong>Str\u00f8m<\/strong> der passer til profilen for ens egne arbejdsbelastninger.<\/p>\n\n<h2>Cgroup v2 i praksis: S\u00e5dan bruger du cpu.max og cpu.weight korrekt<\/h2>\n\n<p>P\u00e5 moderne distributioner foretr\u00e6kker jeg at bruge Cgroup v2. Der kalibrerer jeg CPU-budgetterne med <strong>cpu.max<\/strong> og <strong>cpu.v\u00e6gt<\/strong>. Med cpu.max fasts\u00e6tter jeg et fast tidsbudget pr. periode (f.eks. \u201e50 ms 100 ms\u201c for 50% p\u00e5 en CPU). Hvis det andet tal udelades, g\u00e6lder systemstandardindstillingen. Den <strong>v\u00e6gtning<\/strong> Jeg styrer det med cpu.weight (1\u201310000); p\u00e5 den m\u00e5de fordeler jeg den resterende kapacitet retf\u00e6rdigt, n\u00e5r flere grupper er aktive. For hver tjeneste dokumenterer jeg, om den har brug for faste gr\u00e6nser (f.eks. st\u00f8jende batch-jobs) eller snarere skal v\u00e6gtes relativt (API'er, databaser). Gennem konsistente v\u00e6gtninger pr. rolle forbliver v\u00e6rterne planbare og <strong>retf\u00e6rdigt<\/strong>.<\/p>\n\n<p>Det er vigtigt at finde den rette balance mellem v\u00e6gtning og kvote: En stram kvote beskytter naboer, men kan medf\u00f8re en tidlig begr\u00e6nsning ved korte spidsbelastninger. Hvis v\u00e6gtning alene er tilstr\u00e6kkelig, s\u00e6tter jeg kvoten gener\u00f8st eller udelader den helt. I spidsbelastningsperioder er det en fordel med en lidt st\u00f8rre v\u00e6gtning for interaktivitet, mens arkivering og rapporter kan klare sig med en moderat v\u00e6gtning.<\/p>\n\n<h2>CFS-b\u00e5ndbreddekontrol i detaljer: Periode, kvote og begr\u00e6nsning<\/h2>\n\n<p>CFS-b\u00e5ndbreddekontrollen begr\u00e6nser CPU-tiden pr. Cgroup inden for et defineret <strong>Periode<\/strong>. Normalt indstiller jeg \u00bbperiod\u00ab og \u00bbquota\u00ab (v1) henholdsvis \u00bbcpu.max\u00ab (v2). Hvis budgettet er opbrugt, <strong>d\u00e6mper<\/strong> CFS indtil n\u00e6ste periode. Netop her opst\u00e5r der let takker i latenskurven. Jeg undg\u00e5r skarpe kanter ved at indstille perioden og <strong>Skivest\u00f8rrelse<\/strong> (kernel.sched_cfs_bandwidth_slice_us) tilpasses arbejdsbelastningen: Mindre skiver fordeler udf\u00f8relsen mere pr\u00e6cist, men \u00f8ger overheadet. Ved tjenester med meget store bursts v\u00e6lger jeg en moderat periode (f.eks. 50\u2013100 ms) og tilstr\u00e6kkelig b\u00e5ndbredde, s\u00e5 typiske foresp\u00f8rgselsbursts kan genneml\u00f8be uden begr\u00e6nsning.<\/p>\n\n<p>Hvis jeg observerer hyppig begr\u00e6nsning af ydeevnen p\u00e5 trods af en lav samlet CPU-udnyttelse, er kvoten for lav. Jeg \u00f8ger budgettet i forhold til arbejdsbyrden eller anvender v\u00e6gtning i stedet for faste gr\u00e6nser. Hvis der kun opst\u00e5r kortvarige flaskehalse, fordeler jeg belastningstoppe p\u00e5 flere <strong>Arbejder<\/strong> med en let forskudt aktivitet, s\u00e5 perioderne ikke l\u00f8ber tomme p\u00e5 samme tid.<\/p>\n\n<h2>Effektiv anvendelse af SMT, IRQ-affinitet og kerneisolering<\/h2>\n\n<p>P\u00e5 systemer med <strong>SMT\/Hyper-Threading<\/strong> Jeg tager h\u00f8jde for, at to tr\u00e5de deler en kernes eksekveringsenheder. For latenstidsf\u00f8lsomme frontends foretr\u00e6kker jeg at samle aktive tr\u00e5de p\u00e5 egne fysiske kerner, mens baggrundsopgaver udfylder SMT-s\u00f8sterslots. Derudover indstiller jeg <strong>IRQ-affinitet<\/strong> til netv\u00e6rkskort og NVMe-k\u00f8er til passende CPU-s\u00e6t. P\u00e5 den m\u00e5de havner softirq\u2019erne t\u00e6t p\u00e5 de forbrugende <strong>Arbejdstr\u00e5de<\/strong>, antallet af cache-hits stiger, og jitteret falder.<\/p>\n\n<p>Hvis jeg har brug for h\u00e5rd isolering, reserverer jeg nogle f\u00e5 kerner via kerneparametre (f.eks. isolerede \u201ehousekeeping-frie\u201c kerner). Jeg flytter kun dedikerede tjenester samt deres interrupts derhen og holder systemtr\u00e5de v\u00e6k. I den forbindelse tester jeg omhyggeligt, s\u00e5 kerneltjenesterne ikke bliver underforsynet. Ofte er det nok med en klar affinitet uden fuld isolation for at opn\u00e5 stabile responstider.<\/p>\n\n<h2>Frekvensskalering: Governor og Turbo for konstant latenstid<\/h2>\n\n<p>Die <strong>CPU-frekvens<\/strong> p\u00e5virker tail-latenser m\u00e6rkbart. Med governor\u2019en \u201eschedutil\u201c f\u00f8lger klokfrekvensen n\u00f8je schedulerens opfattelse af udnyttelsen. Til latenstkritiske API\u2019er foretr\u00e6kker jeg dog ofte \u201eperformance\u201c-governoren eller \u00f8ger den minimale frekvens, s\u00e5 kernerne ikke falder ned i dybe P-tilstande. Turbo-Boost bruger jeg m\u00e5lrettet: Den fremskynder korte bursts, men kan udl\u00f8se temperaturreguleringen og d\u00e6mpe frekvenserne bagefter. Jeg m\u00e5ler reaktionstider med og uden Turbo og tr\u00e6ffer beslutningen for hver enkelt node. M\u00e5let er <strong>Constance<\/strong>, ikke maksimale v\u00e6rdier under laboratorieforhold.<\/p>\n\n<p>P\u00e5 blandede noder kombinerer jeg: nogle kerner fast indstillet til h\u00f8j ydeevne for interaktivitet, resten dynamisk til batch-behandling. Det er vigtigt at holde v\u00e6rtens energipolitik konsistent, s\u00e5 testene er reproducerbare, og s\u00e5 effekten af CFS-tuning ikke overskygges af str\u00f8mbesparelseslogikken.<\/p>\n\n<h2>Uddyb diagnosen: Tracepoints, perf og Sched-statistikker<\/h2>\n\n<p>Hvis virkningerne stadig er uklare, g\u00e5r jeg et niveau dybere. Ved hj\u00e6lp af perf og tracepoints unders\u00f8ger jeg <strong>V\u00e6kning<\/strong>, kontekstskift og ventetider i Runqueue. Fund som \u201emange pr\u00e6emptions kort efter wakeup\u201c tyder p\u00e5 for lav wakeup_granularity eller overdreven parallelitet. \/proc\/schedstat og \/proc\/sched_debug viser k\u00f8retider, migrationsrater og fordeling pr. CPU. Jeg korrelerer disse v\u00e6rdier med Cgroup-andele og applikationsmetrikkerne, indtil <strong>\u00c5rsag<\/strong> kan opfanges som en latensb\u00f8lge.<\/p>\n\n<p>Merv\u00e6rdien opst\u00e5r gennem sammenligning: de samme tests f\u00f8r og efter en \u00e6ndring, identiske belastningsm\u00f8nstre, faste tidsvinduer. F\u00f8rst da foretager jeg en revurdering. Hvis m\u00e5lekurverne er st\u00f8jfyldte, reducerer jeg variablerne (f.eks. fast frekvens, konstant antal tr\u00e5de), f\u00f8r jeg tager fat p\u00e5 yderligere justeringsmuligheder.<\/p>\n\n\n<figure class=\"wp-block-image size-full is-resized\">\n  <img loading=\"lazy\" decoding=\"async\" src=\"https:\/\/webhosting.de\/wp-content\/uploads\/2026\/08\/kernel_scheduler_cfs_8945.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>I\/O og netv\u00e6rk i fokus: Softirqs, RPS\/RFS og blok-scheduler<\/h2>\n\n<p>CPU-Fairness virker kun, hvis datavejen kan f\u00f8lge med. Jeg sorterer <strong>Softirqs<\/strong> (ksoftirqd) tildeles applikationens CPU'er, s\u00e5 pakker og behandling foreg\u00e5r p\u00e5 samme sted. Med distribuerede NIC-k\u00f8er og passende affinitet aflaster jeg hotspots. Ved h\u00f8j netv\u00e6rksgennemstr\u00f8mning hj\u00e6lper RPS\/RFS- og XPS-indstillinger med at fordele belastningen bredere. P\u00e5 lagringssiden s\u00f8rger jeg for en passende blok-I\/O-scheduler og Cgroup-I\/O-kontrol, s\u00e5 I\/O-kr\u00e6vende processer ikke indirekte reducerer andres CPU-tid. P\u00e5 den m\u00e5de undg\u00e5r jeg, at retf\u00e6rdighed p\u00e5 CPU-niveau bliver kompromitteret af <strong>Eftersl\u00e6b<\/strong> modarbejdes i I\/O-stien.<\/p>\n\n<p>Til arbejdsbelastninger med io_uring eller intensiv asynkron I\/O afs\u00e6tter jeg egne CPU-s\u00e6t eller -grupper til I\/O-hj\u00e6lpetr\u00e5dene, s\u00e5 de ikke konkurrerer med frontend-arbejdertr\u00e5dene om det samme budget.<\/p>\n\n<h2>Anti-m\u00f8nstre og gennempr\u00f8vede strategier<\/h2>\n\n<p>I praksis st\u00f8der jeg p\u00e5 tilbagevendende m\u00f8nstre, der \u00f8del\u00e6gger svartiderne. Jeg undg\u00e5r dem konsekvent:<\/p>\n<ul>\n  <li>For mange <strong>Tr\u00e5de<\/strong> Ved CPU-afh\u00e6ngige tjenester: Jeg starter t\u00e6t p\u00e5 det optimale antal kerner og skalerer horisontalt i stedet for at starte hundredvis af arbejdsprocesser.<\/li>\n  <li>For sn\u00e6ver <strong>Odds<\/strong> med kort periode: Det f\u00f8rer til throttle-b\u00f8lger. Bedre: Brug lidt mere budget eller v\u00e6gtning.<\/li>\n  <li>Uklare <strong>affinitet<\/strong>: Migrerende tr\u00e5de, der g\u00e5r p\u00e5 kompromis med cache-lokaliteten. Jeg fastl\u00e5ser hotpaths og deres interrupts konsekvent.<\/li>\n  <li>Blandet <strong>Etaper<\/strong> med forskellige nice-\/v\u00e6gt-v\u00e6rdier: Det skaber overraskelser. Jeg harmoniserer standardindstillingerne.<\/li>\n  <li>Autogroup pauschal aktiv: P\u00e5 serverne tester jeg effekten m\u00e5lrettet; interaktive desktop-optimeringer hj\u00e6lper ikke altid i datacentret.<\/li>\n<\/ul>\n\n<p>Mine playbooks er n\u00f8gterne: F\u00f8rst skal der skabes gennemsigtighed (metrikker, traces), derefter grove justeringsmuligheder (threads, cgroups), og f\u00f8rst derefter finjustering (latens, granularitet). Hver \u00e6ndring forbliver reversibel og dokumenteres. P\u00e5 den m\u00e5de forbliver milj\u00f8et h\u00e5ndterbart og <strong>forudsigelig<\/strong>.<\/p>\n\n\n<figure class=\"wp-block-image size-full is-resized\">\n  <img loading=\"lazy\" decoding=\"async\" src=\"https:\/\/webhosting.de\/wp-content\/uploads\/2026\/08\/hosting-serverraum-7482.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Kort opsummeret<\/h2>\n\n<p>Der <strong>CFS<\/strong> Scheduleren fordeler CPU-tiden retf\u00e6rdigt, opretholder en h\u00f8j interaktivitet og er fortsat det bedste udgangspunkt for blandede hosting-arbejdsbelastninger. Det afg\u00f8rende er passende gr\u00e6nser med Cgroups, realistisk parallelitet og klare prioriteter. Jeg justerer kun latenstids- og granularitetsv\u00e6rdier, hvis m\u00e5linger viser en flaskehals. Derefter kontrollerer jeg effekten og justerer indstillingerne tilbage, hvis resultatet ikke er tilfredsstillende. Med denne pragmatiske fremgangsm\u00e5de sikrer jeg konstante <strong>Svartider<\/strong> og forudsigelige kapaciteter \u2013 uden at overbelaste maskinen.<\/p>","protected":false},"excerpt":{"rendered":"<p>CFS Scheduler forklaret: Fair Scheduling i Linux-kernen til hosting-servere, ydeevne og optimal CPU-fordeling.<\/p>","protected":false},"author":1,"featured_media":20571,"comment_status":"","ping_status":"","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"inline_featured_image":false,"footnotes":""},"categories":[676],"tags":[],"class_list":["post-20578","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-server_vm"],"acf":[],"_wp_attached_file":null,"_wp_attachment_metadata":null,"litespeed-optimize-size":null,"litespeed-optimize-set":null,"_elementor_source_image_hash":null,"_wp_attachment_image_alt":null,"stockpack_author_name":null,"stockpack_author_url":null,"stockpack_provider":null,"stockpack_image_url":null,"stockpack_license":null,"stockpack_license_url":null,"stockpack_modification":null,"color":null,"original_id":null,"original_url":null,"original_link":null,"unsplash_location":null,"unsplash_sponsor":null,"unsplash_exif":null,"unsplash_attachment_metadata":null,"_elementor_is_screenshot":null,"surfer_file_name":null,"surfer_file_original_url":null,"envato_tk_source_kit":null,"envato_tk_source_index":null,"envato_tk_manifest":null,"envato_tk_folder_name":null,"envato_tk_builder":null,"envato_elements_download_event":null,"_menu_item_type":null,"_menu_item_menu_item_parent":null,"_menu_item_object_id":null,"_menu_item_object":null,"_menu_item_target":null,"_menu_item_classes":null,"_menu_item_xfn":null,"_menu_item_url":null,"_trp_menu_languages":null,"rank_math_primary_category":null,"rank_math_title":null,"inline_featured_image":null,"_yoast_wpseo_primary_category":null,"rank_math_schema_blogposting":null,"rank_math_schema_videoobject":null,"_oembed_049c719bc4a9f89deaead66a7da9fddc":null,"_oembed_time_049c719bc4a9f89deaead66a7da9fddc":null,"_yoast_wpseo_focuskw":null,"_yoast_wpseo_linkdex":null,"_oembed_27e3473bf8bec795fbeb3a9d38489348":null,"_oembed_c3b0f6959478faf92a1f343d8f96b19e":null,"_trp_translated_slug_en_us":null,"_wp_desired_post_slug":null,"_yoast_wpseo_title":null,"tldname":null,"tldpreis":null,"tldrubrik":null,"tldpolicylink":null,"tldsize":null,"tldregistrierungsdauer":null,"tldtransfer":null,"tldwhoisprivacy":null,"tldregistrarchange":null,"tldregistrantchange":null,"tldwhoisupdate":null,"tldnameserverupdate":null,"tlddeletesofort":null,"tlddeleteexpire":null,"tldumlaute":null,"tldrestore":null,"tldsubcategory":null,"tldbildname":null,"tldbildurl":null,"tldclean":null,"tldcategory":null,"tldpolicy":null,"tldbesonderheiten":null,"tld_bedeutung":null,"_oembed_d167040d816d8f94c072940c8009f5f8":null,"_oembed_b0a0fa59ef14f8870da2c63f2027d064":null,"_oembed_4792fa4dfb2a8f09ab950a73b7f313ba":null,"_oembed_33ceb1fe54a8ab775d9410abf699878d":null,"_oembed_fd7014d14d919b45ec004937c0db9335":null,"_oembed_21a029d076783ec3e8042698c351bd7e":null,"_oembed_be5ea8a0c7b18e658f08cc571a909452":null,"_oembed_a9ca7a298b19f9b48ec5914e010294d2":null,"_oembed_f8db6b27d08a2bb1f920e7647808899a":null,"_oembed_168ebde5096e77d8a89326519af9e022":null,"_oembed_cdb76f1b345b42743edfe25481b6f98f":null,"_oembed_87b0613611ae54e86e8864265404b0a1":null,"_oembed_27aa0e5cf3f1bb4bc416a4641a5ac273":null,"_oembed_time_27aa0e5cf3f1bb4bc416a4641a5ac273":null,"_tldname":null,"_tldclean":null,"_tldpreis":null,"_tldcategory":null,"_tldsubcategory":null,"_tldpolicy":null,"_tldpolicylink":null,"_tldsize":null,"_tldregistrierungsdauer":null,"_tldtransfer":null,"_tldwhoisprivacy":null,"_tldregistrarchange":null,"_tldregistrantchange":null,"_tldwhoisupdate":null,"_tldnameserverupdate":null,"_tlddeletesofort":null,"_tlddeleteexpire":null,"_tldumlaute":null,"_tldrestore":null,"_tldbildname":null,"_tldbildurl":null,"_tld_bedeutung":null,"_tldbesonderheiten":null,"_oembed_ad96e4112edb9f8ffa35731d4098bc6b":null,"_oembed_8357e2b8a2575c74ed5978f262a10126":null,"_oembed_3d5fea5103dd0d22ec5d6a33eff7f863":null,"_eael_widget_elements":null,"_oembed_0d8a206f09633e3d62b95a15a4dd0487":null,"_oembed_time_0d8a206f09633e3d62b95a15a4dd0487":null,"_aioseo_description":null,"_eb_attr":null,"_eb_data_table":null,"_oembed_819a879e7da16dd629cfd15a97334c8a":null,"_oembed_time_819a879e7da16dd629cfd15a97334c8a":null,"_acf_changed":null,"_wpcode_auto_insert":null,"_edit_last":null,"_edit_lock":null,"_oembed_e7b913c6c84084ed9702cb4feb012ddd":null,"_oembed_bfde9e10f59a17b85fc8917fa7edf782":null,"_oembed_time_bfde9e10f59a17b85fc8917fa7edf782":null,"_oembed_03514b67990db061d7c4672de26dc514":null,"_oembed_time_03514b67990db061d7c4672de26dc514":null,"rank_math_news_sitemap_robots":null,"rank_math_robots":null,"_eael_post_view_count":"94","_trp_automatically_translated_slug_ru_ru":null,"_trp_automatically_translated_slug_et":null,"_trp_automatically_translated_slug_lv":null,"_trp_automatically_translated_slug_fr_fr":null,"_trp_automatically_translated_slug_en_us":null,"_wp_old_slug":null,"_trp_automatically_translated_slug_da_dk":null,"_trp_automatically_translated_slug_pl_pl":null,"_trp_automatically_translated_slug_es_es":null,"_trp_automatically_translated_slug_hu_hu":null,"_trp_automatically_translated_slug_fi":null,"_trp_automatically_translated_slug_ja":null,"_trp_automatically_translated_slug_lt_lt":null,"_elementor_edit_mode":null,"_elementor_template_type":null,"_elementor_version":null,"_elementor_pro_version":null,"_wp_page_template":null,"_elementor_page_settings":null,"_elementor_data":null,"_elementor_css":null,"_elementor_conditions":null,"_happyaddons_elements_cache":null,"_oembed_75446120c39305f0da0ccd147f6de9cb":null,"_oembed_time_75446120c39305f0da0ccd147f6de9cb":null,"_oembed_3efb2c3e76a18143e7207993a2a6939a":null,"_oembed_time_3efb2c3e76a18143e7207993a2a6939a":null,"_oembed_59808117857ddf57e478a31d79f76e4d":null,"_oembed_time_59808117857ddf57e478a31d79f76e4d":null,"_oembed_965c5b49aa8d22ce37dfb3bde0268600":null,"_oembed_time_965c5b49aa8d22ce37dfb3bde0268600":null,"_oembed_81002f7ee3604f645db4ebcfd1912acf":null,"_oembed_time_81002f7ee3604f645db4ebcfd1912acf":null,"_elementor_screenshot":null,"_oembed_7ea3429961cf98fa85da9747683af827":null,"_oembed_time_7ea3429961cf98fa85da9747683af827":null,"_elementor_controls_usage":null,"_elementor_page_assets":[],"_elementor_screenshot_failed":null,"theplus_transient_widgets":null,"_eael_custom_js":null,"_wp_old_date":null,"_trp_automatically_translated_slug_it_it":null,"_trp_automatically_translated_slug_pt_pt":null,"_trp_automatically_translated_slug_zh_cn":null,"_trp_automatically_translated_slug_nl_nl":null,"_trp_automatically_translated_slug_pt_br":null,"_trp_automatically_translated_slug_sv_se":null,"rank_math_analytic_object_id":null,"rank_math_internal_links_processed":"1","_trp_automatically_translated_slug_ro_ro":null,"_trp_automatically_translated_slug_sk_sk":null,"_trp_automatically_translated_slug_bg_bg":null,"_trp_automatically_translated_slug_sl_si":null,"litespeed_vpi_list":null,"litespeed_vpi_list_mobile":null,"rank_math_seo_score":null,"rank_math_contentai_score":null,"ilj_limitincominglinks":null,"ilj_maxincominglinks":null,"ilj_limitoutgoinglinks":null,"ilj_maxoutgoinglinks":null,"ilj_limitlinksperparagraph":null,"ilj_linksperparagraph":null,"ilj_blacklistdefinition":null,"ilj_linkdefinition":null,"_eb_reusable_block_ids":null,"rank_math_focus_keyword":"CFS Scheduler","rank_math_og_content_image":null,"_yoast_wpseo_metadesc":null,"_yoast_wpseo_content_score":null,"_yoast_wpseo_focuskeywords":null,"_yoast_wpseo_keywordsynonyms":null,"_yoast_wpseo_estimated-reading-time-minutes":null,"rank_math_description":null,"surfer_last_post_update":null,"surfer_last_post_update_direction":null,"surfer_keywords":null,"surfer_location":null,"surfer_draft_id":null,"surfer_permalink_hash":null,"surfer_scrape_ready":null,"_thumbnail_id":"20571","footnotes":null,"_links":{"self":[{"href":"https:\/\/webhosting.de\/da\/wp-json\/wp\/v2\/posts\/20578","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/webhosting.de\/da\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/webhosting.de\/da\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/webhosting.de\/da\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/webhosting.de\/da\/wp-json\/wp\/v2\/comments?post=20578"}],"version-history":[{"count":0,"href":"https:\/\/webhosting.de\/da\/wp-json\/wp\/v2\/posts\/20578\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/webhosting.de\/da\/wp-json\/wp\/v2\/media\/20571"}],"wp:attachment":[{"href":"https:\/\/webhosting.de\/da\/wp-json\/wp\/v2\/media?parent=20578"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/webhosting.de\/da\/wp-json\/wp\/v2\/categories?post=20578"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/webhosting.de\/da\/wp-json\/wp\/v2\/tags?post=20578"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}