{"id":18553,"date":"2026-03-30T15:05:26","date_gmt":"2026-03-30T13:05:26","guid":{"rendered":"https:\/\/webhosting.de\/linux-scheduler-cfs-alternativen-hosting-kernelperf-boost\/"},"modified":"2026-03-30T15:05:26","modified_gmt":"2026-03-30T13:05:26","slug":"linux-scheduler-cfs-alternativ-hosting-kernelperf-boost","status":"publish","type":"post","link":"https:\/\/webhosting.de\/da\/linux-scheduler-cfs-alternativen-hosting-kernelperf-boost\/","title":{"rendered":"Linux Scheduler CFS: Funktionalitet og alternativer inden for serverhosting"},"content":{"rendered":"<p>Linux-planl\u00e6ggeren CFS styrer, hvordan serverkernerne tildeler deres tid til processer og har dermed direkte indflydelse p\u00e5 latenstid, gennemstr\u00f8mning og retf\u00e6rdighed i serverhosting. I denne guide forklarer jeg, hvordan den fungerer, tuningsh\u00e5ndtagene og nyttige alternativer som ULE, BFS og EEVDF til <strong>Hosting<\/strong> med <strong>webservere<\/strong>.<\/p>\n\n<h2>Centrale punkter<\/h2>\n\n<ul>\n  <li><strong>Retf\u00e6rdighed<\/strong> og <strong>vruntime<\/strong> bestemme, hvilken opgave der f\u00e5r CPU'en.<\/li>\n  <li><strong>C-grupper<\/strong> regulere kvoter og <strong>cpu.shares<\/strong> til kundeisolering.<\/li>\n  <li><strong>Indstilling af kernen<\/strong> via sched_latency_ns og <strong>Granularitet<\/strong>.<\/li>\n  <li><strong>Alternativer<\/strong> s\u00e5som BFS, ULE, EEVDF til s\u00e6rlige <strong>Arbejdsbyrder<\/strong>.<\/li>\n  <li><strong>\u00d8velse<\/strong>Kerneaffinitet, I\/O-planl\u00e6gger og <strong>Test<\/strong> kombinere.<\/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\/03\/linux-server-cfs-9357.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>S\u00e5dan fungerer CFS i den daglige hosting<\/h2>\n\n<p>Med Completely Fair Scheduler beslutter en virtuel runtime, hvilken opgave der skal k\u00f8re n\u00e6ste gang, hvilket resulterer i en <strong>Fair<\/strong> og forudsigelig <strong>Tildeling<\/strong> er oprettet. Hver opgave f\u00e5r CPU-tid proportionalt med nice-v\u00e6rdien, s\u00e5 en lav nice-v\u00e6rdi f\u00e5r flere shares. I hostingmilj\u00f8er deler mange sm\u00e5 webanmodninger, cronjobs og backups CPU'en mellem sig, uden at \u00e9n proces optager alt. Interaktive workloads som f.eks. NGINX-anmodninger nyder godt af hyppige, korte tidsintervaller, mens batch-opgaver f\u00e5r l\u00e6ngere blokke. Det betyder, at svartiderne forbliver p\u00e5lidelige for brugerne, selv om mange websteder behandler anmodninger parallelt.<\/p>\n\n<p>Jeg bruger Cgroups til at begr\u00e6nse kunder og tjenester, fordi cpu.shares og cpu.max sikrer klarhed. <strong>Andel i alt<\/strong> og h\u00e5rdt <strong>Gr\u00e6nser<\/strong>. En standardv\u00e6rdi p\u00e5 1024 shares for \u201cnormal\u201d og 512 for \u201cmindre vigtig\u201d fordeler kernerne p\u00e5 en forst\u00e5elig m\u00e5de. Med cpu.max indstiller jeg f.eks. 50 ms i en periode p\u00e5 100 ms, hvilket effektivt svarer til 50% CPU-andel. Denne ops\u00e6tning giver forudsigelige reserver til hosting af workloads med variabel belastning. Jeg kan finde en kompakt forklaring p\u00e5 princippet p\u00e5 <a href=\"https:\/\/webhosting.de\/da\/cpu-planlaegning-hosting-fair-distribution-server-hosting-ressourcer-optimal\/\">Retf\u00e6rdig CPU-fordeling<\/a>.<\/p>\n\n<h2>CFS-mekanik forklaret tydeligt<\/h2>\n\n<p>CFS administrerer alle opgaver, der er klar til at k\u00f8re, i et r\u00f8dt\/sort tr\u00e6, sorteret efter <strong>vruntime<\/strong> og med effektiv <strong>Udv\u00e6lgelse<\/strong> af den mindste virtuelle runtime. Denne opgave k\u00f8rer som den n\u00e6ste og \u00f8ger sin vruntime i forhold til den forbrugte CPU-tid og v\u00e6gtet via nice-v\u00e6rdien. Dette skaber en flydende balance uden h\u00e5rde k\u00f8er, som giver rene resultater, is\u00e6r med blandede arbejdsbelastninger. P\u00e5 systemer med flere kerner flytter planl\u00e6ggeren opgaver mellem k\u00f8rek\u00f8er, men er opm\u00e6rksom p\u00e5 cache-lokalitet via kerneaffinitet. P\u00e5 den m\u00e5de kombinerer CFS belastningsbalancering med s\u00e5 f\u00e5 dyre migreringer som muligt.<\/p>\n\n<p>Til finjustering s\u00e6tter parametre som sched_latency_ns og sched_min_granularity_ns kursen for <strong>Forsinkelse<\/strong> og <strong>Gennemstr\u00f8mning<\/strong>. Mindre latency-v\u00e6rdier favoriserer korte, interaktive jobs, mens st\u00f8rre v\u00e6rdier styrker batch-jobs. I tests med v\u00e6rkt\u00f8jer som stress-ng og fio tjekker jeg effekten p\u00e5 svartider og CPU-udnyttelse. N\u00e5r antallet af opgaver stiger, stiger ogs\u00e5 tr\u00e6ets administrative overhead, hvilket kan give sig udslag i h\u00f8je latenstider. Korrekt indstillede kvoter og gr\u00e6nser holder dog disse effekter i skak i hostingmilj\u00f8er.<\/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\/03\/linux_scheduler_cfs_meeting_4821.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>CFS' styrker inden for serverhosting<\/h2>\n\n<p>Den st\u00f8rste styrke ligger i <strong>Retf\u00e6rdighed<\/strong>, j\u00e6vnt og forst\u00e5eligt <strong>Ressourcer<\/strong> distribueret. For delte milj\u00f8er betyder det, at ingen kunder permanent fortr\u00e6nger andre, fordi kvoter og andele klart definerer v\u00e6gtningen. Interaktive tjenester f\u00e5r hurtige svartider, mens backups f\u00e5r lov til at k\u00f8re uden hastv\u00e6rk. Prioritering via p\u00e6ne v\u00e6rdier fuldender dette billede og giver mig plads til koordinering afh\u00e6ngigt af en tjenestes rolle. Load balancing p\u00e5 tv\u00e6rs af alle kerner giver mig mulighed for at udnytte den tilg\u00e6ngelige computerkraft uden at give Jeff moments individuelle tr\u00e5de for meget plads.<\/p>\n\n<p>I praksis viser CFS' styrke sig, n\u00e5r der er spidsbelastninger p\u00e5 webserveren, og der kommer mange korte anmodninger, da CFS afs\u00e6tter hyppige slots til denne type opgaver. Rene C-grupper hj\u00e6lper med at s\u00e6tte h\u00e5rde \u00f8vre gr\u00e6nser pr. kunde eller container. M\u00e5linger af gennemsnit og percentiler viser p\u00e5lidelige svartider, hvilket betaler sig i den daglige forretning. Denne tilgang er is\u00e6r nyttig for applikationsstakke med mange komponenter. Det er netop her, at blandingen af forudsigelig retf\u00e6rdighed og tilstr\u00e6kkelig fleksibilitet har stor betydning.<\/p>\n\n<h2>Gr\u00e6nser og typiske snublesten<\/h2>\n\n<p>Med et ekstremt stort antal samtidige opgaver \u00f8ges tr\u00e6operationernes overhead, hvilket ikke er tilf\u00e6ldet med <strong>Tips<\/strong> som <strong>Forsinkelse<\/strong> kan \u00f8ge ydeevnen. I hostingops\u00e6tninger med mange meget korte anmodninger sker der nogle gange hyppige kontekst\u00e6ndringer. En s\u00e5dan \u201cthrashing\u201d-adf\u00e6rd reducerer effektiviteten, hvis granularitetsv\u00e6rdierne v\u00e6lges forkert. F\u00e6rre, men l\u00e6ngere tidsintervaller kan hj\u00e6lpe, s\u00e5 l\u00e6nge interaktiviteten opretholdes. CFS reagerer f\u00f8lsomt p\u00e5 forkerte kvoter, og derfor kontrollerer jeg konsekvent gr\u00e6nserne med belastningstests.<\/p>\n\n<p>Selv affinitetsvenlige arbejdsbelastninger lider, hvis opgaverne hopper mellem kernerne for ofte. Et rent affinitetskoncept holder cachen varm og reducerer migrationsomkostningerne. Jeg kan ogs\u00e5 godt lide at binde st\u00f8jende batchjobs til deres egne kerner, s\u00e5 webforesp\u00f8rgsler k\u00f8rer stille og roligt p\u00e5 deres kerner. For latency-kritiske tjenester er det v\u00e6rd at indstille lave nice-v\u00e6rdier og en finjusteret latency. I sidste ende er det afg\u00f8rende, at m\u00e5lingerne bekr\u00e6fter de valgte parametre.<\/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\/03\/linux-scheduler-cfs-server-7012.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Sammenligning af alternativer: ULE, BFS og EEVDF<\/h2>\n\n<p>Til s\u00e6rlige arbejdsopgaver ser jeg p\u00e5 alternativer for at <strong>Forsinkelse<\/strong> eller <strong>Skalering<\/strong> prioriterer forskelligt. ULE bruger enklere k\u00f8er og scorer med mindre administrativ indsats, BFS prioriterer lydh\u00f8rhed og brillerer med f\u00e5 opgaver, og EEVDF kombinerer fair fordeling med deadlines. Is\u00e6r EEVDF lover kortere ventetider for interaktive belastninger, fordi planl\u00e6ggeren er mere opm\u00e6rksom p\u00e5 den \u201ctidligste tilladte deadline\u201d. For meget store serverfelter er det, der virkelig t\u00e6ller i sidste ende, hvilken blanding af effektivitet og planl\u00e6gbarhed, der virkelig vinder i din egen stak. Et struktureret kig p\u00e5 styrker, svagheder og anvendelsesomr\u00e5der hj\u00e6lper med udv\u00e6lgelsen.<\/p>\n\n<table>\n  <thead>\n    <tr>\n      <th>planl\u00e6gningsprogram<\/th>\n      <th>Kompleksitet<\/th>\n      <th>Styrker i hosting<\/th>\n      <th>Svagheder<\/th>\n      <th>Velegnet til<\/th>\n    <\/tr>\n  <\/thead>\n  <tbody>\n    <tr>\n      <td><strong>CFS<\/strong><\/td>\n      <td>H\u00f8j<\/td>\n      <td>Retf\u00e6rdig fordeling, <strong>C-grupper<\/strong><\/td>\n      <td>Toppen af ventetiden<\/td>\n      <td>Delt hosting, blandede belastninger<\/td>\n    <\/tr>\n    <tr>\n      <td><strong>ULE<\/strong><\/td>\n      <td>Lav<\/td>\n      <td>Enkle signaler, lav <strong>Belastning<\/strong><\/td>\n      <td>Mindre isolering<\/td>\n      <td>VM'er, HPC-lignende m\u00f8nstre<\/td>\n    <\/tr>\n    <tr>\n      <td><strong>BFS<\/strong><\/td>\n      <td>Medium<\/td>\n      <td>Interaktivitet, <strong>Hastighed<\/strong><\/td>\n      <td>Svag skalering<\/td>\n      <td>Desktops, sm\u00e5 servere<\/td>\n    <\/tr>\n    <tr>\n      <td><strong>EEVDF<\/strong><\/td>\n      <td>Medium<\/td>\n      <td>Lav latenstid, <strong>Deadlines<\/strong><\/td>\n      <td>Stadig lidt \u00f8velse<\/td>\n      <td>Moderne hosting-stakke<\/td>\n    <\/tr>\n  <\/tbody>\n<\/table>\n\n<h2>Kernel tuning: praktiske trin for CFS<\/h2>\n\n<p>For CFS skifter jeg ofte sched_autogroup_enabled=0, s\u00e5 ingen implicitte grupper forvr\u00e6nger billedet, og <strong>Fordeling af belastning<\/strong> klar <strong>rester<\/strong>. Med sched_latency_ns vil jeg gerne starte ved 20 ms, hvilket favoriserer interaktive tjenester, og justere sched_min_granularity_ns for at t\u00e6mme kontekst\u00e6ndringer. V\u00e6rdierne afh\u00e6nger af profilen: Mange korte webanmodninger kr\u00e6ver en anden finjustering end backup-vinduer. Jeg tester \u00e6ndringer serielt og m\u00e5ler percentiler i stedet for bare at se p\u00e5 gennemsnit. Det sikrer ikke kun, at gennemsnitsv\u00e6rdierne ser p\u00e6ne ud, men ogs\u00e5 at de lange k\u00f8er bliver mindre.<\/p>\n\n<p>Hvis du vil g\u00e5 dybere ind i sysctl-parametrene, kan du finde en god introduktion her: <a href=\"https:\/\/webhosting.de\/da\/kernel-tuning-linux-sysctl-parameter-serverboost-opti\/\">indstilling af sysctl<\/a>. Jeg indstiller ogs\u00e5 IRQ-fordelingen, CPU-guvern\u00f8ren og energiprofilerne, s\u00e5 CPU'en ikke konstant tipper over i \u00f8konomiske tilstande. Jeg bruger performance governors til latency-drevne stakke, mens rene batch-bokse lever med balanceret kontrol. Jeg adskiller klart test- og produktionsfaser, s\u00e5 der ikke er nogen overraskelser. Efter hvert trin tjekker jeg logfiler og metrikker, f\u00f8r jeg g\u00e5r videre.<\/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\/03\/linux_scheduler_cfs_tech_office_5278.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Brug cgroups og kvoter fornuftigt<\/h2>\n\n<p>Med cpu.shares tildeler jeg relative <strong>V\u00e6gte<\/strong> mens cpu.max er h\u00e5rd <strong>Gr\u00e6nser<\/strong> s\u00e6t. En kunde med 512 shares f\u00e5r halvt s\u00e5 meget computertid som en kunde med 1024, hvis begge genererer belastning p\u00e5 samme tid. Jeg bruger cpu.max til at begr\u00e6nse spidsbelastninger, f.eks. 50 ms p\u00e5 100 ms. Til dedikerede jobs er cpuset.cpus v\u00e6rd at bruge, s\u00e5 en tjeneste bruger faste kerner, og cachen forbliver varm. Alt i alt resulterer det i en modstandsdygtig adskillelse mellem kunder og tjenester.<\/p>\n\n<p>Jeg dokumenterer alle \u00e6ndringer og sammenligner dem med de serviceniveauer, jeg \u00f8nsker at opn\u00e5. Uden m\u00e5lte v\u00e6rdier f\u00f8rer andele hurtigt til fejlfortolkninger, og derfor ledsager jeg altid justeringer med belastningstests. For containere foresl\u00e5r jeg realistiske kvoter, som kan klare spidsbelastninger, men som ikke g\u00f8r v\u00e6rten langsommere. Det er fortsat vigtigt at have et forudsigeligt fejlbudget, s\u00e5 m\u00e6rkbare latenstidstoppe opdages. Hvis du g\u00f8r det konsekvent, undg\u00e5r du overraskelser i spidsbelastningsperioder.<\/p>\n\n<h2>\u00d8velse: Webserver og databaser under CFS<\/h2>\n\n<p>Event-drevne webservere reducerer kontekstskift og harmonerer med CFS, hvilket resulterer i m\u00e6rkbart konstante <strong>Svartider<\/strong> og bedre <strong>Skalering<\/strong> genereret. I tests ser jeg, at NGINX opretholder h\u00f8jere foresp\u00f8rgselshastigheder med mindre jitter p\u00e5 den samme hardware. Databaser reagerer positivt p\u00e5 kerneaffinitet, n\u00e5r baggrundsjobs holdes v\u00e6k fra de varme kerner. Enkle regler hj\u00e6lper: Web p\u00e5 kerne A-B, batch p\u00e5 C-D og DB p\u00e5 E-F. P\u00e5 den m\u00e5de holder stakken pipelinen ren og cacherne varme.<\/p>\n\n<p>Mange sm\u00e5 PHP FPM-arbejdere for\u00e5rsager for mange switches med aggressiv granularitet. S\u00e5 \u00f8ger jeg den mindste time slice og tjekker, om svartiderne forbliver stabile. Samtidig drosler jeg chatty logs, s\u00e5 I\/O ikke bliver en bremse. CFS udg\u00f8r grundlaget her, men den maksimale ydelse opn\u00e5s ved at finjustere hele stakken. P\u00e5 den m\u00e5de griber alle tandhjulene ind i hinanden uden at tage pusten fra v\u00e6rten.<\/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\/03\/linux_scheduler_server_hosting_8372.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Hukommelses-I\/O og CPU-planl\u00e6gning: samspillet<\/h2>\n\n<p>CPU-planl\u00e6ggeren og I\/O-planl\u00e6ggeren p\u00e5virker hinanden, og derfor kan en harmoniseret ops\u00e6tning g\u00f8re en m\u00e6rkbar forskel. <strong>Fordele<\/strong> med <strong>Forsinkelse<\/strong> bringer. Til NVMe bruger jeg normalt Noop eller mq-deadline, mens mq-deadline er bedre til lange k\u00f8er p\u00e5 HDD'er. Hvis CPU'en tildeler tid til tiden, men I\/O-stien g\u00e5r i st\u00e5, bliver den samlede effekt annulleret. Jeg tjekker derfor I\/O-planl\u00e6ggeren parallelt med CFS-parametre. Jeg giver et overblik over Noop, mq-deadline og BFQ her: <a href=\"https:\/\/webhosting.de\/da\/io-scheduler-linux-noop-mq-deadline-bfq-serverboost\/\">I\/O-planl\u00e6gger i sammenligning<\/a>.<\/p>\n\n<p>For databasev\u00e6rter justerer jeg k\u00f8-dybder og read-ahead, s\u00e5 CFS-planlagte slots ikke g\u00e5r i st\u00e5 p\u00e5 grund af blokerende I\/O. Webserverbokse med mange sm\u00e5 filer nyder godt af lav latenstid i I\/O-stakken. I virtualiseringsscenarier er jeg afh\u00e6ngig af konsistente planl\u00e6ggere p\u00e5 v\u00e6rten og g\u00e6sten for at undg\u00e5 uforudsigelige m\u00f8nstre. Det er s\u00e5dan, CPU-planl\u00e6ggeren interagerer med storage-subsystemet. I sidste ende er det den sammenh\u00e6ngende k\u00e6de fra anmodning til svar, der t\u00e6ller.<\/p>\n\n<h2>SMP-balancering, kerneaffinitet og NUMA<\/h2>\n\n<p>Jeg dirigerer tr\u00e5de til faste kerner, s\u00e5 <strong>Cacher<\/strong> varme- og migrationsomkostninger <strong>lille<\/strong> forblive. For NUMA-v\u00e6rter s\u00e6tter jeg hukommelse og CPU sammen, fordi fjernadgang til hukommelse \u00f8ger ventetiden. CFS afbalancerer belastningen mellem k\u00f8rek\u00f8er, men bevidste affinitetsregler f\u00e5r ofte mere ud af det. Tjenester med hyppig cacheadgang nyder godt af stabile kernegrupper. Batchjobs f\u00e5r lov til at vandre rundt, s\u00e5 l\u00e6nge de ikke forstyrrer de varme kerner.<\/p>\n\n<p>I praksis indstiller jeg cpuset.cpus og numactl, og s\u00e5 tester jeg foresp\u00f8rgselstider og CPU-missrate. Jo f\u00e6rre un\u00f8dvendige migreringer, jo bedre responstid. Jeg evaluerer ogs\u00e5 interruptfordelingen, s\u00e5 h\u00e5rde IRQ-toppe ikke tilstopper en kerne. P\u00e5 den m\u00e5de opn\u00e5r jeg en j\u00e6vn clockning af de vigtige tr\u00e5de. Denne ro betaler sig i den samlede stakydelse.<\/p>\n\n<h2>Gruppeplanl\u00e6gning: flot, v\u00e6gtning og hierarkier<\/h2>\n\n<p>En hyppig anst\u00f8dssten inden for hosting er <strong>Interaktion<\/strong> mellem <strong>nice<\/strong>-Prioriteringer og <strong>C-gruppens v\u00e6gte<\/strong>. CFS fordeler f\u00f8rst retf\u00e6rdigt mellem grupper og derefter inden for gruppen mellem opgaver. Det betyder, at en proces med nice -5 stadig kan f\u00e5 mindre CPU end en anden med nice 0, hvis dens gruppe (klient\/container) har en lavere v\u00e6gt. For at opn\u00e5 ensartede resultater indstiller jeg derfor f\u00f8rst <em>Gruppens v\u00e6gte<\/em> og brug kun nice til finjustering inden for en tjeneste.<\/p>\n\n<p>I praksis arbejder jeg med et par klare niveauer (f.eks. 512\/1024\/2048 shares for \u201clav\/normal\/h\u00f8j\u201d) og dokumenterer, hvilke tjenester der k\u00f8rer i hvilken gruppe. Dette holder <strong>Retf\u00e6rdighed<\/strong> kan spores i hierarkiet. Alle, der arbejder meget med kortvarige processer (f.eks. CGI\/CLI-jobs), har ogs\u00e5 gavn af <strong>cgruppe-baseret<\/strong> kontrol, fordi flygtige opgaver ellers ville omg\u00e5 gruppekorsettet utilsigtet. Jeg bruger j\u00e6vnligt runtime metrics til at tjekke, om den interne allokering stadig matcher belastningsprofilen.<\/p>\n\n<h2>Containere og orkestrering: anmodninger, gr\u00e6nser og neddrosling<\/h2>\n\n<p>I containermilj\u00f8er svarer en \u201canmodning\u201d typisk til <strong>relativ v\u00e6gt<\/strong> (aktier\/v\u00e6gt), en \u201cgr\u00e6nse\u201d p\u00e5 <strong>Kvote<\/strong> (cpu.max). Interaktionen beslutter sig for <strong>Neddrosling<\/strong>Hvis kvoten er for stram, bliver container-CPU'en bremset inden for perioden - synligt i p95\/p99 latency bounces. Jeg holder derfor kvoterne p\u00e5 en s\u00e5dan m\u00e5de, at normale udbrud passer ind i perioden, og at tjenesterne sj\u00e6ldent drosles h\u00e5rdt ned. Hvor det er muligt, bruger jeg en <em>Burst<\/em>-reserve (f.eks. cpu.max.burst) til at d\u00e6mpe korte spidsbelastninger uden forvr\u00e6ngninger.<\/p>\n\n<p>Det er vigtigt ikke at s\u00e6tte anmodninger for lavt: Hvis v\u00e6gten er for lav, vil interaktive tjenester falde bagud i forhold til batch-st\u00f8j. Jeg kalibrerer anmodninger baseret p\u00e5 den m\u00e5lte basisbelastning og sikre gr\u00e6nser, s\u00e5 <strong>Fejlbudgetter<\/strong> opretholdes i spidsbelastningsperioder. For knudepunkter med flere lejere planl\u00e6gger jeg ogs\u00e5 bufferkerner, s\u00e5 spidsbelastninger i individuelle containere ikke p\u00e5virker naboerne.<\/p>\n\n<h2>M\u00e5lemetoder og fejlfinding i planl\u00e6gningssammenh\u00e6ng<\/h2>\n\n<p>Jeg vurderer aldrig CFS-tuning blindt, men m\u00e5ler det m\u00e5lrettet. Jeg bruger det til at f\u00e5 overblik:<\/p>\n<ul>\n  <li><strong>Runqueue-l\u00e6ngde<\/strong> pr. CPU (belastning vs. aktive kerner),<\/li>\n  <li><strong>\u00c6ndring af konteksten<\/strong> pr. sekund og antal tr\u00e5de,<\/li>\n  <li><strong>CPU-stj\u00e6ler<\/strong> og <strong>SoftIRQ<\/strong>-aktier,<\/li>\n  <li><strong>Percentil<\/strong> af svartider (p50\/p95\/p99),<\/li>\n  <li>Fordeling af <strong>vruntime<\/strong> eller planl\u00e6gningsforsinkelser.<\/li>\n<\/ul>\n<p>Hvis der opst\u00e5r ventetidsspidser, kigger jeg f\u00f8rst efter <strong>Neddrosling<\/strong> (kvote opbrugt), derefter efter <strong>Migrationer<\/strong> (cache kold) og endelig efter <strong>I\/O-blokeringer<\/strong> (k\u00f8-dybde, lagerm\u00e6tning). Jeg ser p\u00e5 wakeup-m\u00f8nstre: Hyppige korte wakeups af mange workers indikerer for fin granularitet eller chatty I\/O. En \u00f8get andel af ksoftirqd p\u00e5 en kerne indikerer varme IRQ-k\u00f8er - i dette tilf\u00e6lde fordeler jeg IRQ'er og aktiverer RPS\/XPS, s\u00e5 netv\u00e6rksbelastningen spredes mere bredt.<\/p>\n\n<h2>Realtidsklasser, pr\u00e6emption og tick control<\/h2>\n\n<p>Ud over CFS findes der f\u00f8lgende realtidsklasser <strong>SCHED_FIFO\/RR<\/strong>. De tilsides\u00e6tter CFS: En forkert konfigureret RT-tr\u00e5d kan bogstaveligt talt tage luften ud af systemet. Derfor tildeler jeg kun RT-Prio meget selektivt (f.eks. til lyd\/telemetri) og definerer klare vagthunde. Til hosting er CFS med rene v\u00e6gte normalt tilstr\u00e6kkeligt.<\/p>\n\n<p>Til den <strong>Fortrinsret<\/strong>Valget af pr\u00e6emptionsmodel (f.eks. \u201cfrivillig\u201d vs. \u201cfuld\/dynamisk pr\u00e6emption\u201d) \u00e6ndrer forholdet mellem latenstid og gennemstr\u00f8mning. Til webstakke foretr\u00e6kker jeg mere preemption, til rene batch-hosts mindre. Tick-optimeringer (<em>nohz<\/em>-modes) kan reducere jitter, men b\u00f8r bruges med forsigtighed. P\u00e5 isolerede kerner kombinerer jeg af og til <em>nohz_full<\/em> og Affinity, s\u00e5 varme tr\u00e5de k\u00f8rer s\u00e5 uforstyrret som muligt - det er vigtigt, at system- og IRQ-belastninger ikke utilsigtet migrerer til disse kerner.<\/p>\n\n<h2>Virtualisering: KVM, vCPU-pinning og steal time<\/h2>\n\n<p>I hypervisor-milj\u00f8et bestemmer host-planl\u00e6ggeren, hvorn\u00e5r <strong>vCPU'er<\/strong> kan k\u00f8re. Skab overbookinger <strong>Tid til at stj\u00e6le<\/strong> i g\u00e6sterne, hvilket fungerer som \u201cusynlig latenstid\u201d. For latency-kritiske lejere knytter jeg vCPU'er til fysiske kerner og holder overcommit moderat. Jeg adskiller ogs\u00e5 emulatortr\u00e5de (IO-tr\u00e5de, vhost) fra g\u00e6sternes varme kerner, s\u00e5 de ikke forstyrrer hinanden.<\/p>\n\n<p>Jeg undg\u00e5r dobbeltdrosling: Hvis g\u00e6sten allerede bruger cpu.max, s\u00e6tter jeg ikke yderligere h\u00e5rde kvoter p\u00e5 v\u00e6rten for den samme arbejdsbyrde. Frekvensstyring er fortsat v\u00e6rtens opgave; g\u00e6sterne f\u00e5r indirekte gavn af det, hvis v\u00e6rtsguvern\u00f8ren skalerer rent med den faktiske arbejdsbyrde. For j\u00e6vne ventetider anser jeg stabilitet ud over rene maksimale frekvensk\u00f8rsler for at v\u00e6re vigtigere end peak GHz p\u00e5 papiret.<\/p>\n\n<h2>AutoNUMA, hukommelseslokalisering og THP<\/h2>\n\n<p>NUMA kan v\u00e6re en pr\u00e6stationsgevinst eller en pr\u00e6stationsf\u00e6lde. <strong>AutoNUMA<\/strong> hj\u00e6lper ofte, men kan skabe ekstra overhead, hvis der er mange roaming-tr\u00e5de. I hosting-stakke med klare servicegr\u00e6nser s\u00e6tter jeg CPU og <strong>Hukommelse<\/strong> (<em>cpuset.cpus<\/em> og <em>cpuset.mems<\/em>) sammen. Det betyder, at varme data forbliver lokale, og at CFS skal kompensere for f\u00e6rre migreringer.<\/p>\n\n<p>Store sider (<strong>THP<\/strong>) s\u00e6nker TLB-trykket, men passer ikke til alle profiler. For databaser kan \u201cmadvise\u201d give mere mening end et generelt \u201caltid\u201d. Blokerende sidefejl rammer den interaktive latenstid h\u00e5rdt; jeg planl\u00e6gger derfor buffere (sidecache, delt buffer), s\u00e5 CFS-slots bruges produktivt og ikke venter p\u00e5 I\/O- eller MMU-begivenheder. Dette kan m\u00e5les via page fault rates og cache miss-kurver.<\/p>\n\n<h2>Netv\u00e6rkssti: IRQ-kontrol, RPS\/XPS og busy polling<\/h2>\n\n<p>Mange web-arbejdsbelastninger er NIC-dominerede. Jeg distribuerer <strong>IRQ<\/strong>-k\u00f8er p\u00e5 netv\u00e6rkskortet over flere kerner og opbevar dem <em>affine<\/em> til arbejdstr\u00e5dene, s\u00e5 opv\u00e5gningerne forbliver lokale. <strong>RPS\/XPS<\/strong> hj\u00e6lper med at l\u00f8se bl\u00f8de hotspots, hvis individuelle RX\/TX-k\u00f8er b\u00e6rer for meget belastning. Hvis ksoftirqd bliver synligt varm, er det en indikation p\u00e5 overfyldte SoftIRQ'er - jeg udligner derefter flows og \u00f8ger budgetparametrene, hvis det er n\u00f8dvendigt, uden at miste retf\u00e6rdigheden.<\/p>\n\n<p>Valgfri busy polling kan give mening i meget specielle ops\u00e6tninger med lav latenstid, men det koster CPU-tid. Jeg bruger det sj\u00e6ldent, og kun hvis jeg ved hj\u00e6lp af m\u00e5linger kan bevise, at p99 falder markant uden at stresse v\u00e6rten generelt. Normalt giver ren IRQ-affinitet, Cgroups og CFS-granularitet et bedre cost-benefit-forhold.<\/p>\n\n<h2>Udsigt til fremtiden: Fra CFS til EEVDF og userspace-tilgange<\/h2>\n\n<p>EEVDF udvider fair distribution til at omfatte deadlines, hvilket er m\u00e6rkbart <strong>kortere<\/strong> og mere forudsigelig <strong>Svar p\u00e5 sp\u00f8rgsm\u00e5l<\/strong> l\u00f8fter. Is\u00e6r med interaktive latency-m\u00e5l kan det g\u00f8re hele forskellen. Jeg holder n\u00f8je \u00f8je med kerneversioner og tester EEVDF separat, f\u00f8r jeg skifter. Samtidig vinder userspace-planl\u00e6gning via eBPF-m\u00f8nstre frem, hvilket kan give yderligere kontrol afh\u00e6ngigt af arbejdsbyrden. CFS er fortsat relevant for hosting-infrastrukturer, men EEVDF vil hurtigt etablere sig.<\/p>\n\n<p>En klar migrationsvej er stadig vigtig: test, udrulning p\u00e5 udvalgte v\u00e6rter og derefter udvidelse. Det er den eneste m\u00e5de at holde percentiler og fejlrater under kontrol. Jeg holder benchmarks t\u00e6t p\u00e5 virkeligheden, inklusive burst-faser og langsomme backends. F\u00f8rst derefter griber jeg ind i live-milj\u00f8er. P\u00e5 den m\u00e5de kan der opn\u00e5s fremskridt uden ubehagelige overraskelser.<\/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\/03\/linux-scheduler-hosting-4783.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Kort opsummeret<\/h2>\n\n<p>Linux Scheduler CFS leverer fair distribution, solide integrationer og god <strong>Kontrol<\/strong> om <strong>C-grupper<\/strong>. Med passende sysctl-parametre, ren affinitet og realistiske kvoter holder jeg ventetiden lav og gennemstr\u00f8mningen h\u00f8j. ULE, BFS eller EEVDF giver yderligere muligheder for s\u00e6rlige m\u00f8nstre. Jeg m\u00e5ler, sammenligner og udruller \u00e6ndringer i etaper for at begr\u00e6nse risici. Det holder hosting forudsigelig - og performance, hvor den h\u00f8rer hjemme.<\/p>","protected":false},"excerpt":{"rendered":"<p>Linux Scheduler CFS forklaret: Hvordan det fungerer, cpu-planl\u00e6gningsserver og alternativer som EEVDF. Kernel-tuning for optimal hosting-ydelse.<\/p>","protected":false},"author":1,"featured_media":18546,"comment_status":"","ping_status":"","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"_crdt_document":"","inline_featured_image":false,"footnotes":""},"categories":[676],"tags":[],"class_list":["post-18553","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":"482","_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":"Linux Scheduler CFS","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":"18546","footnotes":null,"_links":{"self":[{"href":"https:\/\/webhosting.de\/da\/wp-json\/wp\/v2\/posts\/18553","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=18553"}],"version-history":[{"count":0,"href":"https:\/\/webhosting.de\/da\/wp-json\/wp\/v2\/posts\/18553\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/webhosting.de\/da\/wp-json\/wp\/v2\/media\/18546"}],"wp:attachment":[{"href":"https:\/\/webhosting.de\/da\/wp-json\/wp\/v2\/media?parent=18553"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/webhosting.de\/da\/wp-json\/wp\/v2\/categories?post=18553"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/webhosting.de\/da\/wp-json\/wp\/v2\/tags?post=18553"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}