CPU-governor op hostingservers: prestaties op de juiste manier regelen

Wie wil dat hosting-servers snel en betrouwbaar reageren, kiest voor de CPU-regelaar bewust en controleert het klokgedrag onder reële belasting. Ik geef prioriteit aan duidelijke prestaties, controleer de latenties en pas de Frequentieschaling zo dat het web, de database en PHP zonder vertraging reageren.

Centrale punten

Voordat ik concrete instellingen ga aanpassen, vat ik de belangrijkste instellingen kort samen en rangschik ik ze op basis van hun nut in de dagelijkse hostingpraktijk. Zo ontstaat een duidelijk beeld van hoe ik kloksnelheid, latentie en efficiëntie op elkaar afstem. Deze punten helpen me snel beslissingen te nemen voor productieve servers. Daarbij beoordeel ik zowel harde feiten als het gedrag bij echte piekbelastingen. Dit zorgt voor consequent Procesoptimalisatie en kostenbesparing op de lange termijn Tijd.

• prestatie: Hoogste kloksnelheid, zeer lage latentie bij piekbelastingen.
• powersave: Lage kloksnelheid, lager stroomverbruik bij sporadische belasting.
• ondemand/schedutil: Dynamisch, schaalt mee met de belasting.
• Meting: Voor-en-na-vergelijking voor echte zeggingskracht.
• Volharding: Zorg ervoor dat de instellingen via systemd of opstartopties worden vastgelegd.

Ik gebruik deze lijst als uitgangspunt en neem vervolgens per workload een gerichte beslissing. Zo verhoog ik de Reactiesnelheid en vermijd wisselvallig Taktgedrag.

Wat een CPU-governor op hostingservers regelt

Een governor bepaalt hoe het systeem de CPU-kloksnelheid afhankelijk is van de belasting en hoe snel de kernen naar een hoger klokfrequentie gaan. Ik richt me daarbij op de tijd tot de eerste klokfrequentieverhoging, omdat die direct de Latency bij webverzoeken. Bij veel korte verzoeken leveren snelle kloksnelheidswijzigingen concrete voordelen op, terwijl zuinige strategieën eerder geschikt zijn voor periodes van inactiviteit. Linux regelt dit via de CPU-frequentieschaling, die afhankelijk van de governor agressief of voorzichtig reageert. Uiteindelijk is het doorslaggevend dat de server onder reële belasting consistent snel opstart.

Verschillen tussen stuurprogramma's en platforms: intel_pstate, amd_pstate, acpi_cpufreq

De keuze en werking van een governor hangen sterk af van de actieve driver. Moderne Intel-servers maken vaak gebruik van intel_pstate (HWP), huidige AMD-generaties amd_status; klassiek blijft acpi_cpufreq.

• intel_pstate: Biedt meestal alleen prestatie en powersave. De fijnafstemming gebeurt via de Voorkeur voor energieprestaties (EPP). Waarden zoals prestatie, balans_prestaties, balance_power en kracht invloed uitoefenen op de mate waarin er agressief wordt geboost.
• amd_status: Vergelijkbare logica met EPP/Energy-Policy, afhankelijk van de kernelversie als begeleid of actief Modus. Reageert in de praktijk zeer vlot op piekbelastingen.
• acpi_cpufreq: Klassiek model met een ruime keuze aan governors (bijv. ondemand, conservatief, schedutil). Hier heeft de Governor een bijzonder direct effect op de schaal.

Daarom controleer ik eerst welk stuurprogramma is geladen (cpupower frequentie-informatie), en pas de verwachting aan het platform aan. Wanneer EPP van toepassing is, stel ik bij de prestatiedoelstelling bovendien een “balance_performance”-voorkeur in als ik een minimaal verbruik wil bij vrijwel identieke latentie.

Welke modi er zijn en wanneer ze geschikt zijn

De gangbare modi heten prestatie, powersave, ondemand, conservative en schedutil; Ubuntu, Red Hat en de kernel-documentatie beschrijven deze varianten al jaren. Volgens de Ubuntu Server Docs houdt performance de hoogste kloksnelheid aan en is deze modus duidelijk gericht op snelheid, terwijl Red Hat powersave classificeert als de modus met maximale energiebesparing en minimale prestaties. Ik gebruik ‘performance’ voor webservers, drukbezochte WordPress-instanties en API-diensten die snelle responstijden vereisen. Bij zelden gebruikte machines met een hoge inactiviteit is ‘powersave’ een optie wanneer energievoorziening prioriteit heeft. Dynamische modi zoals ‘schedutil’ bieden een middenweg, maar reageren, afhankelijk van de kernel en hardware, in verschillende mate snel.

Turbo, min./max.-frequenties en boostlimieten

Naast de governor zijn turbomechanismen en frequentielimieten belangrijke instelparameters. Ik stel bewust onder- en bovengrenzen vast, zodat de kernen onder belasting onmiddellijk opschakelen en niet in te lage P-states blijven hangen.

• Min./max.-frequenties: De ondergrens verhogen, zodat short-bursts niet bij een koude start optreden; de bovengrens controleren om beperking uit te sluiten.
• Turbo/Boost: Schakel deze functie doorgaans in voor een lage latentie; houd daarbij de thermische en elektrische limieten in de gaten (PL1/PL2/EDP bij Intel, PPT/TDC/EDC bij AMD).

Typische commando's voor tests (dit kan per distributie verschillen):

#: het huidige bereik en de driver weergeven
cpupower frequency-info

# Governor instellen op Performance
cpupower frequency-set -g performance

# Min./max. frequentie (voorbeeldwaarden) instellen
cpupower frequency-set -d 3,0 GHz
cpupower frequency-set -u 4,8 GHz

# Intel Turbo (intel_pstate) tijdelijk uitschakelen/inschakelen
echo 1 > /sys/devices/system/cpu/intel_pstate/no_turbo    # 1 = uit, 0 = aan

# AMD Boost (afhankelijk van kernel/platform)
echo 1 > /sys/devices/system/cpu/cpufreq/boost

Ik pas deze parameters alleen bij wijze van test aan en meet direct daarna of de latentie en stabiliteit daadwerkelijk verbeteren.

Praktische handleiding: de governor controleren en omschakelen

Ik begin elke optimalisatie met een blik op de momenteel ingestelde Gouverneur. Dat lukt via cat /sys/devices/system/cpu/cpu*/cpufreq/scaling_governor of met cpupower frequentie-informatie, dat bovendien frequentiebanden en drivers weergeeft. Voor productieve webservers schakel ik vaak over naar cpupower frequency-set -g performance naar de high-performance-modus. Vervolgens controleer ik het resultaat nogmaals om verkeerde configuraties uit te sluiten. Zonder deze controle loop ik het risico op inconsistenties Reactietijden, die te voorkomen zijn.

Geautomatiseerde rook- en regressietests

Na het omschakelen voer ik korte, reproduceerbare tests uit om uitschieters snel te herkennen. Ik combineer microbenchmarks (enkelvoudig eindpunt, warme/koude cache) met korte stresstests en meet p50/p95/p99 van de responstijden. Het is belangrijk dat de testgegevens en -routes realistisch zijn (bijv. afrekenen in een webwinkel, zoeken, cache-miss bij het startpad). Ik herhaal de tests meerdere keren en neem gericht het gemiddelde om jitter van het netwerk en de opslag te filteren.

Meetbaar sneller: latentie, kloksnelheid en piekbelastingen

Voorafgaand aan de omschakeling leg ik de uitgangswaarden vast voor Latency, CPU-belasting, foutpercentage en energieverbruik, bijvoorbeeld met afzonderlijke benchmarks en echte toegangsprofielen. Daarna herhaal ik dezelfde tests met dezelfde dataset, zodat ik veranderingen nauwkeurig kan vergelijken. Ik besteed bijzondere aandacht aan Spikes bij korte, hoge mate van parallelliteit, zoals bij het afrekenen in een webwinkel of bij cache-misses. Als er daarbij vertraging optreedt, controleer ik de omgeving, bijvoorbeeld op mogelijke CPU smoren in gescheiden omgevingen. Pas als uit de meting duidelijk blijkt dat het nut ervan is aangetoond, neem ik de configuratie definitief over.

Hulpmiddelen en statistieken: hoe ik effecten zichtbaar maak

• turbostat: Geeft per pakket/kern de kloksnelheid, C-states, turbo-percentage en energie weer. Ideaal om de reactietijd van de boost en de residency te controleren.
• perfect stat: Meet instructies per cyclus (IPC), contextwisselingen en branch-misses – handig om CPU-bottlenecks in kaart te brengen.
• pidstat/iostat/vmstat: Biedt aanvullend inzicht in processen, I/O-wachttijden en systeembelasting.
• PSI (informatie over drukval): Beoordeelt of CPU-/IO-/geheugendruk latentie veroorzaakt – nuttig naast de puur op de kloksnelheid gebaseerde analyse.
• Servergegevens: p50/p95/p99-latentie per eindpunt, foutpercentage, snelheid, verzadiging. Zonder deze parameters blijven aanpassingen aan de governor louter anekdotisch.

Ik breng klokcurves in verband met latenties op dezelfde tijdas. Als de klok pas na 20–50 ms omhoog springt, is dat meestal te zien in de p95. Het doel is dat de eerste relevante worker-thread al in de hoge P-state start.

Vergelijkingstabel: Governors in hostingtoepassingen

In het volgende overzicht worden de gangbare modi ingedeeld op basis van hun ritme en geschiktheid voor hosting. Ik gebruik het als een snel Beslissingsondersteuning, maar vervang daarmee geen eigen tests in reële Belasting.

Gouverneur	Taktgedrag	Geschiktheid voor hosting	Voordeel	Nadeel
prestatie	Maximaal, statisch hoog	Web, webshop, API, database	Zeer lage latentie	Hoger verbruik
powersave	Minimaal, aarzelend stijgend	Zeldzame taak, Dev/Test	Minder energie	Verminderde prestaties
ondemand	Dynamisch, belastingsgestuurd	Gemengde werklasten	Goed compromis	De reactietijd varieert
schedutil	Op een planner gebaseerd	Actuele kernels	Fijnregeling	Afhankelijk van de hardware
conservatief	Langzaam stijgend	Langlaufers, Batch	Geleidelijke schaalvergroting	Trage bij spikes

Deze indeling is gebaseerd op ervaringen met productieve omgevingen en komt overeen met beschrijvingen in kernel- en distributiedocumenten. Concrete hardware kan het gedrag beïnvloeden, daarom test ik het altijd ter plaatse bij normaal gebruik.

Soorten workloads: web, webshop, database, API

Bij WordPress, WooCommerce en headless API’s telt elke Milliseconde tot het eerste antwoord; daarom presteert een hoge kloksnelheid meestal beter. Databases hebben er baat bij als single-thread-fasen snel worden afgehandeld; de Kloksnelheid belangrijker dan kernen komt vaak duidelijker naar voren dan het aantal processen alleen. Voor batch- of rapportagetaken kan een dynamische governor volstaan, zolang er geen gebruikers hoeven te wachten. Kritisch zijn gemengde workloads met veel korte pieken, zoals Cron, PHP-FPM en cache-misses tegelijkertijd. In dergelijke scenario’s zorgt een consequente prestatiemodus voor de meest constante responstijd.

Details per workload: PHP-FPM, NGINX, databaseserver

• PHP-FPM: Veel korte, CPU-gebonden bursts. Ik zorg ervoor dat pm.max_kinderen en het aantal processen moet overeenkomen met het aantal kernen, en de eerste workers mogen niet in de Low-P-status starten. Reuseport in NGINX helpt de belasting gelijkmatig over de kernen te verdelen.
• NGINX/Apache: Accept-threads moeten worden toegewezen aan cores met een lage belasting; IRQ-balancing en affinity voorkomen opstoppingen op afzonderlijke cores. Een hoge basiskloksnelheid verkort TLS-handshakes en de verwerking van headers.
• Databases: Korte single-thread-fasen (parse/plan/index-hits) profiteren sterk van de boost. Langere, parallelle scans zijn sterker afhankelijk van I/O en geheugen; hier is consistentie belangrijker dan maximale frequentie.

Ik test zowel warme als koude paden: het opwarmen van de cache mag niet tot een “slakkenpas” verworden, alleen maar omdat de CPU in een energiebesparende modus blijft.

NUMA, IRQ's en thread-affiniteit

Naast de governor bepalen de topologie en de verdeling van de interrupts de latentie. Ik streef naar korte paden: web- en PHP-processen moeten gebruikmaken van het geheugen en de IRQ’s van hetzelfde NUMA-knooppunt waarin ze worden uitgevoerd. Ik controleer de IRQ-balancing regelmatig, met name na kernel-updates.

• cpuset/affinity: Kritieke diensten vastzetten op kerngroepen die niet worden overschreven door de opslag- of netwerk-IRQ.
• Scheduler isolatie: Op systemen waar de latentie van cruciaal belang is, afzonderlijke kernen isoleren (isolcpus/rcu_nocbs) en daar hot-path-workers aan koppelen.
• TransparantieMet htop of ps -eo pid,psr,comm kan ik zien of threads over kernen “springen” en cache-lokaliteit verliezen.

Virtualisatie en provider-stack

Op VM’s en containers hangt het klokgedrag bovendien af van de instellingen van de hypervisor en de host, en daarom heb ik de Omgeving controleer ik altijd mee. Sommige providers leggen frequenties vast, andere staan flexibele boosts toe of geven voorrang aan bepaalde instanties. Als klokfrequentiewijzigingen in de gast nauwelijks effect hebben, verplaats ik de analyse naar de hostzijde of vraag ik specifiek naar limieten. Bij dedicated servers heb ik meer controle, maar moet ik de BIOS/UEFI- en kernel-drivers zorgvuldig configureren. Duidelijke transparantie over deze keten voorkomt verkeerde interpretaties bij de Meting.

Containers, Cgroups v2 en Kubernetes

In containers bepaalt Cgroups v2 in belangrijke mate hoe de CPU schaalt. Ik let op:

• CPU.max/Quota: Te krappe bandbreedtequota leiden tot throttling en jitter – herkenbaar aan verhoogde p99-waarden en nr_throttled-teller.
• CPU-aandelen: Bepaalt de relatieve prioriteit. Kritieke diensten krijgen een hoger aandeel, zodat ze bij congestie voorrang krijgen.
• cpuset: Om een stabiele latentie te garanderen, koppel ik containers aan aaneengesloten kernen van hetzelfde NUMA-knooppunt.
• Interactie met de planner: schedutil kan in combinatie met sterk fluctuerende containerbelasting een vertragend effect hebben; op hostniveau zorgt “performance” voor stabiliteit van de onderliggende structuur.

Ik test altijd eerst op de host wat het effect van de governor is. Als de container toch nog schommelt, ligt de oorzaak vaak bij quota’s of oversubscription, en niet bij de governor.

BIOS/UEFI, C-states en energievoorkeuren

De basisinstellingen bepalen hoe snel boosts worden geactiveerd. Ik controleer de BIOS-/UEFI-opties:

• C-staten: Te diepe slaaptoestanden verlengen de opwaaklatentie. Op latentiesystemen beperk ik diepe C-toestanden of activeer ik Latentietolerantie-opties, indien beschikbaar.
• Turbo/Boost: Dat moet wel kunnen, anders gaat elke optimalisatie van de Governor verloren.
• Vermogenslimieten: Stel PL1/PL2 (Intel) of PPT/TDC/EDC (AMD) op een realistische waarde in, zodat korte bursts niet meteen tegen de limiet aanlopen.
• SMT/Hyper-Threading: Zorgt voor een hogere doorvoercapaciteit, maar kan latentie-paden delen. Voor strikt deterministische diensten verdeel ik kritieke threads over fysieke kernen.

Ik houd de wisselwerking met EPP/Energy-Policy in de gaten: ook bij “performance” kan een te conservatieve EPP de agressiviteit verminderen. De ideale balans ligt vaak bij “balance_performance” met een actieve turbo en beperkte diepe slaapstanden.

Een evenwicht vinden tussen prestaties en efficiëntie

Ik beschouw vermogen en energie als een geheel, in plaats van ze tegen elkaar uit te spelen, en pas de Strategie aan het belastingprofiel aanpassen. Als reactietijd voorop staat, kies ik voor ‘performance’ en compenseer ik het verbruik via nachtelijke taken of caching. Als de nadruk meer op zuinigheid ligt, noteer ik het verschil en bekijk ik hoe ik de Efficiënt stroomverbruik verlagen, zonder dat dit ten koste gaat van de responstijden. Te agressieve energiebesparingsmodi leiden vaak tot schommelende tijdlijnen, wat gebruikers merken en omzet kan kosten. Een zorgvuldige, op gegevens gebaseerde afweging levert het beste totale resultaat op.

Uitrol, duurzaamheid en noodplan

Ik voer wijzigingen stapsgewijs door: eerst op afzonderlijke servers met telemetrie, daarna op een kleine groep, en pas daarna op grotere schaal. Zo kan ik neveneffecten in een vroeg stadium opsporen. Naast systemd zorg ik ervoor dat ik de wijzigingen snel ongedaan kan maken als er jitter of oververhittingsproblemen optreden.

• Gefaseerde invoering: Canary-hosts markeren en nauwlettend in de gaten houden (latentie, foutpercentage, CPU-temperatuur, turbo-aandeel).
• Configuratiebeheer: Standaardsjablonen voor Governor, min./max.-frequentie, EPP en eventueel C-states; wijzigingen van een versienummer voorzien.
• Terugdraaien: Een commando of playbook waarmee de vorige toestand onmiddellijk wordt hersteld.

Permanente configuratie met systemd

Na de test stabiliseer ik de Instelling voor herstarts, anders valt het systeem terug op de standaardinstellingen. Dat regel ik bijvoorbeeld via een systemd-unit die bij het opstarten cpupower frequency-set -g performance of via geschikte kernel-/UEFI-opties. Daarnaast documenteer ik de werkwijze in het configuratiebeheer, zodat wijzigingen traceerbaar blijven. Afhankelijk van de distributie zijn er specifieke profielen, die ik controleer en indien nodig aanpas. Zo blijft het klokprofiel consistent en worden verrassingen na het opnieuw opstarten voorkomen.

[Unit]
Description=CPU-regelaar instellen
After=network.target

[Service]
Type=oneshot
ExecStart=/usr/bin/cpupower frequency-set -g performance
ExecStart=/usr/bin/sh -c 'echo balance_performance > /sys/devices/system/cpu/cpu0/cpufreq/energy_performance_preference || true'
RemainAfterExit=yes

[Install]
WantedBy=multi-user.target

De EPP-regel werkt alleen als het platform deze ondersteunt. Ik houd de unit bewust idempotent en log wijzigingen, zodat audits later duidelijk traceerbaar zijn.

Kort samengevat

Ik regel de CPU-Frequentie actief, omdat een lage latentie en voorspelbaar gedrag cruciaal zijn bij hosting. De ‘Performance’-modus levert de snelste respons en loont de moeite bij websites, webwinkels en API’s, terwijl zuinige modi geschikt zijn voor systemen die zelden worden gebruikt. De keuze van de governor is pas echt raak als er meetgegevens beschikbaar zijn; daarom test ik voor en na elke wijziging. Permanente instellingen via systemd waarborgen het effect en voorkomen terugval. Zo wordt de CPU-governor een kleine, maar effectieve schroef voor constant Prestaties tijdens het dagelijks gebruik.