Optimisation énergétique dans le centre de données : governors de fréquence CPU, C-States et leurs impacts sur la latence

L‘optimisation énergétique dans le centre de données n’est plus une question purement liée aux coûts. Elle influe sur la stabilité thermique, la longévité du matériel, la densité par rack et, last but not least, la prévisibilité des performances. En pratique, c’est souvent une combinaison discrète de régulation de la fréquence CPU (CPU-Freq-Governors) et d’états de veille CPU (C-States, c.-à-d. idle states) qui détermine si les systèmes fonctionnent « rassasiés » et de manière prévisible ou si des pics de latence surviennent soudainement et sont difficiles à reproduire.

Cet article situe clairement les mécanismes et les traduit en décisions d’exploitation : que peut-on économiser sans risque ? Où le risque de jitter (variations des temps de réponse) augmente-t-il ? Et comment procéder en particulier dans des environnements Kubernetes, où de nombreuses charges partagent les hôtes mais où des applications individuelles conservent des exigences strictes en matière de latence ?

Optimisation énergétique dans le centre de données en pratique

Sur les CPU serveurs modernes, il existe deux leviers principaux :

• Mise à l’échelle fréquence/tension via les P-States (Performance-States) : le CPU cadence plus haut ou plus bas, souvent lié à la tension d’alimentation. Un CPU-Freq-Governor est la politique qui décide de la agressivité des montées/baisses de fréquence.
• États de veille (idle) via les C-States : lorsqu’un cœur n’a rien à faire, il peut basculer dans des états de veille de plus en plus profonds. Plus le C-State est profond, plus il économise d’énergie, mais plus le réveil (exit latency) prend typiquement du temps.

Le malentendu en exploitation : « plus d’économie = toujours plus lent ». En réalité, la situation est plus nuancée. Beaucoup de workloads ne sont en moyenne pas limités par le CPU, et bénéficient d’une efficacité élevée tant que les latences de queue (p. ex. 99e centile) restent sous contrôle. La situation devient critique surtout lorsque la charge est « bursty » (pics courts et fréquents), ou lorsque des threads/requests individuels doivent être servis très rapidement et que la transition depuis un C-State profond ou depuis une fréquence basse vers le « plein régime » coïncide précisément avec ce délai.

D’autres amplificateurs typiques en centre de données : NUMA (Non-Uniform Memory Access, c.-à-d. des temps d’accès mémoire différents selon le socket CPU), Shared Interrupts, Hyper-Threading/SMT (deux threads partageant les ressources d’un cœur) et virtualisation/containerisation avec une allocation CPU variable.

CPU-Freq-Governors, P-States et pilotes : ce que les administrateurs doivent vraiment savoir

Sous Linux le sous-système de fréquence CPU s’est développé de façon historique. Ce qui compte, c’est quel pilote est actif, car le pilote définit les possibilités réelles de réglage et l’observabilité. Variantes fréquentes :

• intel_pstate : pilote spécifique Intel, souvent activé par défaut. Il exploite le DVFS intégré au matériel/CPU (Dynamic Voltage and Frequency Scaling) et propose des politiques telles que « performance »/« powersave ». Les dénominations peuvent être trompeuses : « powersave » signifie souvent ici « géré par le matériel, efficace » et n’est pas nécessairement synonyme de « lent ».
• amd_pstate : équivalent AMD sur les plateformes récentes, dont la qualité varie selon la maturité du kernel/du BIOS.
• acpi-cpufreq : pilote générique basé sur ACPI, offrant des gouverneurs classiques comme « ondemand », « conservative » etc.

La politique du governor décide de la rapidité de réaction à la charge. Dans de nombreux déploiements en centre de données, les temps de réaction (ramp-up) sont plus importants que la fréquence maximale. Autrement dit : une policy qui monte rapidement en fréquence peut stabiliser les latences de queue sans maintenir en permanence le processeur au régime maximal.

État des lieux rapide sur les hôtes Linux

Pour obtenir une baseline fiable, commencez par relever les pilotes, les governors et les limites de fréquence. Utilisez pour cela cpupower (nom du paquet selon la distribution) :

# Überblick: Treiber, Governor, aktuelle Frequenz, Grenzen
cpupower frequency-info

# Kurzstatus pro CPU (je nach Distribution verfügbar)
cpupower frequency-info -p

Un examen de sysfs vaut également la peine (pour automatisation/CMDB) :

# Treiber und Governor pro CPU (CPU0 als Beispiel)
cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_driver
cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor

# Grenzen (kHz)
cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_min_freq
cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_max_freq

Piège fréquent : BIOS-Settings peuvent outrepasser ou limiter Linux (par ex. „Energy Efficient Turbo“, „C-State Control“, „Package C-State Limit“, „Power Regulator“). Si vous intervenez au niveau de l’OS alors que le BIOS/contrôleur de management impose des limites strictes, vous verrez des politiques apparemment « correctes », mais sans effet.

Comprendre les C-States : Core vs. Package et la latence de sortie

Les C-States sont des états d’inactivité. Un cœur peut passer de C1 (très peu profond) à des états plus profonds. Il existe en outre des Package C-States, où l’ensemble du socket CPU (le « package ») entre en repos plus profond lorsque suffisamment de cœurs sont inactifs. Ce sont précisément ces états de package qui sont souvent à l’origine de pics de latence difficiles à expliquer, car le réveil implique davantage de composants (uncore, hiérarchie de caches, interconnect).

La question opérationnelle pertinente n’est pas « Quels C-States sont activés ? », mais : à quelle fréquence et pendant combien de temps la CPU réside dans quels C-States, et les latences de sortie se corrèlent‑elles avec vos SLOs (Service Level Objectives) ?

Mesurer la résidence en C-State

Sur Linux, turbostat (des linux-tools) fournit des indications très utiles. Il affiche notamment le pourcentage de résidence dans les C-States ainsi que le comportement fréquence/turbo. Exemple :

# 10 Messzyklen à 1 Sekunde, kompakt
turbostat --quiet --Summary --interval 1 --num_iterations 10

Si vous observez, lors de périodes où surviennent des pics de latence, une forte résidence dans des Package-States profonds, c’est un fort indice. Inversement : si la CPU atteint rarement un état plus profond que C1/C2 (par ex. en raison d’une charge en arrière‑plan, d’interruptions, d’agents de monitoring), un réglage agressif des C‑States apporte souvent peu — et la cause se trouve ailleurs (scheduler, tempêtes d’IRQ, storage, réseau).

Symptômes de latence typiques liés aux governors/C-States

Toute latence n’est pas « Power ». Toutefois, les motifs suivants correspondent souvent à des problèmes de fréquence et d’idle :

• Pics dans la plage des millisecondes sur une latence moyenne par ailleurs stable, souvent lors de requêtes en rafale (API-Gateways, Ingress, Auth, chemins de cache-miss).
• Clusters réguliers de jitter à l’intervalle d’une seconde, corrélés aux cycles Idle/Wakeup.
• Seuls certains nœuds sont concernés (profil BIOS différent, version microcode/noyau différente, limites d’alimentation différentes).
• Le problème disparaît en charge continue (car le CPU n’est plus profondément idle) et survient pendant des phases de faible activité.

Important : ces symptômes peuvent aussi provenir de l’équilibrage des IRQ, d’accès NUMA distants, de quotas CPU de cgroup, de CPU steal (en virtualisation) ou de pauses du garbage collector. C’est pourquoi une stratégie de mesure et d’exclusion est centrale.

Flux de travail pratique : de l’hypothèse à une décision fondée

Un processus viable en salle blanche nécessite reproductibilité, télémétrie et rollback. Un déroulé éprouvé :

1. Classer la charge de travail : sensible à la latence (p. ex. services proches du temps réel), orientée débit (batch), mixte (APIs avec pics).
2. Définir SLOs et points de mesure : latence p95/p99, longueurs de file d’attente, budget d’erreurs, en complément énergie/température (si disponible).
3. Mesurer la ligne de base : turbostat, cpupower, charge système, taux d’IRQ, runqueue du scheduler, métriques Kubernetes.
4. Modifier de façon minimalement invasive et seulement sur des nœuds sélectionnés (canary) : p. ex. changer le governor ou limiter les C-States.
5. Comparer à la ligne de base : mêmes profils de charge, mêmes fenêtres temporelles, même méthodologie de mesure.
6. Préparer le rollback : restaurer paramètres OS/boot, documenter le profil BIOS, adapter les playbooks d’automatisation.

Umsetzung auf Linux: Governor setzen, Grenzen definieren, Persistenz herstellen

Pour de nombreux workloads serveurs, un point de départ pragmatique : governor „performance“ sur les nœuds critiques pour la latence, et un mode de politique matérielle efficace (selon le pilote) sur les nœuds généraux. L’important est la différenciation des nœuds, pas un dogme global.

Governor temporär setzen (Test)

# Performance-Policy für alle CPUs (temporär bis Reboot/Policy-Reset)
cpupower frequency-set -g performance

# Alternativ: powersave (bei intel_pstate oft "hardware-managed")
cpupower frequency-set -g powersave

Si cpupower échoue, c’est souvent dû à des droits manquants (sudo), des modules/outils absents ou au fait que le pilote n’expose pas de governors classiques (p. ex. selon le mode intel_pstate). Vérifiez alors ce que cpupower frequency-info signale comme « available governors ».

Persistente Konfiguration mit tuned (RHEL-/CentOS-/Rocky-/Alma-Familie)

tuned est un démon qui applique des profils Power/Performance. Pour l’exploitation, c’est souvent plus stable que des scripts individuels, car il prend en compte les ordres de démarrage et de service.

# Status und aktives Profil
tuned-adm active

# Beispiel: auf Performance schalten (Host-weit)
tuned-adm profile performance

Piège : tuned peut aussi modifier l’équilibrage des IRQ, les paramètres de disque ou les paramètres réseau. Pour un réglage ciblé du CPU, il est préférable d’utiliser un profil personnalisé qui ne modifie que les leviers nécessaires, plutôt que d’adopter aveuglément un grand profil standard.

Limiter les C-States : pertinent, risqué, parfois nécessaire

Limiter les C-States est un levier grossier mais efficace lorsque les latences d’activation dominent la tail-latency. Techniquement, cela se fait souvent via des paramètres de démarrage du noyau ou des limites BIOS. Cela réduit le potentiel d’économie, mais peut stabiliser la latence.

Paramètres de démarrage du noyau (exemples) et possibilité de retour arrière

Quels paramètres sont pertinents dépend de la plateforme et du noyau. Les leviers souvent utilisés sont :

• intel_idle.max_cstate: limite les C-States maximums dans le pilote intel_idle.
• processor.max_cstate: paramètre générique de limitation (agit différemment selon le pilote).
• idle=poll: empêche les états d’inactivité profonds (très énergivore, plutôt utilisé pour le diagnostic).

Appliquez d’abord ces paramètres sur un Canary-Node et documentez l’état exact avant/après. Exemple pour GRUB (les distributions diffèrent ; vérifiez vos standards) :

# 1) Aktuelle Kernel-Cmdline prüfen
cat /proc/cmdline

# 2) GRUB Default anpassen (Beispiel)
sudo sed -i 's/GRUB_CMDLINE_Linux="/GRUB_CMDLINE_Linux="intel_idle.max_cstate=1 processor.max_cstate=1 /' /etc/default/grub

# 3) GRUB-Konfig regenerieren (Pfad je nach Distribution)
sudo grub2-mkconfig -o /boot/grub2/grub.cfg

# 4) Reboot planen und nach dem Boot wieder prüfen
sudo reboot

Le retour arrière est identique : supprimer les paramètres, régénérer GRUB, redémarrer. Prévoyez des fenêtres de maintenance, car il s’agit d’un changement de démarrage.

Important pour la décision : si vous limitez les C-States, surveillez également la température, les courbes de ventilation et les limites de puissance. Dans des environnements denses, cela peut provoquer des effets secondaires (thermal throttling) qui, au final, coûtent à nouveau en performance — mais autrement.

Spécifique à Kubernetes : réglage des nœuds sans effets secondaires

Dans Kubernetes, la tâche devient plus exigeante car les charges de travail sont distribuées dynamiquement. L’optimisation énergétique et la stabilité des latences ne sont pas un exercice de « réglage fin sur l’hôte », mais une question de rôles de nœud, de scheduling et d‘isolation.

Principe de base : pools de nœuds distincts pour des SLO différents

Si vous mélangez des workloads sensibles à la latence (p. ex. Ingress, Service-Mesh-Data-Plane, Auth, Message-Broker Frontends) et du batch/CI/ETL sur les mêmes nœuds, toute politique d’alimentation devient un compromis. Mieux :

• Node-Pool „low-latency“: mécanismes d’économie d’énergie conservateurs (politique de performance plus élevée, C-States limités), isolation CPU plus stricte.
• Node-Pool „balanced“: politiques efficaces, mais avec surveillance de la tail-latency.
• Pool de nœuds « batch » : efficacité énergétique maximale, au prix d’une tolérance supérieure au jitter.

Vous implémentez cette séparation via Labels/Taints/Tolerations (Label = critère, Taint = « uniquement avec autorisation »). Cela empêche qu’un seul Deployment n’impose vos politiques CPU globales.

CPU Manager, cgroups et Pods « Guaranteed »

Le CPU Manager du Kubelet peut attribuer des cœurs exclusivement à des pods (politique « static »). Cela réduit le jitter du scheduler, car un pod ne migre pas constamment entre les CPUs. La condition typique est d’utiliser des Pods Guaranteed (Requests = Limits) pour la CPU. Les cgroups (Control Groups, contrôle des ressources au niveau du kernel) appliquent alors les limites ; avec cgroup v2 certains détails diffèrent, mais le principe reste.

Pour un premier contrôle : quelle version de cgroup utilisent vos nœuds ?

stat -fc %T /sys/fs/cgroup

Et pour savoir si le CPU Manager est actif (la configuration du Kubelet dépend du cluster). Sur beaucoup de systèmes, vous trouverez la configuration par exemple sous /var/lib/kubelet/config.yaml :

sudo grep -E "cpuManagerPolicy|cpuManagerReconcilePeriod" -n /var/lib/kubelet/config.yaml || true

Piège fréquent : la politique « static » du CPU Manager apporte peu si la fréquence CPU est agressivement réduite ou si des Package C-States profonds restent actifs. Des cœurs exclusifs réduisent la migration, mais pas la latence de réveil depuis un idle profond. Pour des nœuds à faible latence, ces sujets doivent être traités conjointement.

Affinité IRQ et « Noisy Neighbors »

Les interruptions (IRQs) sont des événements matériels qui consomment du temps CPU en dehors des processus normaux. Si de nombreuses IRQ liées au NIC ou au stockage tombent quand même sur un cœur « exclusif », l’isolation devient pratiquement inutile. Vérifiez donc la charge et la répartition des IRQ :

# IRQ-Statistik (Momentaufnahme)
cat /proc/interrupts | head -n 30

# Softirqs (Netzwerk/Block-Processing im Kernel)
cat /proc/softirqs | head -n 30

Dans Kubernetes, des causes fréquentes sont : Node-Local-DNS, CNI (Container Network Interface) et les plugins de stockage qui génèrent du trafic en arrière-plan traité sur des CPUs « incorrects ». Selon la plateforme, la configuration d’irqbalance, les CPU-sets et une séparation claire entre « System-Cores » et « Workload-Cores » (p. ex. via isolcpus/nohz_full comme options avancées) aident ici. Ces changements sont toutefois profonds et ne doivent être réalisés qu’avec un plan de test et de rollback rigoureux.

Checkliste: Vor dem Tuning prüfen (damit Sie nicht das Falsche optimieren)

• BIOS/UEFI : profils d’alimentation, limites C-State, Turbo, SMT, options de performance déterministes. Documentez l’état par modèle de nœud.
• Microcode und Kernel : des versions différentes modifient de manière mesurable le comportement d’alimentation et d’inactivité. Unifiez-les avant de comparer.
• Virtualisierung : sur des VM, le CPU-steal/la politique de l’hôte est souvent plus déterminant que le tuning côté invité. Ce texte traite principalement du bare metal ou de l’OS hôte.
• Monitoring : mesurez le p95/p99 et pas seulement la moyenne ; corrélez avec le temps de résidence en idle du CPU, la fréquence et les taux d’IRQ.
• Lastprofil : l’optimisation sous une charge synthétique continue peut manquer le comportement réel en rafales.

Troubleshooting: Wenn nach dem Tuning neue Probleme auftauchen

Symptom: Höhere Temperaturen, aber keine bessere Latenz

Souvent, la cause n’est pas la sortie de C-State, mais une mise en file ailleurs (réseau, stockage, contention de verrous) ou un throttling thermique. Vérifiez si le processeur sous charge fonctionne à la fréquence attendue et si des limites de puissance sont activées. Sur de nombreux serveurs, le BMC/Redfish ou les outils du fabricant fournissent les valeurs nécessaires ; au niveau du système d’exploitation, turbostat est un indicateur utile.

Symptôme : plus de débit, mais une latence en queue dégradée

Cela indique souvent des phases de boost/turbo trop agressives qui atteignent des limites thermiques, ou une concurrence accrue due aux tâches d’arrière-plan (p. ex. tout s’accélère mais il y a aussi plus de parallélisme). Dans Kubernetes : vérifiez la densité de pods par nœud, le throttling CPU (cgroup) et que les classes QoS sont correctement définies.

Symptôme : seuls certains Pods sont affectés

Dans ce cas, les politiques CPU ne sont généralement qu’un facteur. Causes fréquentes : quotas/throttling CPU (Limits), affinités CPU inappropriées, pauses GC (sur JVM/.NET), ou effets de « Noisy Neighbor » liés aux caches partagés/SMT. Pour les pods critiques en latence, définissez Requests/Limits de façon cohérente et, si nécessaire, basculez vers des nœuds dédiés.

Stratégie de retour en arrière : comment revenir en toute sécurité à l’état initial

Une stratégie de retour en arrière n’est pas une formalité, mais la différence entre une expérimentation contrôlée et une escalade nocturne. Prévoyez au minimum les niveaux suivants :

• Restauration de la politique OS : réinitialiser le governor (cpupower/tuned), recharger les services, état cible documenté dans la gestion de configuration.
• Restauration des paramètres de boot : annuler les modifications GRUB, conserver l’ancienne kernel-cmdline accessible, démarrer via le menu de boot en cas de doute.
• Restauration du pool de nœuds dans Kubernetes : retirer les canary-nodes du pool (cordon/drain), basculer les workloads vers un profil « balanced », puis poursuivre les modifications.

Pour les opérations Kubernetes (Canary/Drain) comme boîte à outils standard :

# Node für neue Pods sperren
kubectl cordon <node-name>

# Pods kontrolliert evakuieren (Achtung: PDBs und Stateful Workloads)
kubectl drain <node-name> --ignore-daemonsets --delete-emptydir-data

# Nach Rollback wieder freigeben
kubectl uncordon <node-name>

Piège : drain peut échouer à cause de PodDisruptionBudgets (PDB) ou de données locales (emptyDir). Ce n’est pas un « problème Kubernetes », mais une réalité opérationnelle — et c’est précisément pourquoi vous devez traiter le tuning puissance/latence comme un processus contrôlé sur un pool de nœuds.

Bonnes pratiques : concilier efficacité énergétique et latence stable

• Segmenter plutôt que modifier globalement : des politiques différentes par pool de nœuds sont presque toujours préférables à un compromis au niveau du cluster.
• Mesurez la residency, pas seulement les watts : les métriques de C-State et de fréquence expliquent souvent mieux les pics de latence que la seule consommation électrique.
• Unifiez d’abord pilotes/BIOS : sans base reproductible, les comparaisons sont sans valeur.
• Isolation IRQ et CPU pour la faible latence : cœurs dédiés, cœurs système, affinité IRQ — mais uniquement avec une gestion des changements rigoureuse.
• Retour en arrière sous forme de runbook : un tuning sans possibilité de retour n’est pas prêt pour la production.

Conclusion : l’optimisation énergétique est un design d’exploitation, pas un simple interrupteur

L’optimisation énergétique dans le centre de données est durable si vous considérez les CPU-Freq-Governors, les P-States et les C-States comme partie intégrante du design d’exploitation : rôles de nœud, ordonnancement Kubernetes, méthodologie de mesure et stratégie de repli font partie d’un même ensemble. Pour des charges de travail générales, la mise à l’échelle matérielle efficace est souvent non critique. En revanche, pour des services sensibles à la latence, vous devez délibérément appliquer des politiques plus conservatrices, limiter les états d’inactivité profonds et mettre en œuvre l’isolation (CPU/IRQ) de façon systématique — pas partout, mais là où cela protège réellement les SLOs.

Si vous souhaitez aborder ce sujet systématiquement dans votre environnement, planifiez ensuite un pool canari, définissez des critères de mesure (p95/p99 + Residency) et documentez les paramètres BIOS/Kernel par plateforme. Ainsi, ce qui est « ressenti comme plus rapide » devient une décision solide et sûre en exploitation.