{"id":19801,"date":"2026-06-08T11:48:55","date_gmt":"2026-06-08T09:48:55","guid":{"rendered":"https:\/\/webhosting.de\/tickless-kernel-server-energieeffizienz-optimiert-gruen\/"},"modified":"2026-06-08T11:48:55","modified_gmt":"2026-06-08T09:48:55","slug":"%d0%b1%d0%b5%d1%81%d1%89%d0%b5%d1%82%d0%be%d1%87%d0%bd%d1%8b%d0%b9-%d1%81%d0%b5%d1%80%d0%b2%d0%b5%d1%80-%d1%8f%d0%b4%d1%80%d0%b0-%d1%8d%d0%bd%d0%b5%d1%80%d0%b3%d0%be%d1%8d%d1%84%d1%84%d0%b5%d0%ba","status":"publish","type":"post","link":"https:\/\/webhosting.de\/ru\/tickless-kernel-server-energieeffizienz-optimiert-gruen\/","title":{"rendered":"\u042f\u0434\u0440\u043e \u0431\u0435\u0437 \u0433\u0430\u043b\u043e\u0447\u0435\u043a \u0438 \u044d\u043d\u0435\u0440\u0433\u043e\u044d\u0444\u0444\u0435\u043a\u0442\u0438\u0432\u043d\u043e\u0441\u0442\u044c: \u043a\u0430\u043a \u043e\u043f\u0442\u0438\u043c\u0438\u0437\u0438\u0440\u043e\u0432\u0430\u0442\u044c \u0440\u0430\u0431\u043e\u0442\u0443 \u0441\u0435\u0440\u0432\u0435\u0440\u0430"},"content":{"rendered":"<p>Ein <strong>Tickless Kernel<\/strong> reduziert unn\u00f6tige CPU-Aufweckvorg\u00e4nge und senkt dadurch aktiv den Energiebedarf deines Servers, ohne die Reaktionsf\u00e4higkeit unter Last zu verlieren. Ich zeige dir Schritt f\u00fcr Schritt, wie du den <strong>Kernel<\/strong> konfigurierst, Messwerte liest und Workloads so planst, dass sich Leistung und Stromkosten sp\u00fcrbar in Einklang bringen.<\/p>\n\n<h2>Zentrale Punkte<\/h2>\n<p>Die folgenden Punkte skizzieren die wichtigsten Handgriffe und Zusammenh\u00e4nge.<\/p>\n<ul>\n  <li><strong>Tickless<\/strong> Timer: Bedarfsgesteuerte Interrupts statt periodischer Ticks<\/li>\n  <li><strong>Energie<\/strong> sparen: Tiefe C-States l\u00e4nger halten, Wakeups reduzieren<\/li>\n  <li><strong>NO_HZ<\/strong> Optionen: CONFIG_NO_HZ_IDLE und CONFIG_NO_HZ_FULL nutzen<\/li>\n  <li><strong>Scheduler<\/strong> Feinschliff: Last b\u00fcndeln, Interrupt-Affinit\u00e4t setzen<\/li>\n  <li><strong>Monitoring<\/strong> zuerst: Vorher\/Nachher-Messung f\u00fcr klare Effekte<\/li>\n<\/ul>\n\n<h2>Tickless Mode kurz erkl\u00e4rt<\/h2>\n<p>Ein klassischer Linux-<strong>Kernel<\/strong> weckt jede CPU in festen Intervallen auf, oft 100 bis 1000 Mal pro Sekunde. Das kostet messbar <strong>Energie<\/strong>, selbst wenn keine Aufgabe anliegt. Der Tickless Mode ersetzt diese Periodik durch bedarfsgesteuerte Timer-Interrupts. Die CPU bleibt dadurch l\u00e4nger in tiefen Schlafzust\u00e4nden, bis wirklich ein Ereignis vorliegt. Laut [1] steigert genau dieses Verhalten die Effizienz, weil unn\u00f6tige Wakeups entfallen und die Thermik sinkt. Ich nutze Tickless, wenn Systeme stark schwankende Last sehen und zwischen Aktivit\u00e4t und Ruhe sauber wechseln sollen.<\/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\/06\/energieeffizient-serverraum-8347.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Warum Tickless die Energieeffizienz hebt<\/h2>\n<p>Bleibt eine CPU im Idle, verhinderten starre Ticks fr\u00fcher tiefe <strong>C-States<\/strong> und weckten Kerne dauernd auf. Das erzeugte mehr <strong>Abw\u00e4rme<\/strong> und zwang L\u00fcfter zu h\u00f6herer Drehzahl. Tickless beseitigt diesen Dauerwecker und verl\u00e4ngert die Ruhephasen. Ich beobachte bei schwankend ausgelasteten Web- und API-Hosts geringere Leistungsaufnahmen im Leerlauf und glattere Temperaturkurven. In gro\u00dfen Serverfarmen addieren sich kleine Einsparungen pro Node zu sp\u00fcrbaren Euro-Betr\u00e4gen auf der Stromrechnung. Die Plattform bleibt ruhiger, und Lastspitzen lassen sich zuverl\u00e4ssiger abfedern.<\/p>\n\n<h2>Modi und Kernel-Optionen im \u00dcberblick<\/h2>\n<p>Ich unterscheide zwei Hauptans\u00e4tze: Tickless Idle und Tickless Full. Tickless Idle pausiert die Periodik, solange keine Aufgaben anstehen, und spielt seine <strong>St\u00e4rke<\/strong> besonders in Leerlaufphasen aus. Tickless Full (NO_HZ_FULL) reduziert Ticks f\u00fcr ausgew\u00e4hlte Kerne auch im Betrieb, was Latenzen dr\u00fccken und Kontextwechsel senken kann. Moderne Distributionen aktivieren NO_HZ_IDLE oft standardm\u00e4\u00dfig, w\u00e4hrend NO_HZ_FULL gezieltes Tuning verlangt. Beachte, dass erweiterte Modi Feinschliff bei Interrupt-Affinit\u00e4t und Isolierung erfordern, damit die <strong>Vorteile<\/strong> nicht durch zuf\u00e4llige Wakeups verpuffen.<\/p>\n\n<table>\n  <thead>\n    <tr>\n      <th>Modus\/Option<\/th>\n      <th>Wirkung<\/th>\n      <th>Geeignet f\u00fcr<\/th>\n      <th>Hinweise<\/th>\n    <\/tr>\n  <\/thead>\n  <tbody>\n    <tr>\n      <td>CONFIG_NO_HZ_IDLE<\/td>\n      <td>Ticks im Idle aussetzen<\/td>\n      <td>Allgemeine Serverlast mit Idle-Phasen<\/td>\n      <td>Oft per Default aktiv, geringe <strong>Risiken<\/strong><\/td>\n    <\/tr>\n    <tr>\n      <td>CONFIG_NO_HZ_FULL<\/td>\n      <td>Ticks pro Kern im Betrieb minimieren<\/td>\n      <td>Low-Latency, HPC, ausgew\u00e4hlte Kerne<\/td>\n      <td>Kern-Isolierung und IRQ-Affinit\u00e4t sauber <strong>planen<\/strong><\/td>\n    <\/tr>\n    <tr>\n      <td>isolcpus, rcu_nocbs<\/td>\n      <td>St\u00f6rarme Kerne, weniger RCU-Wakeups<\/td>\n      <td>Realtime-\u00e4hnliche Workloads<\/td>\n      <td>Nur wenige Kerne isolieren, Rest tr\u00e4gt <strong>Systemlast<\/strong><\/td>\n    <\/tr>\n    <tr>\n      <td>Kernel \u2265 aktuelle LTS<\/td>\n      <td>Neue Energiesparpfade, Fixes<\/td>\n      <td>Alle Produktivsysteme<\/td>\n      <td>Fixes und Effizienzgewinne laut [1] <strong>nutzen<\/strong><\/td>\n    <\/tr>\n  <\/tbody>\n<\/table>\n\n<h2>Schritt f\u00fcr Schritt: Kernel- und Boot-Parameter setzen<\/h2>\n<p>Ich beginne mit einer Bestandsaufnahme der Kernel-F\u00e4higkeiten. Ob der Kernel Tickless unterst\u00fctzt, erkennst du an den Config-Flags:<\/p>\n<pre><code>grep NO_HZ \/boot\/config-$(uname -r)\ngrep HIGH_RES_TIMERS \/boot\/config-$(uname -r)\ngrep -E 'CPU_IDLE|INTEL_IDLE' \/boot\/config-$(uname -r)\n<\/code><\/pre>\n<p>F\u00fcr NO_HZ_IDLE gen\u00fcgt in der Regel der Distributionskernel. F\u00fcr NO_HZ_FULL lege ich gezielt Housekeeping-CPUs fest, die Systemaufgaben, IRQs und RCU-Callbacks \u00fcbernehmen. Typisch lasse ich CPU 0\u20131 als Housekeeping und setze die restlichen Kerne in den DyTick-Betrieb:<\/p>\n<pre><code># Beispiel GRUB-CMDLINE (an Hardware anpassen):\nGRUB_CMDLINE_LINUX=\"nohz_full=2-15 isolcpus=2-15 rcu_nocbs=2-15 irqaffinity=0-1 nmi_watchdog=0\"\n<\/code><\/pre>\n<p>Wichtig: Mindestens ein Kern muss Housekeeping bleiben, sonst drohen RCU-Stalls. Nach dem Update der GRUB-Config und Reboot pr\u00fcfe ich die aktiven Einstellungen:<\/p>\n<pre><code>cat \/sys\/devices\/system\/cpu\/nohz_full      # listet NO_HZ_FULL-CPUs\ncat \/sys\/devices\/system\/cpu\/isolated       # listet isolierte CPUs\ncat \/proc\/cmdline                          # verifiziert Boot-Parameter\n<\/code><\/pre>\n<p>Zus\u00e4tzlich aktiviere ich High-Resolution-Timer und die idle-spezifischen Treiber (z. B. intel_idle). Beides verbessert die Feink\u00f6rnigkeit der Timer und die Tiefe der Schlafzust\u00e4nde. Wer irqbalance einsetzt, konfiguriert gesperrte Kerne, damit die Affinit\u00e4t nicht wieder auf isolierte CPUs wandert:<\/p>\n<pre><code># Beispiel: IRQBALANCE_BANNED_CPUS in \/etc\/irqbalance\/irqbalance.env\nIRQBALANCE_BANNED_CPUS=0x0003   # CPUs 0-1 erlaubt, Rest gesperrt (Maskenformat je System)\n<\/code><\/pre>\n<p>Ich verifiziere anschlie\u00dfend, dass die Ticks tats\u00e4chlich ausbleiben, indem ich die n\u00e4chsten Wakeups je CPU betrachte:<\/p>\n<pre><code>sudo cat \/proc\/timer_list | grep -A2 'next event' | sed -n '1,60p'\n<\/code><\/pre>\n<p>In Ruhephasen sollten die n\u00e4chsten Ereignisse deutlich in der Zukunft liegen oder komplett fehlen, wenn keine Timer anstehen.<\/p>\n\n<h2>Messdisziplin: Werkzeuge und Kennzahlen<\/h2>\n<p>Ohne Messung bleibt jede Optimierung blind. Ich nehme Basiswerte auf und vergleiche sie nach jeder \u00c4nderung. Bew\u00e4hrt haben sich:<\/p>\n<ul>\n  <li><strong>powertop<\/strong>: Wakeups-from-idle\/s, Top-Verursacher, C-State-Residency<\/li>\n  <li><strong>turbostat<\/strong>: Frequenzen, Package- und Core-C-States, RAPL-Leistung<\/li>\n  <li><strong>perf stat<\/strong>: Kontextwechsel, Timer-Interrupts, Cycles, Instructions<\/li>\n  <li><strong>\/proc\/interrupts<\/strong>: IRQ-Verteilung je CPU<\/li>\n  <li><strong>pidstat\/iostat<\/strong>: Prozess- und I\/O-Charakteristik<\/li>\n<\/ul>\n<pre><code># 10 Minuten Baseline im Idle erfassen\nsudo turbostat --Summary --interval 5 --quiet --show PkgWatt,BUS,CPU%c1,CPU%c6,CPU%c7,MHz\nsudo powertop --time=600 --html=\/tmp\/powertop_baseline.html\n\n# Interrupt-Heatmap\nwatch -n2 'cat \/proc\/interrupts | sed -n \"1,30p\"'\n\n# Kontextwechsel & Timer-Ereignisse\nperf stat -a --delay 5000 --timeout 60000 -e cs,task-clock,cpu-clock,irq_vectors:local_timer\n<\/code><\/pre>\n<p>Ich dokumentiere jeweils: Idle-Leistungsaufnahme (PkgWatt), C-State-Anteile, Wakeups\/s und Latenzmetriken (p95\/p99) meines relevanten Workloads. Schon kleine Differenzen werden \u00fcber Wochen sp\u00fcrbar.<\/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\/06\/server_opt_7895.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Virtualisierung, Container und Tickless im Stack<\/h2>\n<p>Hypervisor und G\u00e4ste erzeugen zusammen viele <strong>Timer<\/strong> und Wakeups, etwa durch Cron, Logging und Agenten. Ich reduziere diese Kette, indem ich Tickless im Hypervisor und in den Gastsystemen aktiviere. Dadurch verschwinden Doppelwecker, und virtuelle CPUs bleiben l\u00e4nger ruhig. In Kubernetes- oder Microservices-Umgebungen sinkt der Grundrauschpegel messbar. Ich stimme zudem Pod- und Batch-Zeiten so ab, dass l\u00e4ngere Ruhefenster entstehen und die <strong>Einsparungen<\/strong> steigen.<\/p>\n<p>In KVM-Umgebungen plane ich vCPU-Pinning und IRQ-Affinit\u00e4t gemeinsam: laute vNIC- oder vBlock-IRQs binde ich an Housekeeping-CPUs, ruhige Workloads auf isolierte Kerne. Gastseitig deaktiviere ich \u00fcberfl\u00fcssige Timerquellen, reduziere Cron-Frequenzen und nutze systemd-Timer mit gro\u00dfz\u00fcgiger Genauigkeit (AccuracySec), damit Events nat\u00fcrlicher geb\u00fcndelt werden. So werden Leerlaufphasen l\u00e4nger \u2013 der Hypervisor profitiert doppelt, weil weniger VM-Exits und -Entries stattfinden.<\/p>\n\n<h2>Praxis-Setup: Power-Profile, Governor, Interrupts<\/h2>\n<p>F\u00fcr schnelle Reaktionen setze ich meist den Governor <strong>schedutil<\/strong> ein, weil er Lastspr\u00fcnge dynamisch abf\u00e4ngt. C-States lasse ich aktiv, au\u00dfer extrem kurze Latenzen haben Vorrang. Ich binde laute IRQs an ausgew\u00e4hlte Kerne und halte andere Kerne frei, damit sie tief schlafen k\u00f6nnen. Batch-Jobs, Backups und Updates plane ich in Bl\u00f6cken, um ruhige Phasen zu b\u00fcndeln. Wer das vertiefen will, findet Hintergr\u00fcnde zur <a href=\"https:\/\/webhosting.de\/server-cpu-frequency-scaling-stromverbrauch-effizient-greenpower\/\">CPU-Frequenzskalierung<\/a>, die ich eng mit Tickless abstimme, um Spitzen sparsam zu bedienen.<\/p>\n<p>Zus\u00e4tzlich justiere ich den Energy-Preference-Bias (EPP\/EPB) moderner CPUs, damit Boosts nur bei Bedarf feuern und Idle-Residenzen hoch bleiben. Services mit toleranter Latenz erhalten gr\u00f6\u00dfere Timer-Slack-Werte (systemd: TimerSlackNSec=), periodische Jobs steuere ich \u00fcber systemd-Timer mit AccuracySec und RandomizedDelaySec. Das verringert Kantenlasten und erzeugt l\u00e4ngere, zusammenh\u00e4ngende Ruhefenster.<\/p>\n<pre><code># Beispiel: IRQ gezielt zuweisen (Achtung: IRQ-Nummer pr\u00fcfen)\necho 0-1 | sudo tee \/proc\/irq\/XX\/smp_affinity_list   # lauten IRQ an Housekeeping binden\n\n# systemd-Timer kooperativ einstellen (Auszug einer .timer-Unit)\nAccuracySec=5min\nRandomizedDelaySec=30min\nPersistent=true\n<\/code><\/pre>\n\n\n<figure class=\"wp-block-image size-full is-resized\">\n  <img decoding=\"async\" src=\"https:\/\/webhosting.de\/wp-content\/uploads\/2026\/06\/energy-efficient-server-tickless-4729.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>NUMA und Lastb\u00fcndelung sinnvoll einsetzen<\/h2>\n<p>In Multi-Core- und NUMA-Hosts erh\u00f6he ich die <strong>Effizienz<\/strong>, indem ich Last bewusst auf wenige Kerne konzentriere. Freie Kerne fallen dadurch tiefer und l\u00e4nger in C-States. Ich achte darauf, Speicherzugriffe NUMA-lokal zu halten, damit keine unn\u00f6tigen Wanderungen entstehen. Der Linux-Scheduler hilft, doch manuelles Pinning f\u00fcr Hot-Threads stellt oft den letzten Feinschliff dar. Mit Tickless erreicht dieses B\u00fcndeln mehr Wirkung, weil isolierte Kerne nicht durch Periodik geweckt werden und so echte <strong>Ruhe<\/strong> haben.<\/p>\n<p>In der Praxis ordne ich I\/O-lastige Threads bevorzugt denselben NUMA-Knoten zu und isoliere CPU-intensive Services auf wenige Kerne dieses Knotens. Cgroups (cpuset, cpu) helfen, Grenzen sauber zu ziehen. Transparent Huge Pages und AutoNUMA pr\u00fcfe ich workload-spezifisch: Sie k\u00f6nnen helfen, aber bei Latenz-Jitter entgegenwirken. Wichtig ist, dass mindestens ein Knoten genug Housekeeping-Kapazit\u00e4t beh\u00e4lt, damit Systemaufgaben nicht in kritische Kerne hineinplatzen.<\/p>\n\n<h2>Latenzanforderungen austarieren und messen<\/h2>\n<p>Manche Echtzeit- oder Trading-Workloads verlangen k\u00fcrzeste <strong>Antwortzeiten<\/strong>. Ich f\u00fchre daher Tests mit produktionsnahen Samples durch und vergleiche Latenzpercentiles vor und nach Tickless-\u00c4nderungen. NO_HZ_FULL kann Kontextwechsel und Timer-Noise senken, doch tiefe C-States verl\u00e4ngern gelegentlich Wakeup-Pfade. Mit Telemetrie f\u00fcr C-States, Frequenz, Paketlatenzen und Jitter treffe ich fundierte Entscheidungen. Wer zudem den Kernel pflegt, profitiert mehrfach \u2013 Performance-Tuning und Sicherheitsfixes greifen ineinander, wie die Praxis zeigt; hierzu passt mein Verweis auf <a href=\"https:\/\/webhosting.de\/linux-kernel-performance-hosting-optimierung-kernelboost\/\">Kernel-Optimierung<\/a>, die ich konsequent in Wartungsfenster integriere.<\/p>\n<p>Ich teste gezielt Burst-Szenarien (kurze, intensive Phasen) und korreliere Latenzspitzen mit Frequenz- und C-State-Traces. Hilfreich sind dabei Messungen mit festgesetztem EPP, alternativ ein kurzer Test mit begrenzten C-States, um den Anteil der Aufwachlatenz sichtbar zu machen. Werden NO_HZ_FULL-Kerne genutzt, stelle ich sicher, dass Housekeeping-CPUs nicht unterversorgt sind \u2013 sonst drohen RCU-Warnungen oder sporadische Jitter.<\/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\/06\/tickless_kernel_ser_3124.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Sicherheit: Aktuelle Kernel zahlen doppelt ein<\/h2>\n<p>Ich halte Systeme <strong>aktuell<\/strong>, weil neue Kernel nicht nur Energiesparpfade verfeinern, sondern auch L\u00fccken schlie\u00dfen. Berichte zu Kernel-Schwachstellen belegen, dass Angreifer gelegentlich mit wenig Aufwand Rechte ausweiten konnten. Mit Updates senke ich dieses Risiko und sichere zugleich die Effizienzgewinne moderner Mechanismen ab [2]. In Summe steigt die Betriebssicherheit, und ungeplante Ausf\u00e4lle belasten weder Nerven noch Budget. Genau diese Kombination aus Sicherheit und <strong>Effizienz<\/strong> macht regelm\u00e4\u00dfige Updates zu einer einfachen Entscheidung.<\/p>\n\n<h2>Rechenzentrumseffekt: PUE, L\u00fcfter, Netzteile<\/h2>\n<p>Weniger Wakeups reduzieren die <strong>Last<\/strong> auf K\u00fchlung und Stromverteilung messbar. CPU-Spitzen werden glatter, L\u00fcfter laufen seltener am Limit und Netzteile arbeiten effizienter. Dieser Dominoeffekt wirkt direkt auf die PUE eines Standortes. Wer sich breiter informieren will, schaut auf das Thema <a href=\"https:\/\/webhosting.de\/green-data-center-hosting-pue-wert-nachhaltigkeit-trend\/\">gr\u00fcnes Rechenzentrum<\/a> und setzt Tickless als Baustein in ein ganzheitliches Energiemanagement. Ich plane Ma\u00dfnahmen stets zusammen, denn Hardware, OS und Workload tragen gemeinsam zur <strong>Einsparung<\/strong> bei.<\/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\/06\/server_optimierung_3369.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>WordPress, PHP und Datenbanken praxisnah trimmen<\/h2>\n<p>Auf CMS-Stacks mit vielen kurzen <strong>Anfragen<\/strong> profitiere ich stark von Cache-Schichten und sauberem PHP-FPM-Tuning. Ich halte opcache warm, versiegele Chatty-Plugins und minimiere cron-Noise durch stapelnde Aufgabenfenster. Datenbanken erhalten klare Wartungszeitr\u00e4ume, damit sie I\/O-Spitzen nicht in die Tageslast schieben. Zusammen mit Tickless sinkt der Grundl\u00e4rm, und der Server f\u00e4llt schneller in den Idle. So kombiniert die Plattform Leistung pro Watt, ohne dass Nutzer sp\u00fcrbare <strong>Einbu\u00dfen<\/strong> sehen.<\/p>\n<p>Konkret reduziere ich WordPress-Cron-Trigger, verlagere wiederkehrende Arbeiten in systemd-Timer mit Koaleszenz und halte PHP-FPM-Worker so dimensioniert, dass kurze Lastwellen bedient werden, ohne einen hohen Dauersockel offener Worker zu halten. Datenbanken profitieren von klaren Autovacuum-Fenstern (bei Bedarf drosseln\/verschieben) und von konsistenten &quot;Maintenance-Bl\u00f6cken&quot;. Jede regelm\u00e4\u00dfige, aber nicht zeitkritische Aufgabe b\u00fcndele ich lieber grob-granular als sie im Sekundenraster feuern zu lassen.<\/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\/06\/serverraum-optimierung-8471.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>BIOS\/UEFI und Hardware-Pfade<\/h2>\n<p>Ich setze schon im BIOS\/UEFI die Basis: tiefe Package-C-States aktivieren, ASPM\/PCIe-L1-Substates nutzen und Energiesparfunktionen nicht pauschal deaktivieren. Nur wenn spezielle Latenzziele es erzwingen, begrenze ich C-State-Tiefen testweise. Netzwerkkarten und NVMe-Controller profitieren von stromsparenden Modi; dennoch pr\u00fcfe ich, ob aggressives Power-Management Latenzspitzen erzeugt. Feinf\u00fchliges Austarieren lohnt: Ein Gang weniger bei maximaler Stromsparstrenge kann im 99p-Latenzbereich gro\u00dfe Wirkung haben.<\/p>\n\n<h2>Netzwerk und Storage: Wakeups weiter dr\u00fccken<\/h2>\n<p>Der Netzwerk-Stack triggert oft viele IRQs. Ich erh\u00f6he die Coalescing-Parameter vorsichtig, um Interrupt-St\u00fcrme zu gl\u00e4tten, ohne Latenz unn\u00f6tig zu verschlechtern:<\/p>\n<pre><code># Beispiel (Werte workload-spezifisch abstimmen!)\nsudo ethtool -C eth0 rx-usecs 16 rx-frames 16 tx-usecs 16 tx-frames 16\n<\/code><\/pre>\n<p>GRO\/LRO und RSS skaliere ich passend zur CPU-Topologie, damit wenige Kerne den Gro\u00dfteil des Interrupt-L\u00e4rms tragen. Auf der Storage-Seite pr\u00fcfe ich, ob die Ger\u00e4teeigenschaften (z. B. NVMe-APST) bereits optimal gesetzt sind und Lastspitzen nicht durch Hintergrundjobs (Scrubs, Rebuilds) in Tagesspitzen hineinragen. Ziel ist, planbare I\/O-Bursts in definierte Fenster zu schieben.<\/p>\n\n<h2>Fehlerbilder und Troubleshooting<\/h2>\n<p>Tickless-Setups scheitern selten an der Grundmechanik, h\u00e4ufiger am Feinschliff:<\/p>\n<ul>\n  <li><strong>RCU-Stalls<\/strong>: Treten nach NO_HZ_FULL auf, sind meist zu wenige Housekeeping-CPUs oder zu viel IRQ-Last auf isolierten Kernen die Ursache. Mehr Housekeeping-Kapazit\u00e4t einplanen.<\/li>\n  <li><strong>Unerwartete Wakeups<\/strong>: Powertop zeigt Schuldige. H\u00e4ufige Quellen sind Telemetrie-Agenten, kurze Timer-Intervalle oder Chatty-Logs.<\/li>\n  <li><strong>Ungleiche IRQ-Verteilung<\/strong>: \/proc\/interrupts pr\u00fcfen und Affinit\u00e4ten nachjustieren; irqbalance korrekt konfigurieren.<\/li>\n  <li><strong>Latenz-Jitter<\/strong>: C-State-Tiefe, EPP und Coalescing schrittweise variieren und p99 beobachten; kleine Anpassungen reichen oft.<\/li>\n<\/ul>\n<p>F\u00fcr reproduzierbare Ergebnisse arbeite ich mit Change-Windows, klaren Rollback-Punkten und exakt dokumentierten Parametern. Jede \u00c4nderung bekommt eine Messrunde \u2013 erst dann folgt der n\u00e4chste Schritt.<\/p>\n\n<h2>Konkrete Schritte f\u00fcr deinen Start<\/h2>\n<p>Ich beginne mit einem aktuellen <strong>Kernel<\/strong> und pr\u00fcfe, ob NO_HZ_IDLE aktiv ist. Danach messe ich Baselines: Idle-Leistungsaufnahme, Temperatur, C-States, IRQ-Rate und Latenz. Anschlie\u00dfend aktiviere ich Tickless-Optionen und wiederhole die Messungen. Finde ich Einsparungen, sichere ich die Konfiguration in Code- und Dokumentations-Repos. Bei Bedarf teste ich NO_HZ_FULL f\u00fcr ausgew\u00e4hlte Kerne und isoliere diese mit sorgsamer IRQ-Zuordnung, damit die <strong>Wirkung<\/strong> sichtbar bleibt.<\/p>\n<p>Mein pragmatischer Ablauf:<\/p>\n<ol>\n  <li>Baseline erheben (10\u201315 Minuten Idle + kurzer Lasttest, Metriken sichern)<\/li>\n  <li>NO_HZ_IDLE \u00fcberpr\u00fcfen, High-Res-Timer und Idle-Treiber validieren<\/li>\n  <li>IRQ-Affinit\u00e4t und irqbalance anpassen, laute IRQs auf Housekeeping<\/li>\n  <li>Timer-Koaleszenz erh\u00f6hen (systemd-Timer, TimerSlack, Cron-Intervalle)<\/li>\n  <li>Optional: NO_HZ_FULL auf ausgew\u00e4hlte Kerne + rcu_nocbs, mindestens 1\u20132 Housekeeping-CPUs freilassen<\/li>\n  <li>NUMA- und CPU-Pinning, Cgroup-Grenzen und Batch-Fenster nachziehen<\/li>\n  <li>Vorher\/Nachher vergleichen, Entscheidungen dokumentieren<\/li>\n<\/ol>\n\n<h2>Mein Kurz-Res\u00fcmee<\/h2>\n<p>Tickless bringt messbare <strong>Energie<\/strong>&#8211; und Thermikvorteile, gerade bei flexiblen Workloads mit l\u00e4ngeren Idle-Phasen. Ich setze zuerst auf NO_HZ_IDLE und kombiniere das mit sinnvollen Power-Profilen. Danach feile ich an IRQ-Affinit\u00e4ten, Lastb\u00fcndelung und Messdisziplin. F\u00fcr besonders latenzkritische Szenarien nutze ich NO_HZ_FULL dosiert und evaluiere den Trade-off mit realistischen Tests [1]. Wer Technologie, Workload-Design und Monitoring zusammenf\u00fchrt, sch\u00f6pft die <strong>Potenziale<\/strong> dieser Kernel-Funktion dauerhaft aus.<\/p>","protected":false},"excerpt":{"rendered":"<p>\u0423\u0437\u043d\u0430\u0439\u0442\u0435, \u043a\u0430\u043a \u0445\u043e\u0441\u0442\u0438\u043d\u0433 Tickless Kernel \u043f\u043e\u0432\u044b\u0448\u0430\u0435\u0442 \u044d\u043d\u0435\u0440\u0433\u043e\u044d\u0444\u0444\u0435\u043a\u0442\u0438\u0432\u043d\u043e\u0441\u0442\u044c \u0432\u0430\u0448\u0435\u0433\u043e \u0441\u0435\u0440\u0432\u0435\u0440\u0430 \u0438 \u043a\u0430\u043a \u0446\u0435\u043b\u0435\u043d\u0430\u043f\u0440\u0430\u0432\u043b\u0435\u043d\u043d\u0430\u044f \u043d\u0430\u0441\u0442\u0440\u043e\u0439\u043a\u0430 linux \u0441\u043d\u0438\u0436\u0430\u0435\u0442 \u0437\u0430\u0442\u0440\u0430\u0442\u044b \u043d\u0430 \u044d\u043b\u0435\u043a\u0442\u0440\u043e\u044d\u043d\u0435\u0440\u0433\u0438\u044e \u0438 \u0432\u044b\u0431\u0440\u043e\u0441\u044b CO\u2082 \u0432 \u0446\u0435\u043d\u0442\u0440\u0435 \u043e\u0431\u0440\u0430\u0431\u043e\u0442\u043a\u0438 \u0434\u0430\u043d\u043d\u044b\u0445.<\/p>","protected":false},"author":1,"featured_media":19794,"comment_status":"","ping_status":"","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"inline_featured_image":false,"footnotes":""},"categories":[681],"tags":[],"class_list":["post-19801","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-cloud_computing"],"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":"83","_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 Kernel","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":"19794","footnotes":null,"_links":{"self":[{"href":"https:\/\/webhosting.de\/ru\/wp-json\/wp\/v2\/posts\/19801","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/webhosting.de\/ru\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/webhosting.de\/ru\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/webhosting.de\/ru\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/webhosting.de\/ru\/wp-json\/wp\/v2\/comments?post=19801"}],"version-history":[{"count":0,"href":"https:\/\/webhosting.de\/ru\/wp-json\/wp\/v2\/posts\/19801\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/webhosting.de\/ru\/wp-json\/wp\/v2\/media\/19794"}],"wp:attachment":[{"href":"https:\/\/webhosting.de\/ru\/wp-json\/wp\/v2\/media?parent=19801"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/webhosting.de\/ru\/wp-json\/wp\/v2\/categories?post=19801"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/webhosting.de\/ru\/wp-json\/wp\/v2\/tags?post=19801"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}