{"id":20786,"date":"2026-08-19T08:34:46","date_gmt":"2026-08-19T06:34:46","guid":{"rendered":"https:\/\/webhosting.de\/cpu-governor-hosting-server-performance\/"},"modified":"2026-08-19T08:34:46","modified_gmt":"2026-08-19T06:34:46","slug":"cpu-regelaar-prestaties-van-de-hostserver","status":"publish","type":"post","link":"https:\/\/webhosting.de\/nl\/cpu-governor-hosting-server-performance\/","title":{"rendered":"CPU-governor op hostingservers: prestaties op de juiste manier regelen"},"content":{"rendered":"<p>Wer Hosting-Server z\u00fcgig und verl\u00e4sslich antworten lassen will, steuert den <strong>CPU Governor<\/strong> bewusst und pr\u00fcft das Taktverhalten unter realer Last. Ich priorisiere klare Leistung, kontrolliere Latenzen und passe die <strong>Frequenzskalierung<\/strong> so an, dass Web, Datenbank und PHP ohne Verz\u00f6gerung reagieren.<\/p>\n\n<h2>Zentrale Punkte<\/h2>\n\n<p>Bevor ich konkrete Einstellungen setze, fasse ich die wichtigsten Stellhebel kurz zusammen und ordne sie nach Nutzen im Hosting-Alltag ein. So entsteht ein klares Bild, wie ich Takt, Latenz und Effizienz zusammenf\u00fchre. Diese Punkte geben mir eine schnelle Entscheidungshilfe f\u00fcr produktive Server. Ich bewerte dabei sowohl harte Fakten als auch das Verhalten bei echten Zugriffsspitzen. Das sorgt f\u00fcr <strong>konsistente<\/strong> Abl\u00e4ufe und spart langfristig <strong>Zeit<\/strong>.<\/p>\n<ul>\n  <li><strong>performance<\/strong>: H\u00f6chster Takt, sehr geringe Latenz bei Lastspitzen.<\/li>\n  <li><strong>powersave<\/strong>: Niedriger Takt, geringerer Verbrauch bei seltener Last.<\/li>\n  <li><strong>ondemand\/schedutil<\/strong>: Dynamisch, skaliert je nach Auslastung.<\/li>\n  <li><strong>Messung<\/strong>: Vorher\/Nachher-Vergleich f\u00fcr echte Aussagekraft.<\/li>\n  <li><strong>Persistenz<\/strong>: Setzung per systemd oder Boot-Optionen sichern.<\/li>\n<\/ul>\n<p>Ich nutze diese Liste als Startpunkt und entscheide danach gezielt pro Workload. So erh\u00f6he ich die <strong>Reaktionsgeschwindigkeit<\/strong> und vermeide wechselhaftes <strong>Taktverhalten<\/strong>.<\/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\/08\/cpu-governor-server-5892.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Was ein CPU Governor auf Hosting-Servern steuert<\/h2>\n\n<p>Ein Governor bestimmt, wie das System die <strong>CPU-Frequenz<\/strong> an die Auslastung koppelt und wie schnell Kerne hochtakten. Ich fokussiere mich dabei auf die Zeit bis zum ersten Taktboost, weil sie direkt die <strong>Latenz<\/strong> bei Webrequests pr\u00e4gt. Bei vielen kurzen Requests bringen schnelle Taktwechsel handfeste Vorteile, w\u00e4hrend sparsame Strategien eher f\u00fcr Leerlaufphasen taugen. Linux regelt das \u00fcber die CPU-Frequenzskalierung, die je nach Governor aggressiv oder vorsichtig reagiert. Entscheidend ist am Ende, dass der Server unter realer Last konsistent schnell anspringt.<\/p>\n\n<h2>Treiber und Plattformunterschiede: intel_pstate, amd_pstate, acpi_cpufreq<\/h2>\n<p>Die Wahl und Wirkung eines Governors h\u00e4ngt stark vom aktiven Treiber ab. Moderne Intel-Server nutzen h\u00e4ufig <em>intel_pstate<\/em> (HWP), aktuelle AMD-Generationen <em>amd_pstate<\/em>; klassisch bleibt <em>acpi_cpufreq<\/em>.<\/p>\n<ul>\n  <li><strong>intel_pstate<\/strong>: Bietet meist nur <em>performance<\/em> und <em>powersave<\/em>. Feintuning l\u00e4uft \u00fcber die <em>Energy Performance Preference<\/em> (EPP). Werte wie <em>performance<\/em>, <em>balance_performance<\/em>, <em>balance_power<\/em> und <em>power<\/em> beeinflussen, wie aggressiv geboostet wird.<\/li>\n  <li><strong>amd_pstate<\/strong>: Vergleichbare Logik mit EPP\/Energy-Policy, je nach Kernel-Version als <em>guided<\/em> oder <em>active<\/em> Modus. Reagiert in der Praxis sehr flott auf Lastspitzen.<\/li>\n  <li><strong>acpi_cpufreq<\/strong>: Klassisches Modell mit breiter Governor-Auswahl (z. B. <em>ondemand<\/em>, <em>conservative<\/em>, <em>schedutil<\/em>). Hier wirkt der Governor besonders direkt auf die Skala.<\/li>\n<\/ul>\n<p>Ich pr\u00fcfe daher zuerst, welcher Treiber geladen ist (<code>cpupower frequency-info<\/code>), und passe die Erwartung an die Plattform an. Wo EPP greift, setze ich beim Performance-Ziel zus\u00e4tzlich eine \u201cbalance_performance\u201d-Pr\u00e4ferenz, wenn ich minimalen Verbrauch bei nahezu identischer Latenz m\u00f6chte.<\/p>\n\n<h2>Welche Modi es gibt und wann sie passen<\/h2>\n\n<p>Die g\u00e4ngigen Modi hei\u00dfen <strong>performance<\/strong>, <strong>powersave<\/strong>, ondemand, conservative und schedutil; Ubuntu, Red Hat und die Kernel-Dokumentation beschreiben diese Varianten seit Jahren. Laut Ubuntu Server Docs h\u00e4lt performance den h\u00f6chsten Takt und zielt klar auf Geschwindigkeit, w\u00e4hrend Red Hat powersave als Modus mit maximaler Energieersparnis und geringster Leistung einordnet. Ich setze performance f\u00fcr Webserver, stark frequentierte WordPress-Instanzen und API-Dienste, die schnelle Antwortzeiten fordern. Bei selten genutzten Maschinen mit hohem Leerlauf ist powersave eine Option, wenn Energie Priorit\u00e4t hat. Dynamische Modi wie schedutil liefern einen Mittelweg, reagieren aber je nach Kernel und Hardware unterschiedlich flink.<\/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\/cpugovernor_meeting_4092.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Turbo, Min-\/Max-Frequenzen und Boost-Grenzen<\/h2>\n<p>Neben dem Governor sind Turbo-Mechanismen und Frequenzlimits zentrale Stellschrauben. Ich definiere bewusst Unter- und Obergrenzen, damit Kerne unter Last sofort hochschalten und nicht in zu niedrigen P-States verharren.<\/p>\n<ul>\n  <li><strong>Min-\/Max-Frequenzen:<\/strong> Untergrenze anheben, damit Short-Bursts nicht vom Kaltstart kommen; Obergrenze pr\u00fcfen, um Drosselung auszuschlie\u00dfen.<\/li>\n  <li><strong>Turbo\/Boost:<\/strong> F\u00fcr niedrige Latenz in der Regel aktivieren; dabei thermische und elektrische Limits im Blick behalten (PL1\/PL2\/EDP bei Intel, PPT\/TDC\/EDC bei AMD).<\/li>\n<\/ul>\n<p>Typische Kommandos f\u00fcr Tests (Distributionen k\u00f6nnen abweichen):<\/p>\n<pre><code># aktuellen Bereich und Treiber anzeigen\ncpupower frequency-info\n\n# Governor auf Performance\ncpupower frequency-set -g performance\n\n# Min-\/Max-Frequenz (Beispielwerte) setzen\ncpupower frequency-set -d 3.0GHz\ncpupower frequency-set -u 4.8GHz\n\n# Intel Turbo (intel_pstate) tempor\u00e4r deaktivieren\/aktivieren\necho 1 &gt; \/sys\/devices\/system\/cpu\/intel_pstate\/no_turbo    # 1 = aus, 0 = an\n\n# AMD Boost (je nach Kernel\/Plattform)\necho 1 &gt; \/sys\/devices\/system\/cpu\/cpufreq\/boost\n<\/code><\/pre>\n<p>Ich \u00e4ndere diese Parameter nur testweise und messe unmittelbar danach, ob sich Latenz und Stabilit\u00e4t tats\u00e4chlich verbessern.<\/p>\n\n<h2>Praxisleitfaden: Governor pr\u00fcfen und umschalten<\/h2>\n\n<p>Ich starte jede Optimierung mit einem Blick auf den aktuell gesetzten <strong>Governor<\/strong>. Das gelingt per <code>cat \/sys\/devices\/system\/cpu\/cpu*\/cpufreq\/scaling_governor<\/code> oder mit <code>cpupower frequency-info<\/code>, das zus\u00e4tzlich Frequenzspannen und Treiber zeigt. F\u00fcr produktive Webserver schalte ich h\u00e4ufig mit <code>cpupower frequency-set -g performance<\/code> auf den Hochleistungsmodus. Anschlie\u00dfend verifiziere ich das Ergebnis erneut, um Fehlkonfigurationen auszuschlie\u00dfen. Ohne diese Kontrolle riskiere ich inkonsistente <strong>Antwortzeiten<\/strong>, die vermeidbar sind.<\/p>\n\n<h2>Automatisierte Smoke- und Regressions-Tests<\/h2>\n<p>Nach dem Umschalten lasse ich kurze, reproduzierbare Tests laufen, um Ausrei\u00dfer schnell zu erkennen. Ich kombiniere Microbenchmarks (einzelner Endpunkt, warmer\/kalter Cache) mit kurzen Stresstests und messe p50\/p95\/p99 der Antwortzeiten. Wichtig ist, dass die Testdaten und -routen realit\u00e4tsnah sind (z. B. Shop-Checkout, Suche, Cache-Miss beim Startpfad). Ich wiederhole die L\u00e4ufe mehrfach und mitt(e)le gezielt, um Jitter von Netz und Storage auszufiltern.<\/p>\n\n<h2>Messbar schneller: Latenz, Takt und Lastspitzen<\/h2>\n\n<p>Vor der Umstellung erfasse ich Ausgangswerte f\u00fcr <strong>Latenz<\/strong>, CPU-Last, Fehlerquote und Energieaufnahme, etwa mit abgetrennten Benchmarks und echten Zugriffsprofilen. Danach wiederhole ich dieselben Tests mit identischer Datenbasis, damit ich Ver\u00e4nderungen sauber vergleichen kann. Ein besonderes Augenmerk lege ich auf <strong>Spikes<\/strong> bei kurzer, hoher Parallelit\u00e4t, wie sie bei Shop-Checkouts oder Cache-Misses auftreten. Tritt dabei Drosselung auf, pr\u00fcfe ich das Umfeld, beispielsweise m\u00f6gliches <a href=\"https:\/\/webhosting.de\/cpu-throttling-shared-hosting-erkennen-optimierung\/\">CPU Throttling<\/a> in geteilten Umgebungen. Erst wenn die Messung klaren Nutzen zeigt, \u00fcbernehme ich die Konfiguration dauerhaft.<\/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\/cpu-governor-hosting-server-4352.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Werkzeuge und Metriken: wie ich Effekte sichtbar mache<\/h2>\n<ul>\n  <li><strong>turbostat<\/strong>: Zeigt pro Paket\/Kern Takt, C-States, Turbo-Anteil und Energie. Ideal, um Boost-Reaktionszeit und Residency zu pr\u00fcfen.<\/li>\n  <li><strong>perf stat<\/strong>: Misst Instruktionen\/Zyklus (IPC), Kontextwechsel und Branch-Miss \u2013 gut, um CPU-Bottlenecks einzuordnen.<\/li>\n  <li><strong>pidstat\/iostat\/vmstat<\/strong>: Erg\u00e4nzen Sicht auf Prozesse, I\/O-Wartezeiten und Systemdruck.<\/li>\n  <li><strong>PSI (Pressure Stall Information)<\/strong>: Bewertet, ob CPU\/IO\/Memory-Pressure Latenz erzeugt \u2013 hilfreich neben der reinen Taktbetrachtung.<\/li>\n  <li><strong>Server-Metriken<\/strong>: p50\/p95\/p99 Latenzen je Endpoint, Fehlerquote, Rate, S\u00e4ttigung. Ohne diese Kenngr\u00f6\u00dfen bleiben Governor-\u00c4nderungen anekdotisch.<\/li>\n<\/ul>\n<p>Ich korreliere Taktkurven mit Latenzen in derselben Zeitachse. Springt der Takt erst nach 20\u201350 ms hoch, sieht man das meist in der p95. Ziel ist, dass der erste relevante Worker-Thread bereits im hohen P-State startet.<\/p>\n\n<h2>Vergleichstabelle: Governors im Hosting-Einsatz<\/h2>\n\n<p>Die folgende \u00dcbersicht ordnet die g\u00e4ngigen Modi nach Taktverhalten und Hosting-Eignung ein. Ich nutze sie als schnelle <strong>Entscheidungshilfe<\/strong>, ersetze damit aber keine eigenen Tests unter realer <strong>Last<\/strong>.<\/p>\n<table>\n  <thead>\n    <tr>\n      <th>Governor<\/th>\n      <th>Taktverhalten<\/th>\n      <th>Eignung Hosting<\/th>\n      <th>Vorteil<\/th>\n      <th>Nachteil<\/th>\n    <\/tr>\n  <\/thead>\n  <tbody>\n    <tr>\n      <td>performance<\/td>\n      <td>Maximal, statisch hoch<\/td>\n      <td>Web, Shop, API, DB<\/td>\n      <td>Sehr geringe Latenz<\/td>\n      <td>H\u00f6herer Verbrauch<\/td>\n    <\/tr>\n    <tr>\n      <td>powersave<\/td>\n      <td>Minimal, z\u00f6gerlich hoch<\/td>\n      <td>Seltene Last, Dev\/Test<\/td>\n      <td>Weniger Energie<\/td>\n      <td>Reduzierte Performance<\/td>\n    <\/tr>\n    <tr>\n      <td>ondemand<\/td>\n      <td>Dynamisch, lastgesteuert<\/td>\n      <td>Gemischte Workloads<\/td>\n      <td>Guter Kompromiss<\/td>\n      <td>Reaktionszeit variiert<\/td>\n    <\/tr>\n    <tr>\n      <td>schedutil<\/td>\n      <td>Scheduler-basiert<\/td>\n      <td>Aktuelle Kernel<\/td>\n      <td>Feink\u00f6rnige Regelung<\/td>\n      <td>Hardwareabh\u00e4ngig<\/td>\n    <\/tr>\n    <tr>\n      <td>conservative<\/td>\n      <td>Langsam steigend<\/td>\n      <td>Langl\u00e4ufer, Batch<\/td>\n      <td>Sanfte Skalierung<\/td>\n      <td>Tr\u00e4ge bei Spikes<\/td>\n    <\/tr>\n  <\/tbody>\n<\/table>\n<p>Die Einordnung spiegelt Erfahrungen aus produktiven Setups wider und deckt sich mit Beschreibungen in Kernel- und Distributionsdokumenten. Konkrete Hardware kann das Verhalten ver\u00e4ndern, daher pr\u00fcfe ich stets vor Ort unter typischer Nutzung.<\/p>\n\n<h2>Workload-Typen: Web, Shop, Datenbank, API<\/h2>\n\n<p>Bei WordPress, WooCommerce und Headless-APIs z\u00e4hlt jede <strong>Millisekunde<\/strong> bis zur ersten Antwort, daher performt ein hoher Takt meist besser. Datenbanken profitieren, wenn Single-Thread-Phasen schnell abgearbeitet werden; die <a href=\"https:\/\/webhosting.de\/cpu-taktrate-wichtiger-als-kerne-hosting-performance-serverflux\/\">Taktrate wichtiger als Kerne<\/a> zeigt sich oft deutlicher als reine Kernanzahl. F\u00fcr Batch- oder Reporting-Jobs kann ein dynamischer Governor reichen, solange keine Nutzer warten. Kritisch sind gemischte Workloads mit vielen kurzen Spitzen, etwa Cron, PHP-FPM und Cache-Misses zeitgleich. In solchen Szenarien verschafft mir ein konsequenter performance-Modus die konstanteste Reaktionszeit.<\/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\/cpu_governor_nacht_tech_office_8271.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Details je Workload: PHP-FPM, NGINX, DB-Server<\/h2>\n<ul>\n  <li><strong>PHP-FPM<\/strong>: Viele kurze, CPU-gebundene Bursts. Ich stelle sicher, dass <em>pm.max_children<\/em> und Prozessanzahl zur Kernzahl passen und die ersten Worker nicht im Low-P-State starten. Reuseport bei NGINX hilft, Last gleichm\u00e4\u00dfig \u00fcber Kerne zu verteilen.<\/li>\n  <li><strong>NGINX\/Apache<\/strong>: Accept-Threads sollten auf wenig ausgelastete Kerne pinnen; IRQ-Balancing und Affinity verhindern Staus auf einzelnen Cores. Ein hoher Grundtakt verk\u00fcrzt TLS-Handshakes und Header-Verarbeitung.<\/li>\n  <li><strong>Datenbanken<\/strong>: Kurze Single-Thread-Phasen (Parse\/Plan\/Index-Hits) profitieren stark vom Boost. L\u00e4ngere, parallele Scans h\u00e4ngen st\u00e4rker an I\/O und Speicher, hier ist Konsistenz wichtiger als Maximalfrequenz.<\/li>\n<\/ul>\n<p>Ich teste sowohl Warm- als auch Kaltpfade: Cache-Warmup darf nicht zum \u201cSchneckengang\u201d verkommen, nur weil die CPU in einem Sparzustand verharrt.<\/p>\n\n<h2>NUMA, IRQs und Thread-Affinit\u00e4t<\/h2>\n<p>Neben dem Governor bestimmen Topologie und Interrupt-Verteilung die Latenz. Ich strebe kurze Wege an: Web- und PHP-Prozesse sollen Speicher und IRQs aus demselben NUMA-Knoten nutzen, in dem sie rechnen. IRQ-Balancing pr\u00fcfe ich regelm\u00e4\u00dfig, insbesondere nach Kernel-Updates.<\/p>\n<ul>\n  <li><strong>cpuset\/affinity<\/strong>: Kritische Dienste auf Kerngruppen pinnen, die nicht vom Storage- oder Netz-IRQ \u00fcberfahren werden.<\/li>\n  <li><strong>Scheduler-Isolation<\/strong>: Auf besonders latenzkritischen Systemen einzelne Kerne isolieren (isolcpus\/rcu_nocbs) und dort Hot-Path-Worker anheften.<\/li>\n  <li><strong>Transparenz<\/strong>: Mit <em>htop<\/em> oder <em>ps -eo pid,psr,comm<\/em> sehe ich, ob Threads \u00fcber Kerne \u201cspringen\u201d und Cache-Lokalit\u00e4t verlieren.<\/li>\n<\/ul>\n\n<h2>Virtualisierung und Provider-Stack<\/h2>\n\n<p>Auf VMs und Containern h\u00e4ngt das Taktverhalten zus\u00e4tzlich von Hypervisor- und Host-Settings ab, weshalb ich die <strong>Umgebung<\/strong> immer mitpr\u00fcfe. Manche Provider pinnen Frequenzen, andere erlauben flexible Boosts oder priorisieren bestimmte Instanzen. Wenn Taktwechsel im Gast kaum Wirkung zeigen, verlagere ich die Analyse auf Host-Seite oder frage gezielt nach Limits. Bei dedizierten Servern erhalte ich mehr Kontrolle, muss aber BIOS\/UEFI- und Kernel-Treiber sauber konfigurieren. Klare Transparenz \u00fcber diese Kette verhindert Fehlinterpretationen bei der <strong>Messung<\/strong>.<\/p>\n\n<h2>Container, Cgroups v2 und Kubernetes<\/h2>\n<p>In Containern bestimmt Cgroups v2 ma\u00dfgeblich, wie die CPU skaliert. Ich achte auf:<\/p>\n<ul>\n  <li><strong>CPU.max\/Quota<\/strong>: Zu enge Quoten verursachen Throttling und Jitter \u2013 erkennbar \u00fcber erh\u00f6hte p99 und <em>nr_throttled<\/em>-Z\u00e4hler.<\/li>\n  <li><strong>CPU.shares<\/strong>: Definiert relative Priorit\u00e4t. Kritische Services erhalten h\u00f6here Shares, damit sie bei Contention bevorzugt werden.<\/li>\n  <li><strong>cpuset<\/strong>: F\u00fcr stabile Latenz pinne ich Container auf zusammenh\u00e4ngende Kerne desselben NUMA-Nodes.<\/li>\n  <li><strong>Scheduler-Interaktion<\/strong>: <em>schedutil<\/em> kann in Kombination mit stark schwankender Container-Last tr\u00e4ge wirken; auf Hostebene \u201cperformance\u201d stabilisiert den Unterbau.<\/li>\n<\/ul>\n<p>Ich teste immer zuerst auf dem Host die Wirkung des Governors. Wenn der Container dennoch schwankt, liegt die Ursache oft in Quotas oder Oversubscription, nicht im Governor.<\/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\/developer_desk_cpu_gov_8364.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>BIOS\/UEFI, C-States und Energiepr\u00e4ferenzen<\/h2>\n<p>Der Unterbau entscheidet, wie flink Boosts gez\u00fcndet werden. Ich pr\u00fcfe BIOS-\/UEFI-Optionen:<\/p>\n<ul>\n  <li><strong>C-States<\/strong>: Zu tiefe Schlafzust\u00e4nde erh\u00f6hen die Aufwachlatenz. Auf Latenzsystemen begrenze ich tiefe C-States oder aktiviere <em>Latency Tolerance<\/em>-Optionen, wenn verf\u00fcgbar.<\/li>\n  <li><strong>Turbo\/Boost<\/strong>: Muss erlaubt sein, sonst verpufft jede Governor-Optimierung.<\/li>\n  <li><strong>Power Limits<\/strong>: PL1\/PL2 (Intel) bzw. PPT\/TDC\/EDC (AMD) realistisch setzen, damit kurze Bursts nicht sofort am Limit anstehen.<\/li>\n  <li><strong>SMT\/Hyper-Threading<\/strong>: Bringt Durchsatz, kann aber Latenz-Pfade teilen. F\u00fcr streng deterministische Services trenne ich kritische Threads auf echte Kerne.<\/li>\n<\/ul>\n<p>Ich beobachte die Wechselwirkung mit EPP\/Energy-Policy: Auch bei \u201cperformance\u201d kann eine zu konservative EPP die Aggressivit\u00e4t mindern. Der Sweet Spot ist h\u00e4ufig \u201cbalance_performance\u201d bei aktivem Turbo und begrenzten Tiefschlafzust\u00e4nden.<\/p>\n\n<h2>Leistung und Effizienz ausbalancieren<\/h2>\n\n<p>Ich betrachte Leistung und Energie gemeinsam, statt sie gegeneinander auszuspielen, und passe die <strong>Strategie<\/strong> an das Lastprofil an. Steht Reaktionszeit an erster Stelle, w\u00e4hle ich performance und gleiche den Verbrauch \u00fcber Nachtjobs oder Caching aus. Liegt der Fokus st\u00e4rker auf \u00d6konomie, dokumentiere ich das Delta und pr\u00fcfe, wie ich den <a href=\"https:\/\/webhosting.de\/server-cpu-frequency-scaling-stromverbrauch-effizient-greenpower\/\">Stromverbrauch effizient<\/a> senke, ohne Antwortzeiten zu verschlechtern. Zu aggressive Sparmodi verursachen h\u00e4ufig schwankende Zeitleisten, was Nutzer sp\u00fcren und Ums\u00e4tze kosten kann. Eine saubere, datenbasierte Abw\u00e4gung bringt die bessere Gesamtwirkung.<\/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\/cpu-governor-server-5392.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Rollout, Persistenz und R\u00fcckfallplan<\/h2>\n<p>Ich rolle \u00c4nderungen stufenweise aus: erst Einzelserver mit Telemetrie, dann eine kleine Gruppe, erst danach breit. So erkenne ich fr\u00fch Seiteneffekte. Neben systemd sorge ich f\u00fcr schnelle R\u00fccknahme, falls Jitter oder Hitzeprobleme auftreten.<\/p>\n<ul>\n  <li><strong>Staged Rollout<\/strong>: Canary-Hosts markieren und eng \u00fcberwachen (Latenz, Fehlerquote, CPU-Temperatur, Turbo-Anteil).<\/li>\n  <li><strong>Konfigurationsmanagement<\/strong>: Einheitliche Templates f\u00fcr Governor, Min-\/Max-Frequenz, EPP und ggf. C-States; \u00c4nderungen versionieren.<\/li>\n  <li><strong>Rollback<\/strong>: Ein Kommando oder Playbook, das den vorherigen Zustand sofort wiederherstellt.<\/li>\n<\/ul>\n\n<h2>Persistente Konfiguration mit systemd<\/h2>\n\n<p>Nach dem Test stabilisiere ich die <strong>Einstellung<\/strong> f\u00fcr Neustarts, sonst f\u00e4llt das System zur\u00fcck auf Standard. Das erledige ich etwa \u00fcber eine systemd-Unit, die beim Boot <code>cpupower frequency-set -g performance<\/code> setzt, oder \u00fcber geeignete Kernel-\/UEFI-Optionen. Zus\u00e4tzlich dokumentiere ich das Vorgehen im Konfigurationsmanagement, damit \u00c4nderungen nachvollziehbar bleiben. Je nach Distribution existieren eigene Profile, die ich pr\u00fcfe und bei Bedarf anpasse. So bleibt das Taktprofil konsistent und \u00dcberraschungen nach Reboots bleiben aus.<\/p>\n<pre><code>[Unit]\nDescription=CPU Governor setzen\nAfter=network.target\n\n[Service]\nType=oneshot\nExecStart=\/usr\/bin\/cpupower frequency-set -g performance\nExecStart=\/usr\/bin\/sh -c 'echo balance_performance &gt; \/sys\/devices\/system\/cpu\/cpu0\/cpufreq\/energy_performance_preference || true'\nRemainAfterExit=yes\n\n[Install]\nWantedBy=multi-user.target\n<\/code><\/pre>\n<p>Die EPP-Zeile greift nur, wenn die Plattform sie unterst\u00fctzt. Ich halte die Unit bewusst idempotent und logge \u00c4nderungen, damit Audits sp\u00e4ter klar nachvollziehbar sind.<\/p>\n\n<h2>Kurz zusammengefasst<\/h2>\n\n<p>Ich steuere die <strong>CPU<\/strong>-Frequenz aktiv, weil geringe Latenz und vorhersehbares Verhalten im Hosting entscheidend sind. Performance liefert die schnellste Antwort und zahlt sich bei Web, Shop und APIs aus, w\u00e4hrend sparsame Modi bei selten genutzten Systemen taugen. Die Wahl des Governors trifft erst mit Messdaten ins Schwarze, daher teste ich vor und nach jeder \u00c4nderung. Persistente Setups \u00fcber systemd sichern die Wirkung und verhindern R\u00fcckf\u00e4lle. So wird der CPU Governor zu einer kleinen, aber wirkungsvollen Schraube f\u00fcr <strong>konstante<\/strong> Performance im Tagesbetrieb.<\/p>","protected":false},"excerpt":{"rendered":"<p>CPU-governor op hostingservers: performance, powersave en serveroptimalisatie eenvoudig uitgelegd.<\/p>","protected":false},"author":1,"featured_media":20779,"comment_status":"","ping_status":"","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"inline_featured_image":false,"footnotes":""},"categories":[676],"tags":[],"class_list":["post-20786","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":"145","_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":"CPU Governor","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":"20779","footnotes":null,"_links":{"self":[{"href":"https:\/\/webhosting.de\/nl\/wp-json\/wp\/v2\/posts\/20786","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/webhosting.de\/nl\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/webhosting.de\/nl\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/webhosting.de\/nl\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/webhosting.de\/nl\/wp-json\/wp\/v2\/comments?post=20786"}],"version-history":[{"count":0,"href":"https:\/\/webhosting.de\/nl\/wp-json\/wp\/v2\/posts\/20786\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/webhosting.de\/nl\/wp-json\/wp\/v2\/media\/20779"}],"wp:attachment":[{"href":"https:\/\/webhosting.de\/nl\/wp-json\/wp\/v2\/media?parent=20786"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/webhosting.de\/nl\/wp-json\/wp\/v2\/categories?post=20786"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/webhosting.de\/nl\/wp-json\/wp\/v2\/tags?post=20786"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}