{"id":21507,"date":"2026-09-18T08:32:17","date_gmt":"2026-09-18T06:32:17","guid":{"rendered":"https:\/\/webhosting.de\/tickless-mode-linux-kernel-rhythmus\/"},"modified":"2026-09-18T08:32:17","modified_gmt":"2026-09-18T06:32:17","slug":"tickless-tilstand-linux-kernen-rytme","status":"publish","type":"post","link":"https:\/\/webhosting.de\/da\/tickless-mode-linux-kernel-rhythmus\/","title":{"rendered":"Kernel-schedulerens tickless-tilstand forklaret: Fordele, risici og optimering"},"content":{"rendered":"<p>Jeg forklarer den <strong>tickless-tilstand<\/strong> i Linux-kernen p\u00e5 en forst\u00e5elig m\u00e5de og viser, hvorn\u00e5r den har en positiv indflydelse p\u00e5 ydeevne, latenstid og energiforbrug. Derudover n\u00e6vner jeg klare fordele, mulige risici og konkrete optimeringstrin, som jeg selv anvender i praksis.<\/p>\n\n<h2>Centrale punkter<\/h2>\n\n<p>Jeg opsummerer de vigtigste <strong>Hovedtemaer<\/strong> samlet p\u00e5 en overskuelig m\u00e5de, s\u00e5 du straks ved, hvad du skal v\u00e6re opm\u00e6rksom p\u00e5. Linux-scheduleren og den dynamiske tick h\u00e6nger direkte sammen og bestemmer, hvordan din <strong>CPU'er<\/strong>. Afh\u00e6ngigt af arbejdsbelastningen beslutter jeg, om \u00bbTickless Idle\u00ab er tilstr\u00e6kkeligt, eller om jeg skal bruge \u00bbFull Tickless\u00ab med isolerede kerner. For at opn\u00e5 reproducerbare resultater planl\u00e6gger jeg omhyggeligt housekeeping-CPU\u2019er, IRQ-affinitet og RCU-callbacks. I sidste ende er det m\u00e5lingerne af latenstid, energiforbrug og gennemstr\u00f8mning i din <strong>Ops\u00e6tning<\/strong> virkelig vise.<\/p>\n<ul>\n  <li><strong>Tickless-tomgang<\/strong>: f\u00e6rre tik i tomgang<\/li>\n  <li><strong>NO_HZ_FULL<\/strong>: rolige, afsondrede omr\u00e5der<\/li>\n  <li><strong>IRQ-affinitet<\/strong>: Samle st\u00f8jkilder<\/li>\n  <li><strong>CPU-pinning<\/strong>: Tildele tr\u00e5de fast<\/li>\n  <li><strong>M\u00e5lte v\u00e6rdier<\/strong>: Latenstid, energi, jitter<\/li>\n<\/ul>\n<p>Listen viser de indstillingsh\u00e5ndtag, som jeg f\u00f8rst tjekker og kombinerer. P\u00e5 den m\u00e5de kan jeg hurtigt se, hvor den st\u00f8rste <strong>H\u00e5ndtag<\/strong> afh\u00e6nger af, hvor meget jeg tilpasser kernen.<\/p>\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\/09\/kernel-tickless-6359.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Hvad kernel-tick'et rent praktisk set medf\u00f8rer<\/h2>\n\n<p>Et periodisk tick udl\u00f8ser i kernen tidsm\u00e5ling, timerh\u00e5ndtering og nye <strong>Planl\u00e6gning<\/strong>-beslutninger. Den er enkel, men den v\u00e6kker kerner, selv n\u00e5r der ikke er noget meningsfuldt arbejde, der venter. Med \u00bbtickless\u00ab planl\u00e6gger kernen den n\u00e6ste opv\u00e5gning efter behov og undg\u00e5r un\u00f8dvendige <strong>Afbrydelser<\/strong>. P\u00e5 den m\u00e5de forbliver CPU'erne l\u00e6ngere i dybe C-tilstande og genererer mindre jitter ved opgaver, hvor latenstiden er afg\u00f8rende. Jeg bruger denne mekanisme til at skabe rolige eksekveringsvinduer til f\u00f8lsomme tr\u00e5de.<\/p>\n\n<h2>Variationer: Oversigt over Tickless Idle og NO_HZ_FULL<\/h2>\n\n<p><strong>Tickless-tomgang<\/strong> (CONFIG_NO_HZ_IDLE) undertrykker den regelm\u00e6ssige tick, s\u00e5 snart en CPU er inaktiv. Dette reducerer str\u00f8mforbruget og varmeudviklingen, da processoren sj\u00e6ldnere v\u00e6kkes fra dyb s\u00f8vn. <strong>NO_HZ_FULL<\/strong> g\u00e5r endnu videre og reducerer antallet af ticks selv p\u00e5 aktive kerner, hvis der kun k\u00f8rer \u00e9n opgave der. Til det form\u00e5l isolerer jeg disse kerner strengt og flytter systemopgaver over p\u00e5 dedikerede housekeeping-CPU\u2019er. Hvis man implementerer en ordentlig isolering, opn\u00e5r man meget stille kerner og dermed bedre forudsigelighed under belastning.<\/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\/09\/tickless_mode_vorteile_1234.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Sammenligningstabel og anvendelsesscenarier<\/h2>\n\n<p>F\u00f8lgende oversigt hj\u00e6lper mig med at finde den rigtige <strong>Tilstand<\/strong> at v\u00e6lge den rette l\u00f8sning afh\u00e6ngigt af form\u00e5let og forberede det n\u00f8dvendige milj\u00f8 korrekt. Jeg ser f\u00f8rst p\u00e5 arbejdsbelastningens karakteristika, derefter p\u00e5 energim\u00e5lene og til sidst p\u00e5 jitter-tolerancen. Erfaringen viser, at klar CPU-isolering is\u00e6r l\u00f8nner sig inden for trading, HPC og applikationer med meget lav latenstid <strong>Netv\u00e6rk<\/strong>-Stacks. I et datacenter med varierende belastning giver \u00bbTickless Idle\u00ab derimod ofte den hurtigste besparelse. \u00bbFull Tickless\u00ab gemmer jeg til strengt kontrollerede v\u00e6rter, hvor jeg p\u00e5lideligt adskiller systemarbejdet.<\/p>\n<table>\n  <thead>\n    <tr>\n      <th>Tilstand<\/th>\n      <th>Hvorn\u00e5r er den aktiv?<\/th>\n      <th>Fordel<\/th>\n      <th>Risiko<\/th>\n      <th>Velegnet til<\/th>\n    <\/tr>\n  <\/thead>\n  <tbody>\n    <tr>\n      <td>Periodisk tick<\/td>\n      <td>Altid, fast frekvens<\/td>\n      <td>Enkel <strong>Administration<\/strong><\/td>\n      <td>Mere jitter og wake-ups<\/td>\n      <td>Generelle servere<\/td>\n    <\/tr>\n    <tr>\n      <td>Tickless-tomgang (NO_HZ_IDLE)<\/td>\n      <td>Kun ved tomgang<\/td>\n      <td>Mindre energi, k\u00f8ligere <strong>CPU'er<\/strong><\/td>\n      <td>Begr\u00e6nset forbedring af latenstiden<\/td>\n      <td>VM-v\u00e6rter, web, blandet<\/td>\n    <\/tr>\n    <tr>\n      <td>Fuldst\u00e6ndig tickless (NO_HZ_FULL)<\/td>\n      <td>Ogs\u00e5 ved single-task-belastning<\/td>\n      <td>Meget stille omr\u00e5der, f\u00e5 <strong>Jitter<\/strong><\/td>\n      <td>Omfattende isolering er n\u00f8dvendig<\/td>\n      <td>HPC, handel, n\u00e6sten i realtid<\/td>\n    <\/tr>\n  <\/tbody>\n<\/table>\n\n<h2>Hvorn\u00e5r tikl\u00f8s tilstand virkelig kommer til sin ret<\/h2>\n\n<p>Jeg aktiverer Full Tickless p\u00e5 isolerede kerner, n\u00e5r et program er ekstremt <strong>Lav latenstid<\/strong> skal reagere. Herunder h\u00f8rer ordrematchning, pakkebehandling med single-queue eller t\u00e6t NUMA-lokalisering i videnskabelige koder. Ved energim\u00e5l p\u00e5 blandede v\u00e6rter er \u00bbTickless Idle\u00ab ofte tilstr\u00e6kkeligt til at opn\u00e5 m\u00e5lbare <strong>Besparelser<\/strong>. Hvis man ser mange s\u00f8vnfaser, f\u00e5r man stor fordel af det, fordi C-tilstande sj\u00e6ldnere forlades ved ticks. Du er velkommen til at l\u00e6se min vejledning om <a href=\"https:\/\/webhosting.de\/da\/tickless-kernel-server-energieffektivitet-optimeret-gron\/\">Energieffektivitet med Tickless<\/a>, hvis du f\u00f8rst og fremmest vil s\u00e6nke elregningen.<\/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\/09\/tickless-mode-scheduler-explained-4785.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Fordele og bivirkninger i hverdagen<\/h2>\n\n<p>F\u00e6rre periodiske ticks betyder f\u00e6rre <strong>\u00c6ndring af konteksten<\/strong> og ofte mere ensartede k\u00f8retider. I isolationsops\u00e6tninger falder OS-st\u00f8j, s\u00e5 f\u00f8lsom kode reagerer mere konsistent. If\u00f8lge Linux Foundation og kerne-dokumentationen giver NO_HZ_IDLE markante forbedringer i tomgangstilstand, mens NO_HZ_FULL yderligere reducerer forstyrrende impulser. HPC-dokumentation bekr\u00e6fter effekten i kombination med pinning og IRQ-b\u00fcndelung p\u00e5 housekeeping-kerner. Hvis man udf\u00f8rer m\u00e5linger korrekt, kan man tydeligt se disse effekter i latenstid- og energiprofilerne for <strong>V\u00e6rter<\/strong>.<\/p>\n\n<h2>Risici ved forkert tuning<\/h2>\n\n<p>Jeg ser problemer, hvis IRQ\u2019er eller RCU-callbacks alligevel ender p\u00e5 isolerede kerner, og de <strong>Hvile<\/strong> \u00f8del\u00e6gge. S\u00e5 vendes fordelen, fordi st\u00f8jbelastningen opst\u00e5r ukoordineret og skaber jitter. Uplanlagte baggrundstjenester, timere eller watchdogs p\u00e5 isolerede CPU\u2019er har en lignende forstyrrende virkning. Ogs\u00e5 blandede arbejdsbelastninger med mange korte opgaver spreder forstyrrelserne s\u00e5 bredt, at fuld tickless-drift ikke giver meget. Derfor planl\u00e6gger jeg klart housekeeping-kerner ind og tester hvert trin med realistiske <strong>Profiler<\/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\/09\/ticless_mode_tech_buer_1593.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>De vigtigste kernel-indstillinger forklaret p\u00e5 en forst\u00e5elig m\u00e5de<\/h2>\n\n<p>Med <strong>CONFIG_NO_HZ_IDLE<\/strong> sl\u00e5r jeg \u00bbTick\u00ab fra i tomgang og opn\u00e5r hurtige gevinster uden st\u00f8rre ombygning. <strong>CONFIG_NO_HZ_FULL<\/strong> Jeg aktiverer det kun, n\u00e5r jeg isolerer kerner strengt og definerer rene housekeeping-CPU\u2019er. Boot-parameteren nohz_full fastl\u00e6gger, hvilke kerner der k\u00f8rer tickless; isolcpus adskiller dem fra den generelle planl\u00e6gning. rcu_nocbs flytter RCU-callbacks v\u00e6k fra disse kerner, mens irqaffinity fastl\u00e6gger interrupt-ansvaret. F\u00f8rst i samspil fungerer ops\u00e6tningen stabilt og dermed virkelig <strong>nyttigt<\/strong>.<\/p>\n\n<h2>Planl\u00e6gning af kerneopgaver inden for reng\u00f8ring<\/h2>\n\n<p>Jeg reserverer en eller to <strong>Kerner<\/strong> Hver NUMA-node fungerer som en housekeeping-zone for IRQ\u2019er, kernel-tr\u00e5de og RCU. Disse kerner varetager de uundg\u00e5elige systemopgaver og holder de isolerede kerner fri. Til dette form\u00e5l tildeler jeg bevidst tjenester og IRQ-k\u00f8er til housekeeping-CPU\u2019erne og blokerer dem p\u00e5 de stille kerner. Hvem der <a href=\"https:\/\/webhosting.de\/da\/server-cpu-scheduler-klasseplanlaegning\/\">CPU-scheduler-klasser<\/a> forst\u00e5r, styrer prioriteter og retf\u00e6rdighed p\u00e5 en p\u00e5lidelig m\u00e5de. P\u00e5 den m\u00e5de forbliver ventetidsstierne korte, og de rolige kerner leverer forudsigelige <strong>Svartider<\/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\/09\/entwicklerdesk_kernel_7123.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Praktisk vejledning: Trin for trin<\/h2>\n\n<p>Jeg starter hvert projekt med en klar <strong>Baseline<\/strong>-K\u00f8rsel: Latens, energiforbrug, gennemstr\u00f8mning, jitter. Derefter tjekker jeg, om NO_HZ_IDLE er aktiveret, og om kernen underst\u00f8tter NO_HZ_FULL. Dern\u00e6st tildeler jeg IRQ-affinitet, indstiller rcu_nocbs og planl\u00e6gger housekeeping-CPU'er. F\u00f8rst derefter isolerer jeg nogle f\u00e5 kerner til test med nohz_full og sammenligner resultaterne. Til den detaljerede analyse hj\u00e6lper denne vejledning mig med at <a href=\"https:\/\/webhosting.de\/da\/maling-af-latenstid-i-linux-scheduleren-og-optimering-af-ydeevnen\/\">M\u00e5ling af latenstid<\/a>, s\u00e5 jeg kan vurdere hver \u00e6ndring n\u00f8je.<\/p>\n\n<h2>M\u00e5lemetoder og KPI\u2019er<\/h2>\n\n<p>Jeg m\u00e5ler end-to-end-<strong>Forsinkelse<\/strong> med histogrammer og kvantilisering af outliers i stedet for blot at se p\u00e5 gennemsnitsv\u00e6rdier. Jeg vurderer PPS og tail-latency samlet, s\u00e5 kerner med lav aktivitet ikke tr\u00e6kker gennemstr\u00f8mningen ned. Jeg m\u00e5ler energiforbruget via RAPL, IPMI eller en tilsluttet m\u00e5ler og beregner besparelsen i <strong>Euro<\/strong> pr. m\u00e5ned. Eksempel: Hvis en host sparer 12 W ved drift d\u00f8gnet rundt, giver det ved en pris p\u00e5 0,30 \u20ac\/kWh ca. 3,15 \u20ac pr. m\u00e5ned pr. maskine. Med 200 hosts l\u00f8ber det op i hele 630 \u20ac pr. m\u00e5ned.<\/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\/09\/kernel-scheduler-tickless-8475.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Et n\u00e6rmere kig: Hvordan kernen egentlig sl\u00e5r ticks fra<\/h2>\n<p>Bag Tickless ligger overgangen fra periodiske ticks til en <strong>Oneshot-ur-begivenhed<\/strong>: Kernen planl\u00e6gger den n\u00e6ste \u201ebegivenhed\u201c pr\u00e6cist til det tidligste tidspunkt, hvor en timer udl\u00f8ber, eller hvor en scheduler-beslutning skal tr\u00e6ffes. High-Resolution-Timere (hrtimer) muligg\u00f8r fin granularitet. P\u00e5 en <strong>NO_HZ_FULL<\/strong>-CPU\u2019en udelades den periodiske scheduler-tick, s\u00e5 l\u00e6nge der kun k\u00f8rer \u00e9n opgave, og der ikke er noget kernearbejde. S\u00e5 snart to eller flere opgaver er k\u00f8rbare, genstarter kernen ticken, s\u00e5 retf\u00e6rdighed og tidsdeling fungerer korrekt. Det er netop denne dynamik, der g\u00f8r systemet mere st\u00f8jsvagt uden at miste planl\u00e6gningsn\u00f8jagtigheden.<\/p>\n\n<h2>HZ, High-Res-timer og tidskonto<\/h2>\n<p>Kernel-konstanten <strong>HZ<\/strong> (typisk 250 eller 1000) bestemmer frekvensen for det klassiske tick. Med \u00bbTickless\u00ab mister HZ sin praktiske betydning for kerner, hvor k\u00f8retiden er afg\u00f8rende, men forbliver relevant for jiffies-baseret logik. Det er ogs\u00e5 vigtigt, at <strong>Tidskontierung<\/strong> (VTIME\/Context Tracking): For at sikre, at bruger- og systemtid registreres korrekt, sporer kernen n\u00f8jagtigt, hvorn\u00e5r en opgave befinder sig i kernen eller i brugerrummet \u2013 uden en permanent tick. Hvis man arbejder meget med profilering, b\u00f8r man have dette i baghovedet for at kunne fortolke m\u00e5lingerne korrekt.<\/p>\n\n<h2>Str\u00f8mbesparelsesmekanismer og tickless<\/h2>\n<p>Tickless udnytter sin energibesparende effekt kun, n\u00e5r platformen er i dyb <strong>C-tilstande<\/strong> opn\u00e5s p\u00e5lideligt. Jeg tjekker derfor firmware- og kerneindstillingerne vedr\u00f8rende intel_pstate\/amd-pstate, turbomodi og <strong>cpufreq<\/strong>-Governor. En aggressiv performance-governor kan reducere ventetiderne, men modarbejde energim\u00e5lene. Omvendt kan en for tr\u00e6g str\u00f8mbesparende governor g\u00e5 ud over gennemstr\u00f8mningen. Min fremgangsm\u00e5de: F\u00f8rst stabilisere tickless-ops\u00e6tningen, derefter systematisk teste P- og C-state-tuning, hver gang med identiske arbejdsbelastningsprofiler.<\/p>\n\n<h2>Virtualisering og containere<\/h2>\n<p>P\u00e5 hypervisor-v\u00e6rter giver <strong>Tickless-tomgang<\/strong> ofte m\u00e6rkbare besparelser med det samme, fordi inaktive vCPU\u2019er sj\u00e6ldnere v\u00e6kkes. For <strong>NO_HZ_FULL<\/strong> Jeg isolerer fysiske kerner og tildeler vCPU\u2019er til de kritiske VM\u2019er pr\u00e6cist dertil. Vigtigt: Steal-Time og host-IRQ\u2019er m\u00e5 ikke forstyrre disse kerner. I g\u00e6ster giver Full Tickless kun mening, hvis v\u00e6rten stiller CPU-tiden til r\u00e5dighed p\u00e5 en deterministisk m\u00e5de. I containermilj\u00f8er replikerer jeg isolationslogikken med <strong>cgroups CPU-s\u00e6t<\/strong> og forhindrer, at Systempods eller Sidecars optager de stille kerner.<\/p>\n\n<h2>Optimering af netv\u00e6rks- og lagringsstier<\/h2>\n<p>For at opn\u00e5 ultralave latenstider samler jeg <strong>RX\/TX-k\u00f8er<\/strong> og deres IRQ\u2019er p\u00e5 housekeeping-CPU\u2019er. P\u00e5 de inaktive kerner foretr\u00e6kker jeg at arbejde med userspace-polling eller dedikerede completion-tr\u00e5de i stedet for at tillade IRQ\u2019er. Med NVMe kan <strong>IO-k\u00f8-affinitet<\/strong> hj\u00e6lper p\u00e5 samme m\u00e5de. NAPI-Busy-Polling kan anvendes m\u00e5lrettet, n\u00e5r polling-jitter er mere forudsigelig end interrupt-jitter. M\u00e5let er, at de isolerede kerner aldrig uventet v\u00e6kkes af eksterne h\u00e6ndelser.<\/p>\n\n<h2>Eksempel: Boot-parametre og pinning<\/h2>\n<p>Her skitserer jeg en minimal ops\u00e6tning (eksempel: 16 kerner, CPU 0-1 til vedligeholdelse; 2-7 og 10-15 som kandidater til belastning; 8-9 til systemtjenester):<\/p>\n<pre><code>GRUB_CMDLINE_LINUX=\"nohz_full=2-7,10-15 rcu_nocbs=2-7,10-15 isolcpus=2-7,10-15 irqaffinity=0-1\"<\/code><\/pre>\n<p>Efter opstarten implementerer jeg Affinity og CPUsets konsekvent:<\/p>\n<pre><code>Samling af #-IRQ'er\nfor i in $(grep -E 'eth0|nvme' \/proc\/interrupts | awk -F: '{print $1}'); do\n  echo 3 &gt; \/proc\/irq\/$i\/smp_affinity_list   # CPU 0-1\ndone\n\n# Fastl\u00e5sning af latenstidsf\u00f8lsom tjeneste\ntaskset -c 2-3 \/usr\/bin\/min_tjeneste\n\n# cgroup-cpuset til systemtjenester (eksempel)\nmkdir -p \/sys\/fs\/cgroup\/cpuset\/housekeeping\necho 0-1,8-9 &gt; \/sys\/fs\/cgroup\/cpuset\/housekeeping\/cpuset.cpus\necho 0 &gt; \/sys\/fs\/cgroup\/cpuset\/housekeeping\/cpuset.mems\necho $$ &gt; \/sys\/fs\/cgroup\/cpuset\/housekeeping\/cgroup.procs<\/code><\/pre>\n<p>I systemd-enheder bruger jeg desuden <strong>CPUAffinitet=.<\/strong> eller <strong>AllowedCPUs=<\/strong>, s\u00e5 tjenesterne altid bruger de rigtige kerner.<\/p>\n\n<h2>Diagnose: Kontroller, om kernerne virkelig er lydl\u00f8se<\/h2>\n<p>Jeg kontrollerer mine kerners inaktivitet med et par enkle trin:\n\u2013 \/proc\/interrupts: Stiger t\u00e6lleren p\u00e5 isolerede CPU\u2019er? Hvis ja, skal IRQ-affinitet korrigeres.\n\u2013 \/proc\/timer_list: Identificer uventede timere p\u00e5 NO_HZ_FULL-kerner.\n\u2013 ftrace\/perf: G\u00f8r wakeups, softirqs og sched-events synlige.\n\u2013 turbostat: Kontroller C-state-opholdstider.\nHvis der stadig forekommer softirqs (NET_RX, TIMER) p\u00e5 inaktive kerner, er der n\u00e6sten altid tale om et fordelings- eller driverproblem.<\/p>\n\n<h2>Interaktion med PREEMPT_RT og RT-tr\u00e5de<\/h2>\n<p><strong>PREEMPT_RT<\/strong> reducerer latenstider ved at integrere preemption dybt i kernen. Kombineret med NO_HZ_FULL kan dette give meget gode resultater, n\u00e5r IRQ\u2019er k\u00f8rer som tr\u00e5de og strengt forbliver p\u00e5 housekeeping-CPU\u2019er. Vigtigt: Spred ikke RT-tr\u00e5de for bredt, men fastg\u00f8r dem t\u00e6t og kontroller deres hukommelsesstier (NUMA, sidefejl). Jeg holder altid RT-tr\u00e5de p\u00e5 isolerede kerner \u201ealene\u201c, s\u00e5 der ikke returneres et tick, fordi der opst\u00e5r en anden k\u00f8rbar opgave.<\/p>\n\n<h2>Hvorn\u00e5r er \u00bbFull Tickless\u00ab ikke en god id\u00e9<\/h2>\n<p>Jeg undg\u00e5r at bruge NO_HZ_FULL, hvis:\n\u2013 Der konstant opst\u00e5r mange kortvarige opgaver (f.eks. Fork\/Exec-bursts).\n\u2013 Arbejdsbelastningen er st\u00e6rkt synkroniseret og tvinger konstant til kerneskift.\n\u2013 Platformen ikke opn\u00e5r rene C-tilstande, eller TSC er ustabil.\nI s\u00e5danne tilf\u00e6lde giver ren <strong>IRQ- og CPU-pinning<\/strong> ofte mere end omkostningerne ved en fuldst\u00e6ndig isolering.<\/p>\n\n<h2>Finjusteringer i produktionen: Overv\u00e5gning og drift<\/h2>\n<p>I produktive milj\u00f8er advarer jeg mod \u201esnigende\u201c \u00e6ndringer: En kerneopdatering, en ny agent eller en \u00e6ndret IRQ-mapping kan forstyrre kernernes ro. Derfor indf\u00f8rer jeg:\n\u2013 Et \u201eGuardrail\u201c-script, der efter genstart verificerer affinity, CPU-s\u00e6t og RCU-indstillinger.\n\u2013 Metrikker for wakeups\/s, C-state-ophold og p99,9-latens.\n\u2013 Periodiske <strong>Regressionstests<\/strong> med identiske arbejdsbelastninger.\nKun p\u00e5 den m\u00e5de bevares fordelen ved tickless-drift p\u00e5lideligt.<\/p>\n\n<h2>M\u00e5lrettet afhj\u00e6lpning af jitterkilder<\/h2>\n<p>Ud over IRQ\u2019er er det ofte <strong>Timer i brugerrummet<\/strong> (sleep\/usleep\/timerfd) til uregelm\u00e6ssige m\u00f8nstre. Jeg arbejder med <em>timer slack<\/em> (prctl eller \/proc) og samler forfaldstidspunkter, s\u00e5 kernen planl\u00e6gger f\u00e6rre individuelle opv\u00e5gninger. Ogs\u00e5 baggrunds-GC\u2019er i administrerede k\u00f8rselstider (JVM, Go) planl\u00e6gger jeg tidsm\u00e6ssigt eller isolerer dem p\u00e5 housekeeping-kerner. M\u00e5let er altid kun at tillade de absolut n\u00f8dvendige opv\u00e5gninger p\u00e5 NO_HZ_FULL-kerner.<\/p>\n\n<h2>Fortolkning af KPI\u2019erne: Synligg\u00f8re afvejninger<\/h2>\n<p>Jeg vurderer ikke kun gennemsnitsv\u00e6rdier, men ogs\u00e5 <strong>Distribution<\/strong>: p50, p95, p99,9 og maksimum. Et typisk m\u00f8nster for succes: Tail-latensen falder markant, den gennemsnitlige gennemstr\u00f8mning forbliver u\u00e6ndret eller stiger let, og C-state-opholdet bliver l\u00e6ngere. Hvis jeg derimod ser forbedret jitter, men m\u00e6rkbart lavere gennemstr\u00f8mning, justerer jeg CPU-frekvenspolitikken eller \u00f8ger forsigtigt antallet af inaktive kerner, s\u00e5 k\u00f8erne ikke bliver overbelastede.<\/p>\n\n<h2>Tjekliste inden aktivering af NO_HZ_FULL<\/h2>\n<p>\n\u2013 Kernelfunktioner: CONFIG_NO_HZ_FULL, High-Res-Timer aktiveret<br\/>\n\u2013 Tydelige CPU-roller: Housekeeping-CPU\u2019er defineret pr. NUMA-node<br\/>\n\u2013 IRQ- og RCU-offload: irqaffinity og rcu_nocbs er indstillet konsekvent<br\/>\n\u2013 Placering af tjenester: systemd\/cgroups-pinning er dokumenteret og testet<br\/>\n\u2013 M\u00e5leops\u00e6tning: reproducerbare arbejdsbelastninger, meningsfulde KPI\u2019er, sammenligning <em>f\u00f8r\/efter<\/em><br\/>\n\u2013 Rollback-plan: Boot-indgang tilg\u00e6ngelig uden NO_HZ_FULL\n<\/p>\n\n<h2>Almindelige forhindringer og l\u00f8sninger<\/h2>\n\n<p>Jeg ser ofte, at systemtjenester k\u00f8rer p\u00e5 isolerede kerner, og at <strong>Isolering<\/strong> undg\u00e5. Dette kan im\u00f8deg\u00e5s ved hj\u00e6lp af systemd-Affinity, cgroups-CPUsets og en klar dokumentation af tjenesterne. Ogs\u00e5 forkert placering i NUMA f\u00f8rer til un\u00f8dvendige fjernadgange og spidsbelastninger i latenstiden. Jeg knytter hukommelse og tr\u00e5de strengt til den respektive node, s\u00e5 stierne bliver korte og konsistente <strong>ophold<\/strong>. Uklar IRQ-fordeling er den tredje klassiker, derfor samler jeg k\u00f8er med h\u00f8j belastning p\u00e5 housekeeping-CPU'er.<\/p>\n\n<h2>Kort oversigt til praksis<\/h2>\n\n<p>Der <strong>tickless<\/strong> Kernen reducerer forstyrrende ticks, sparer energi og skaber p\u00e5lidelige tidsvinduer til f\u00f8lsomme arbejdsbelastninger. Med \u00bbTickless Idle\u00ab opn\u00e5r jeg hurtigt effektivitetsgevinster, mens \u00bbFull Tickless\u00ab giver yderligere ro p\u00e5 isolerede kerner. Den st\u00f8rste effekt ser jeg, n\u00e5r jeg samler IRQ'er, RCU og baggrundsopgaver p\u00e5 en overskuelig m\u00e5de p\u00e5 housekeeping-CPU'er. Uden m\u00e5linger g\u00e5r det ikke: Latens, jitter, energiforbrug og gennemstr\u00f8mning viser mig, om finjusteringen virker. S\u00e5dan bruger jeg tickless-tilstand m\u00e5lrettet og f\u00e5r det maksimale ud af <strong>planl\u00e6gningsprogram<\/strong> ud.<\/p>","protected":false},"excerpt":{"rendered":"<p>Tickless-kernen forklaret p\u00e5 en enkel m\u00e5de: Fordele, risici og kernel-tuning til servere, HPC og systemer med lav latenstid.<\/p>","protected":false},"author":1,"featured_media":21500,"comment_status":"","ping_status":"","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"inline_featured_image":false,"footnotes":""},"categories":[676],"tags":[],"class_list":["post-21507","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":"60","_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":"tickless mode","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":"21500","footnotes":null,"_links":{"self":[{"href":"https:\/\/webhosting.de\/da\/wp-json\/wp\/v2\/posts\/21507","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=21507"}],"version-history":[{"count":0,"href":"https:\/\/webhosting.de\/da\/wp-json\/wp\/v2\/posts\/21507\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/webhosting.de\/da\/wp-json\/wp\/v2\/media\/21500"}],"wp:attachment":[{"href":"https:\/\/webhosting.de\/da\/wp-json\/wp\/v2\/media?parent=21507"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/webhosting.de\/da\/wp-json\/wp\/v2\/categories?post=21507"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/webhosting.de\/da\/wp-json\/wp\/v2\/tags?post=21507"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}