{"id":20778,"date":"2026-08-18T18:23:16","date_gmt":"2026-08-18T16:23:16","guid":{"rendered":"https:\/\/webhosting.de\/linux-scheduler-latenz-messen-und-optimieren-performance\/"},"modified":"2026-08-18T18:23:16","modified_gmt":"2026-08-18T16:23:16","slug":"maling-af-latenstid-i-linux-scheduleren-og-optimering-af-ydeevnen","status":"publish","type":"post","link":"https:\/\/webhosting.de\/da\/linux-scheduler-latenz-messen-und-optimieren-performance\/","title":{"rendered":"M\u00e5ling og optimering af Linux-schedulerens latenstid for at opn\u00e5 bedre kerneydelse"},"content":{"rendered":"<p>Jeg m\u00e5ler latenstiden for <strong>Linux-scheduler<\/strong> m\u00e5lrettet, analyserer jeg afvigelser og optimerer parametre, indtil interaktive og realtids-workloads reagerer p\u00e5lideligt. P\u00e5 den m\u00e5de reducerer jeg systematisk scheduler-latensen og \u00f8ger <strong>Kernel-ydeevne<\/strong> uden at flyve i blinde.<\/p>\n\n<h2>Centrale punkter<\/h2>\n\n<ul>\n  <li><strong>M\u00e5lemetoder<\/strong>: perf sched, eBPF runqlat, schedstat og cyclictest giver et fuldst\u00e6ndigt overblik.<\/li>\n  <li><strong>V\u00e6rste tilf\u00e6lde<\/strong>: Uregelm\u00e6ssigheder dominerer brugeroplevelsen og realtidsfristerne.<\/li>\n  <li><strong>CFS-parametre<\/strong>: sched_latency_ns og tidsskiver er afg\u00f8rende for reaktionstiderne.<\/li>\n  <li><strong>Politikker<\/strong>: SCHED_FIFO\/RR\/DEADLINE prioriterer kritiske tr\u00e5de.<\/li>\n  <li><strong>Isolering<\/strong>: CPU-pinning og IRQ-tuning stabiliserer latenstiderne.<\/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\/linux-performance-2349.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Hvad betyder \u00bbscheduler-latens\u00ab i kernen?<\/h2>\n\n<p>Jeg definerer scheduler-latens som tiden mellem <strong>V\u00e6kke<\/strong> en opgave og det \u00f8jeblik, hvor dens kode k\u00f8rer efter kontekstskiftet. En interrupt afslutter en I\/O-ventetid, handleren markerer tr\u00e5den som k\u00f8reklar, scheduleren tr\u00e6ffer valget og igangs\u00e6tter skiftet. For interaktive systemer t\u00e6ller hver mikrosekund, men i hverdagen er det is\u00e6r <strong>V\u00e6rste tilf\u00e6lde<\/strong>-Latensen p\u00e5virker brugeroplevelsen. Selv enkelte hundrede millisekunder kan \u00f8del\u00e6gge brugeroplevelsen, selvom gennemsnitsv\u00e6rdien ser god ud. Netop derfor ser jeg p\u00e5 hele k\u00e6den i kernen, men fokuserer p\u00e5 afsnittet mellem \u00bbwakeup\u00ab og CPU-indgang.<\/p>\n\n<h2>Hvorfor den v\u00e6rst t\u00e6nkelige latenstid er vigtig<\/h2>\n\n<p>Jeg vurderer ikke kun gennemsnitsv\u00e6rdier, fordi et kort gennemsnit kan give h\u00f8je <strong>Tips<\/strong> kan skjule. Lyden kn\u00e6kker, n\u00e5r sj\u00e6ldne spidsbelastninger t\u00f8mmer bufferne, og handel mister sin timing, n\u00e5r tidsfrister overskrides. For desktop, servere og realtid g\u00e6lder det, at f\u00e5 afvigelser pr\u00e6ger <strong>Lydh\u00f8rhed<\/strong> mere end tusindvis af gode samples. Derfor g\u00e5r jeg efter smalle fordelinger og kontrollerede jitter-v\u00e6rdier. F\u00f8rst n\u00e5r maksimumsv\u00e6rdierne falder, opst\u00e5r der et j\u00e6vnt og forudsigeligt forl\u00f8b.<\/p>\n\n<h2>M\u00e5ling af scheduler-latens: V\u00e6rkt\u00f8jer og fremgangsm\u00e5de<\/h2>\n\n<p>Jeg begynder med <strong>perf<\/strong> og registrerer scheduler-begivenheder specifikt for hver arbejdsbelastning: \u201eperf sched record\u201c indsamler data, \u201eperf sched latency\u201c sorterer dem pr. opgave, \u201eperf sched timehist\u201c viser begivenheder med tidsm\u00e6rker. P\u00e5 den m\u00e5de kan jeg se ventetiden fra \u201esched-out\u201c til \u201esched-in\u201c, forsinkelsen mellem wakeup og den faktiske udf\u00f8relse samt den rene k\u00f8retid. Til en detaljeret CPU-analyse kombinerer jeg dette med denne vejledning: <a href=\"https:\/\/webhosting.de\/da\/linux-perf-vaerktoj-analyse-af-cpu-flaskehalse-optimering-serverbelastning-profilering\/\">perf til CPU-flaskehalse<\/a>. Dette perspektiv afsl\u00f8rer flaskehalse og viser, om \u00e5rsagen ligger i konflikter, prioriteter eller overhead.<\/p>\n\n<p>Med eBPF m\u00e5ler jeg k\u00f8tider direkte i <strong>Runqueue<\/strong>. Det s\u00e6dvanlige \u201erunqlat\u201c genererer histogrammer i nanosekund-intervaller, hvilket g\u00f8r det muligt for mig at identificere typiske zoner og sj\u00e6ldne udsving. S\u00e5danne fordelinger reagerer m\u00e6rkbart p\u00e5 CPU-isolering eller \u00e6ndringer i politikker og leverer dermed konkrete beviser til brug for finjustering. Jeg gentager m\u00e5lingerne f\u00f8r og efter \u00e6ndringerne, indtil toppene forsvinder. F\u00f8rst da vurderer jeg resultatet som tilfredsstillende.<\/p>\n\n<p>For enkelte opgaver bruger jeg \u201e\/proc\/\/schedstat\u201c og sammenligner andelene af CPU-k\u00f8rselstid, <strong>Runqueue<\/strong>-Ventetid og dvaletilstande. Ved at afl\u00e6se dataene med j\u00e6vne mellemrum f\u00e5r man n\u00f8gletal som CPU-procent, latenstidsprocent og dvaleprocent. P\u00e5 den m\u00e5de kan jeg hurtigt se, om processen k\u00e6mper om CPU-tid eller er blokeret p\u00e5 grund af I\/O. Denne klarhed forhindrer fejlagtige optimeringer, der rammer det forkerte sted. Som en supplerende test bruger jeg cyclictest med h\u00f8j prioritet til at dokumentere jitter og maksimale v\u00e6rdier.<\/p>\n\n<h2>Afl\u00e6sning og fortolkning af m\u00e5lev\u00e6rdier<\/h2>\n\n<p>Jeg vurderer m\u00e5leresultaterne f\u00f8rst kvalitativt: Hvor forekommer der hyppigt ventetider, og hvilke tr\u00e5de dukker gentagne gange op med <strong>Tinder<\/strong> . Derefter unders\u00f8ger jeg, om de skyldes CPU-begr\u00e6nsninger, politikkonflikter eller interrupt-storme. Jeg s\u00f8rger for, at m\u00e5letiden er lang nok til at fange sj\u00e6ldne h\u00e6ndelser, men kort nok til at kunne betragte \u00e6ndringer isoleret. V\u00e6rdier i mikrosekundomr\u00e5det er gode i hverdagen, men realtids-workloads kr\u00e6ver til tider endnu strammere rammer. Det afg\u00f8rende er stadig: falder den maksimale latenstid p\u00e5lideligt, og bliver jitteren mindre?.<\/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\/linuxscheduler_9374.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Parametre i Linux-scheduleren, der p\u00e5virker latenstiden<\/h2>\n\n<p>F\u00f8rst justerer jeg m\u00e5llatenstiden \u201esched_latency_ns\u201c, som fastl\u00e6gger, i hvilket tidsvindue alle opgaver, der er klar til udf\u00f8relse, <strong>CPU<\/strong>-Tid. I mange processer bliver tidsintervallet pr. opgave kortere, mens det i nogle f\u00e5 tilf\u00e6lde bliver l\u00e6ngere, hvilket sikrer retf\u00e6rdighed, men kan forskyde reaktionstiderne. Til interaktive applikationer s\u00e6nker jeg v\u00e6rdien moderat for at fremme korte svartider, men holder \u00f8je med overheadet. CFS fordeler tiden retf\u00e6rdigt, men arbejdsbelastninger med kritiske tr\u00e5de drager fordel af klare prioriteter. Her sammenfatter jeg grundl\u00e6ggende oplysninger om fair scheduling i en hosting-sammenh\u00e6ng: <a href=\"https:\/\/webhosting.de\/da\/cfs-scheduler-fair-scheduling-hosting\/\">At forst\u00e5 CFS-schedulere<\/a>.<\/p>\n\n<p>Ud over latenstid og kvanta har ogs\u00e5 wakeup-granularitet og migrationslogik indflydelse p\u00e5 <strong>Tips<\/strong>. For aggressive migrationer \u00f8del\u00e6gger cache-lokaliteten og forl\u00e6nger indirekte ventetiderne. Jeg reducerer un\u00f8dvendige vandringer, pinner hot-threads og holder data t\u00e6t p\u00e5 deres kerner. I NUMA-milj\u00f8er g\u00e6lder dette i dobbelt grad, fordi hukommelsesafstande \u00f8ger latenstiderne. M\u00e5let er fortsat et roligt, forudsigeligt planl\u00e6gningsmilj\u00f8.<\/p>\n\n<h2>Brug politikker, prioriteter og deadlines klogt<\/h2>\n\n<p>Jeg giver kritiske tr\u00e5de <strong>SCHED_FIFO<\/strong> eller SCHED_RR-prioritet, n\u00e5r latenstid er vigtigere end gennemstr\u00f8mning. Med SCHED_DEADLINE kan jeg pr\u00e6cist tildele ressourcer i forhold til perioder, k\u00f8retid og deadline, hvilket sikrer overholdelse af strenge tidsfrister. Jeg bruger s\u00e5danne politikker med m\u00e5de, s\u00e5 systemet ikke l\u00f8ber t\u00f8r for ressourcer. Jeg kalibrerer prioriteterne, indtil kun de virkelig essentielle stier slipper igennem. En praktisk introduktion til prioriteter findes her: <a href=\"https:\/\/webhosting.de\/da\/serverprocesplanlaegning-prioriteter-optimering-serverboost\/\">Prioriteringer i processen<\/a>.<\/p>\n\n<p>Jeg tjekker regelm\u00e6ssigt, om der opst\u00e5r konflikter mellem politikker, f.eks. n\u00e5r baggrundsopgaver bruger mere <strong>Prio<\/strong> modtaget som interaktionstr\u00e5de. Ogs\u00e5 deadline-parametre skal dimensioneres korrekt, ellers opst\u00e5r der nye flaskehalse. Testk\u00f8rsler med reelle arbejdsbelastninger sikrer det rigtige valg. Jeg dokumenterer hver \u00e6ndring og m\u00e5ler opf\u00f8lgende, s\u00e5 virkningerne forbliver sporbare. P\u00e5 den m\u00e5de undg\u00e5r jeg bivirkninger i driften.<\/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\/LinuxSchedulerOptimierung4321.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>CPU-isolering, pinning og NUMA: Stabilisering af latenstider<\/h2>\n\n<p>Jeg adskiller kritiske tr\u00e5de fra den generelle belastning ved at isolere dedikerede CPU\u2019er og holde systemtjenesterne v\u00e6k, hvor lav <strong>Forsinkelse<\/strong> er n\u00f8dvendigt. CPU-pinning holder hot-paths p\u00e5 faste kerner og beskytter cache-lokaliteten. I NUMA-konfigurationer binder jeg tr\u00e5de til lokale hukommelsesbanker for at undg\u00e5 un\u00f8dvendige adgangsforesp\u00f8rgsler p\u00e5 tv\u00e6rs af noder. Disse foranstaltninger reducerer jitter-effekter m\u00e6rkbart. Gevinsten viser sig straks i smallere eBPF-histogrammer.<\/p>\n\n<p>IRQ-fordelingen er en del af det: Jeg omdirigerer forstyrrende interrupts v\u00e6k fra latenskerner og aflaster dermed <strong>Varm<\/strong>-Tr\u00e5de. MSI-X og affiniteter hj\u00e6lper med at finjustere fordelingen. Hvor det er muligt, bruger jeg tr\u00e5dbaserede IRQ\u2019er, s\u00e5 ISR-opgaver afleveres hurtigere. Alt dette skaber r\u00e5derum til tidsf\u00f8lsom udf\u00f8relse. M\u00e5linger med perf og cyclictest bekr\u00e6fter effekten.<\/p>\n\n<h2>Optimering af interrupts, drivere og pr\u00e6emption<\/h2>\n\n<p>Jeg flytter beregningskr\u00e6vende dele fra ISR til efterf\u00f8lgende arbejdsk\u00f8er, s\u00e5 planl\u00e6ggeren kan arbejde hurtigere <strong>skifte<\/strong> kan. Jeg opdeler l\u00e6ngere kritiske afsnit i kernen, s\u00e5 der opst\u00e5r hyppigere pr\u00e6emptionspunkter. Un\u00f8dvendige kernefunktioner og tunge drivere sl\u00e5r jeg fra, hvis de \u00f8ger latenstiden. Til kr\u00e6vende realtidsopgaver bruger jeg PREEMPT_RT, mens PREEMPT med en god konfiguration ofte er tilstr\u00e6kkeligt til bred serverbelastning. Det er vigtigt at m\u00e5le hver eneste optimering n\u00f8je i stedet for at stole p\u00e5 antagelser.<\/p>\n\n<p>Jeg tjekker, om timer-opl\u00f8sninger og tick-indstillinger passer til arbejdsbelastningen, fordi grove ticks <strong>Jitter<\/strong> kan forst\u00e6rke. Derudover kommer energistyring: dybe C-tilstande forl\u00e6nger opv\u00e5gningstiderne og kan medf\u00f8re spidsbelastninger i ventetiden. Med tilpassede governor-indstillinger finder jeg et holdbart kompromis. I sidste ende er det m\u00e5lev\u00e6rdiernes konsistens, der t\u00e6ller, ikke navnet p\u00e5 en indstilling. En stabil tilgang er bedre end aggressive enkeltindstillinger.<\/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\/linux_scheduler_performance1234.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Praktiske indstillingstrin med eksempelv\u00e6rdier<\/h2>\n\n<p>Jeg starter med en basism\u00e5ling og \u00e6ndrer kun \u00e9n <strong>Parametre<\/strong> pr. runde for at fastsl\u00e5 kausaliteten. Derefter varierer jeg sched_latency_ns i sm\u00e5 trin, observerer maksimumsv\u00e6rdier og jitter og dokumenterer effekterne. Om n\u00f8dvendigt fastl\u00e5ser jeg kritiske tr\u00e5de og flytter IRQ\u2019er, m\u00e5ler igen og registrerer spidsbelastninger. Hvor det er relevant, skifter jeg m\u00e5lrettet til FIFO\/RR eller DEADLINE. F\u00f8lgende tabel sammenligner almindelige indstillinger med hensyn til effekt og bivirkninger:<\/p>\n\n<table>\n  <thead>\n    <tr>\n      <th>Valgmulighed\/mekanik<\/th>\n      <th>Forventet indvirkning p\u00e5 ventetiden<\/th>\n      <th>Mulige bivirkninger<\/th>\n      <th>Hint<\/th>\n    <\/tr>\n  <\/thead>\n  <tbody>\n    <tr>\n      <td><strong>sched_latency_ns<\/strong> s\u00e6nke<\/td>\n      <td>Kortere ventetid til CPU\u2019en<\/td>\n      <td>St\u00f8rre planl\u00e6gningsomkostninger<\/td>\n      <td>Sm\u00e5 skridt, m\u00e5ling af effekten<\/td>\n    <\/tr>\n    <tr>\n      <td>Juster wakeup-granularitet<\/td>\n      <td>Hurtigere genoptagelse efter opv\u00e5gning<\/td>\n      <td>Hyppigere fortr\u00e6ngninger<\/td>\n      <td>Juster kun moderat<\/td>\n    <\/tr>\n    <tr>\n      <td>CPU-fastg\u00f8relse\/isolering<\/td>\n      <td>Mere stabile <strong>Tinder<\/strong> og mindre jitter<\/td>\n      <td>Mindre fleksibilitet<\/td>\n      <td>Tage h\u00f8jde for IRQ-tilknytninger<\/td>\n    <\/tr>\n    <tr>\n      <td>SCHED_FIFO\/RR<\/td>\n      <td>Foretrukket design<\/td>\n      <td>Forskydning af andre opgaver<\/td>\n      <td>Kun for kritiske forl\u00f8b<\/td>\n    <\/tr>\n    <tr>\n      <td>PREEMPT_RT<\/td>\n      <td>Lav latens i v\u00e6rst t\u00e6nkelige tilf\u00e6lde<\/td>\n      <td>Flere kontekstskift<\/td>\n      <td>Der kr\u00e6ves RT-kompatible drivere<\/td>\n    <\/tr>\n  <\/tbody>\n<\/table>\n\n<p>Jeg validerer \u00e6ndringer ved hj\u00e6lp af perf timehist og eBPF-histogrammer, indtil <strong>Distribution<\/strong> t\u00e6t, og at maksimumsv\u00e6rdien forbliver konservativ. Hvis der opst\u00e5r modstridende effekter, tager jeg et skridt tilbage og pr\u00f8ver en alternativ kombination. Hvert milj\u00f8 reagerer lidt forskelligt, derfor er det vigtigt at eksperimentere omhyggeligt. Med konsistente benchmarks beviser jeg objektivt fordelene. P\u00e5 den m\u00e5de skabes en gentagelig optimeringsproces.<\/p>\n\n<h2>Hosting- og serverkontekst: Effektiv reduktion af latenstiden<\/h2>\n\n<p>I hosting-milj\u00f8et reducerer en finjustering af scheduleren svartiderne for web- og <strong>DB<\/strong>-Foresp\u00f8rgsler. Mange samtidige processer drager fordel af, at ventetiderne i runqueue reduceres, og spidsbelastninger undg\u00e5s. Container- og microservice-stacks bliver mere stabile, s\u00e5 snart kritiske tjenester f\u00e5r prioritet og placeres t\u00e6t p\u00e5 CPU\u2019en. N\u00e5r man v\u00e6lger udbyder, skal man v\u00e6re opm\u00e6rksom p\u00e5 aktuelle kerneler, fornuftig pr\u00e6emption og fleksibel IRQ-\/CPU-styring. Lavere latenstid har en direkte positiv indvirkning p\u00e5 oms\u00e6tningen og brugeroplevelsen.<\/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\/linux-performance-optimierung-4523.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Moderne kernefunktioner, der p\u00e5virker latenstiden<\/h2>\n\n<p>De nyeste kerneler indeholder mekanismer, der direkte p\u00e5virker reaktionstiderne. I de nyere versioner har CFS f\u00e5et forbedrede heuristikker for wakeups og fortr\u00e6ngninger, som prioriterer interaktive belastninger. Attributter som en <strong>Pr\u00e6ference for v\u00e5genhed og s\u00f8vn<\/strong> pr. tr\u00e5d bidrage til, at vigtige stier kommer hurtigere til udf\u00f8relse, uden at RT-politikker misbruges. Derudover styrer <strong>uclamp<\/strong> (utilization clamping) den minimale og maksimale CPU-udnyttelse pr. opgave eller cgroup, som planl\u00e6ggeren fasts\u00e6tter. P\u00e5 denne m\u00e5de tvinger jeg en nedre gr\u00e6nse for regnekraften for tr\u00e5de, hvor latenstiden er afg\u00f8rende, hvilket styrer frekvensregulatoren og placeringen p\u00e5 aktive kerner.<\/p>\n\n<p>Til systemer med f\u00e5 tik bruger jeg <strong>NOHZ_FULL<\/strong> i kombination med dedikerede housekeeping-CPU\u2019er. Dette flytter periodiske kernelopgaver v\u00e6k fra kernerne med h\u00f8j latenstid. Derudover aflaster jeg disse kerner via <code>rcu_nocbs<\/code>, s\u00e5 callbacks ikke forstyrrer deres rytme. Begge dele mindsker u\u00f8nskede afbrydelser p\u00e5 det forkerte tidspunkt og stabiliserer v\u00e6rdierne i v\u00e6rst t\u00e6nkelige tilf\u00e6lde.<\/p>\n\n<p>Med <strong>PSI<\/strong> (Oplysninger om tryk-stall) m\u00e5ler jeg systemtrykket p\u00e5 CPU, hukommelse og I\/O. N\u00f8gletallene i <code>\/proc\/pressure\/*<\/code> vise, om tr\u00e5de st\u00e5r stille p\u00e5 grund af ressourceknaphed. Hvis CPU-PSI stiger sidel\u00f8bende med ventetiderne i Runqueue, er det et klart tegn p\u00e5 reel overbelastning eller en for stram kvotestyring.<\/p>\n\n<h2>Cgroups, containere og retf\u00e6rdighed: Isolering uden ekstra belastning<\/h2>\n\n<p>I container-milj\u00f8er er cgroups n\u00f8glen til at sikre forudsigelig latenstid. Jeg bruger <strong>cpu.v\u00e6gt<\/strong>, for at sikre en vis retf\u00e6rdighed, og benyt <strong>cpu.max<\/strong>, for at s\u00e6tte en stram begr\u00e6nsning p\u00e5 forstyrrende baggrundstjenester. Kritiske tjenester f\u00e5r ikke tildelt en stram CPU-kvote, s\u00e5 de ikke <em>begr\u00e6nse<\/em> og opdeles tidsm\u00e6ssigt. For at sikre n\u00e6rhed til CPU\u2019en opdeler jeg cpusets: et s\u00e6t kerner til interaktion, et s\u00e6t til batch. Denne isolering har st\u00f8rre effekt end blot at justere nice-niveauerne.<\/p>\n\n<p>P\u00e5 platforme med orkestrering undg\u00e5r jeg, at flere latenstf\u00f8lsomme pods deler den samme fysiske kerne. Jeg reserverer kerner <em>eksklusivt<\/em> og binder de tilh\u00f8rende IRQ'er konsekvent. Jeg m\u00e5ler \u00e6ndringer i cgroup-hierarkiet med eBPF via cgroup-filtre, s\u00e5 jeg kan se ventetiderne i Runqueue for hver enkelt tjeneste. P\u00e5 den m\u00e5de kan jeg se, om det er belastningsfordelingen eller kvoterne, der er den egentlige \u00e5rsag til spidsbelastningerne.<\/p>\n\n<h2>Virtualisering og SMT: Registrering og d\u00e6mpning af host-st\u00f8j<\/h2>\n\n<p>I virtuelle maskiner l\u00e6gger jeg m\u00e6rke til <strong>Stj\u00e6l tid<\/strong>: Den viser, hvorn\u00e5r hypervisoren tager CPU-tid fra g\u00e6stesystemet. Hvis perf viser gode stier, men appen hakker, er det ofte \u00bbSteal Time\u00ab, der er synderen. L\u00f8sningen er <em>vCPU-fastg\u00f8relse<\/em> p\u00e5 dedikerede pCPU\u2019er, reducerede overcommitment-rater og adskillelse af I\/O-tr\u00e5de p\u00e5 egne kerner. For at opn\u00e5 konstant latenstid planl\u00e6gger jeg pCPU = vCPU; ellers er worst-case-scenariet n\u00e6sten umuligt at beregne.<\/p>\n\n<p>Med <strong>SMT<\/strong> (Hyper-Threading) deler jeg kernekapaciteten med en s\u00f8skende. Derfor dirigerer jeg latensstier over til kerner, hvis s\u00f8skende er ledige, eller jeg bruger Core Scheduling-indstillinger, der begr\u00e6nser forstyrrelser p\u00e5 tv\u00e6rs af kerner. Ved kr\u00e6vende opgaver deaktiverer jeg SMT selektivt for kritiske kerner. Fordelen opn\u00e5s gennem mindre konkurrence om porte, cacher og eksekveringsenheder.<\/p>\n\n<h2>Hukommelses-, I\/O- og netv\u00e6rksstier: skjulte kilder til latenstid<\/h2>\n\n<p>Scheduler-latens f\u00f8les ofte som et CPU-problem, men er i virkeligheden <strong>Reclaim<\/strong> eller <strong>Komprimering<\/strong>. Direkte reclaim stopper tr\u00e5de og skaber lange spidsbelastninger. Jeg holder de ledige sidepuljer p\u00e5 et tilstr\u00e6kkeligt h\u00f8jt niveau og v\u00e6lger en moderat <code>vm.swappiness<\/code>, s\u00e5 adgang til hukommelsen ikke forstyrres af voldsomme swap-operationer. Jeg kalibrerer Transparent Huge Pages defensivt: Hvis kernen sammenl\u00e6gger store sider p\u00e5 et uheldigt tidspunkt, opst\u00e5r der forsinkelser; med <em>madvise<\/em> Jeg placerer THP der, hvor de \u00f8ger gennemstr\u00f8mningen uden at forstyrre interaktionen.<\/p>\n\n<p>Writeback- og journal-commit-intervaller p\u00e5virker ligeledes interaktionerne. For store \u00bbdirty limits\u00ab udskyder arbejdet til ugunstige perioder; for sm\u00e5 tvinger til hyppige flush-spidsbelastninger. Jeg dimensionerer i bytes i stedet for procenter og spreder skrivningerne, s\u00e5 CPU'ens v\u00e5gne faser ikke kolliderer med I\/O-spidsbelastninger.<\/p>\n\n<p>I netv\u00e6rksstien ser jeg p\u00e5 <strong>SoftIRQs<\/strong>, NAPI-budgetter og pakkebundling. En for aggressiv GRO reducerer overhead pr. pakke, men kan forl\u00e6nge den interaktive latenstid. RPS\/RFS fordeler belastningen godt, men skal passe til IRQ- og CPU-affiniteter. M\u00e5let er, at pakkerne behandles der, hvor applikationstr\u00e5den k\u00f8rer \u2013 og ikke f\u00f8rst skal vandre gennem flere kerner.<\/p>\n\n<h2>At finde den rette balance mellem RT-begr\u00e6nsninger, tidsfrister og beskyttelsesmekanismer<\/h2>\n\n<p>Das <strong>RT-begr\u00e6nsning<\/strong> beskytter systemet mod at g\u00e5 i st\u00e5, men begr\u00e6nser RT-belastningen effektivt til en del af CPU-tiden. For at opn\u00e5 deterministiske reaktionstider \u00f8ger jeg <code>kernel.sched_rt_runtime_us<\/code> eller deaktivere begr\u00e6nsningen i omhyggeligt afgr\u00e6nsede milj\u00f8er. Jeg m\u00e5ler derefter konsekvent, om ikke-RT-tr\u00e5de stadig f\u00e5r tildelt tilstr\u00e6kkeligt med vinduer. Lige s\u00e5 vigtige er globale <strong>Deadline<\/strong>-Kontingenter: Hvis de indstilles for stramt, g\u00e5r DEADLINE-opgaver glip af deres tidsvinduer, selvom parametrene er korrekte. Jeg tjekker forholdet mellem <em>k\u00f8rselstid<\/em> til <em>periode<\/em> og summen af alle DEADLINE-reservationer pr. CPU.<\/p>\n\n<h2>M\u00e5ledesign, beskyttelse mod regression og drift<\/h2>\n\n<p>Jeg adskiller m\u00e5lefaser strengt: opvarmning, reference, variation, verifikation. Kolde cacher forvr\u00e6nger resultaterne; jeg m\u00e5ler stabiliserede faser og korrelerer dem med Perf- og eBPF-data. A\/B-sammenligninger k\u00f8rer med identiske arbejdsbelastninger, identisk varighed og faste affiniteter. Jeg v\u00e6lger et m\u00e5levindue, der er stort nok til, at sj\u00e6ldne toppe dukker op statistisk, men lille nok til at kunne vurdere enkelte finjusteringstrin isoleret.<\/p>\n\n<p>Til kontinuerlig drift definerer jeg en <strong>SLO<\/strong> for latenstid og jitter: ca. 99,91 TP3T-kvantil under X mikrosekunder ved Y-belastning. Telemetri fra PSI, perf-statistikker og eBPF-histogrammer fungerer som overv\u00e5gning; hvis m\u00e5lingerne overskrider t\u00e6rskelv\u00e6rdierne, skifter jeg automatisk tilbage til konservative profiler. Hver \u00e6ndring f\u00e5r en \u00e6ndringslog med kerneversion, parametre, m\u00e5lemetoder, r\u00e5data og fortolkning. P\u00e5 den m\u00e5de forbliver finjusteringen reproducerbar \u2013 og det er muligt at rulle tilbage n\u00e5r som helst.<\/p>\n\n<ul>\n  <li>Opret baseline: perf, eBPF, schedstat, cyclictest<\/li>\n  <li>Identificer flaskehals: CPU, IRQ, I\/O, hukommelse, politik<\/li>\n  <li>\u00c9n \u00e6ndring pr. runde: parametre, pinning, politik, isolering<\/li>\n  <li>M\u00e5ling f\u00f8r\/efter: Gennemsnit, 99%- og 99,9%-kvantil, maksimum<\/li>\n  <li>Test af stabilitet: lange k\u00f8rsler, reelle arbejdsbelastninger, belastningsspidser<\/li>\n  <li>Dokumentation og opbevaring: Profiler, gr\u00e6nsev\u00e6rdier, plan for tilbagefald<\/li>\n<\/ul>\n\n<h2>Kort opsummeret<\/h2>\n\n<p>Jeg m\u00e5ler scheduler-latens med <strong>perf<\/strong>, eBPF, schedstat og cyclictest, f\u00f8r jeg r\u00f8rer ved noget som helst. Derefter s\u00e6nker jeg m\u00e5l-latensen forsigtigt, kalibrerer politikker og afsk\u00e6rmer kritiske tr\u00e5de ved hj\u00e6lp af pinning og IRQ-affiniteter. Jeg fastl\u00e6gger drivere, ISR-fordeling og pr\u00e6emption p\u00e5 en s\u00e5dan m\u00e5de, at worst-case-spidser falder, og jitteren bliver minimal. Hver \u00e6ndring underbygger jeg med gentagne m\u00e5linger, indtil kurverne er overbevisende. P\u00e5 den m\u00e5de \u00f8ger jeg <strong>Kernen<\/strong>-Reaktionshastigheden er stabil og leverer p\u00e5lidelige resultater til desktop, servere og realtids-arbejdsbelastninger.<\/p>","protected":false},"excerpt":{"rendered":"<p>En praktisk vejledning i, hvordan du m\u00e5ler og optimerer Linux-scheduler-latensen for at \u00f8ge kernels ydeevne. Fokus: Scheduler-latens under Linux for pr\u00e6cis CPU-scheduling og stabile server-responstider.<\/p>","protected":false},"author":1,"featured_media":20771,"comment_status":"","ping_status":"","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"inline_featured_image":false,"footnotes":""},"categories":[676],"tags":[],"class_list":["post-20778","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":"173","_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","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":"20771","footnotes":null,"_links":{"self":[{"href":"https:\/\/webhosting.de\/da\/wp-json\/wp\/v2\/posts\/20778","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=20778"}],"version-history":[{"count":0,"href":"https:\/\/webhosting.de\/da\/wp-json\/wp\/v2\/posts\/20778\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/webhosting.de\/da\/wp-json\/wp\/v2\/media\/20771"}],"wp:attachment":[{"href":"https:\/\/webhosting.de\/da\/wp-json\/wp\/v2\/media?parent=20778"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/webhosting.de\/da\/wp-json\/wp\/v2\/categories?post=20778"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/webhosting.de\/da\/wp-json\/wp\/v2\/tags?post=20778"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}