Kurz gesagt:

• C-States bestimmen, wie tief die CPU im Leerlauf schläft.
• P-States bestimmen Takt und Spannung, während die CPU arbeitet.
  
  Lenovopress p-states-with-linux-on-intel-based-servers

apt update && apt install -y powertop linux-cpupower
cpupower frequency-info

Aktuelles Performance Profil anzeigen lassen:

So weit, so gut, aber ich werde das Gefühl nicht los, dass ich wieder veräppelt werde… beginnende Paranoia?

steuerung aller CPU´s anzeigen lassen:
grep . /sys/devices/system/cpu/cpu*/cpufreq/scaling_governor

Das passt auch. Warum bin ich so misstrauisch? Energischer nachfragen!

for f in /sys/devices/system/cpu/cpu*/power/energy_perf_bias; do echo -n "$(basename $(dirname $(dirname $f))): "; cat $f; done

Was bedeutet „6“, mal recherchieren „CPU_frequency_scaling“,… ha… erwischt

Dauerhafte Umstellung (nach Neustarts)

Da Proxmox (Debian) diese Werte beim Booten neu einliest, sollten Sie die Einstellung automatisieren. Am saubersten gelingt dies über eine udev-Regel. Dadurch wird der Wert automatisch auf 0 gesetzt, sobald das System die CPU-Kerne beim Booten initialisiert.

1. Erstellen Sie eine neue Regeldatei:bashnano /etc/udev/rules.d/99-cpu-performance.rules
2. Fügen Sie die folgende Zeile ein:textACTION=="add", SUBSYSTEM=="cpu", ATTR{power/energy_perf_bias}="0"
3. Speichern Sie die Datei

Hat es sich gelohnt?

Ob die Änderung wirklich etwas gebracht hat, muss am Ende jeder für sich selbst entscheiden. Mein Server verbraucht im Leerlauf jetzt rund 40 Watt mehr. Auf ein Jahr gerechnet sind das immerhin etwa 350 Kilowattstunden zusätzlich.

Ist es das wert?

In einem Homelab vermutlich eher nicht. Bei Arbeitslasten, die kurze Reaktionszeiten und eine gleichbleibend hohe Leistung benötigen, kann es dagegen sinnvoll sein. Entscheidend ist, ob sich die Verbesserung auch wirklich messen lässt. Nur weil C6 nicht mehr genutzt wird, läuft eine Anwendung nicht automatisch schneller.

Spannend finde ich trotzdem, an welchen Stellen man etwas hinters Licht geführt wird. Im BIOS steht „Static High Performance“, die C-States sind abgeschaltet und trotzdem entscheidet das Betriebssystem am Ende anders.

Kaum macht man es richtig, funktioniert es. Die Stromrechnung erinnert einen dann aber daran, dass volle Leistung auch ihren Preis hat.

Der Tanker läuft mit voller Kraft voraus. Keine unnötigen Pausen, keine Tiefschlafphase und möglichst geringe Verzögerungen.

Oder?

Nö. Das interessiert meinen Lieblings-Hypervisor Proxmox auf Debian-Basis offenbar einen feuchten ***.

Warum wird C6 trotzdem genutzt?

Obwohl im BIOS alles korrekt eingestellt war, zeigte PowerTOP weiterhin, dass die Prozessoren fleißig den tiefen C6-Zustand nutzten.

Also begann die übliche Fehlersuche:

• BIOS-Einstellungen prüfen
• Einstellungen zurücksetzen und neu setzen
• BIOS aktualisieren
• Server neu starten
• Erneut messen
• Langsam an sich selbst zweifeln

Nach mehreren Durchläufen und einigen energischen Rückfragen lieferte die Google-KI schließlich einen entscheidenden Hinweis: Der Linux-Kernel verwendet auf Intel-Systemen den Treiber intel_idle. Dieser verwaltet die verfügbaren Ruhemodi der CPU und kann dabei tiefere C-States anbieten, obwohl diese im BIOS vermeintlich eingeschränkt wurden.

Ganz aus der Luft gegriffen war diese Aussage nicht. IBM beschreibt genau dieses Verhalten für bestimmte Serversysteme. Auch die Dokumentation des Linux-Kernels bestätigt, dass intel_idle und acpi_idle unterschiedliche Wege zur Verwaltung der C-States nutzen.

Wichtig ist jedoch: Das ist kein reines HPE- oder Proxmox-Problem. Es betrifft das Zusammenspiel aus Firmware, Prozessor und Linux-Kernel. Außerdem sind „High Performance“ und das Abschalten tiefer C-States nicht automatisch dasselbe. Das eine betrifft vor allem die Leistung und Taktsteuerung, das andere die Ruhephasen der CPU.

Die Lösung

EFI: In meinem Fall half der folgende Kernel-Parameter:

intel_idle.max_cstate=1

Damit darf intel_idle weiterhin genutzt werden, wird aber auf einen flachen C-State begrenzt.

Bei einem Proxmox-System sollte zuerst geprüft werden, welcher Bootloader tatsächlich verwendet wird:

proxmox-boot-tool status

Wenn das Ergebniss wie bei mir EFI ist müssen wir folgendes machen:

nano /etc/kernel/cmdline

und folgendes in der Zeile hinzufügen:

intel_idle.max_cstate=1

Danach wird die Boot-Konfiguration aktualisiert:

proxmox-boot-tool refresh

BIOS: Bei einer klassischen GRUB-Konfiguration wird der Parameter dagegen in /etc/default/grub innerhalb von GRUB_CMDLINE_LINUX_DEFAULT eingetragen:

GRUB_CMDLINE_LINUX_DEFAULT="quiet intel_idle.max_cstate=1"

Anschließend:

update-grub
reboot

Nach dem Neustart kann geprüft werden, welcher Treiber aktiv ist:

cat /sys/devices/system/cpu/cpuidle/current_driver

Zusätzlich sollte kontrolliert werden, ob der Parameter wirklich übernommen wurde:

cat /proc/cmdline

Und siehe da: C6 war verschwunden und der Server verhielt sich endlich so, wie es die BIOS-Einstellung bereits versprochen hatte.

Kaum macht man es richtig, funktioniert es.

Kleiner Hinweis

Das Einschränken tiefer C-States kann den Stromverbrauch und die Wärmeentwicklung erhöhen. Es sollte daher nicht vorsorglich auf jedem Server umgesetzt werden. Sinnvoll ist es vor allem dann, wenn messbare Verzögerungen auftreten und ein Vorher-Nachher-Test zeigt, dass die Änderung wirklich hilft. Das Performance Workload Profil ändert nichts an den C-States Einstellungen.

Quellen:

• Linux Kernel: CPU Idle Time Management
• Linux Kernel: Parameter intel_idle.max_cstate
• IBM: Linux ignores C-State settings in UEFI
• Proxmox: Host Bootloader
• Prozessor P-States und C-States
• https://www.spec.org/cpu2017/flags/HPE-Platform-Flags-Intel-V1.1-HSW-revB.html

Doch es bleibt noch >> „Die Frage nach den P-States“ >>

Um das Problem zu lösen, habe ich einen Server bei Hetzner gemietet.

Mein Setup besteht aus einer handelsüblichen Maschine mit 32 GB RAM und 1 TB SSD. Darauf läuft Proxmox, mit dem ich mehrere virtuelle Umgebungen betreiben kann.

Proxmox wurde über die Konsole auf einem dedizierten Server bei Hetzner installiert. Innerhalb des Servers habe ich mehrere Netzwerksegmente eingerichtet, die durch die integrierte Proxmox‑Firewall voneinander getrennt und geschützt sind.

Der Datenverkehr zwischen den virtuellen Umgebungen und dem Internet wird zuverlässig überwacht und geschützt. Dafür verwende ich eine OPNsense‑Firewall, die als sichere Datenschleuse dient.

Als privaten Cloud‑Speicher nutze ich Nextcloud in einem fertigen Container (in meinem Fall NextcloudPi). Dieser Container wird durch Proxmox direkt bereitgestellt. Nach der Installation ist Nextcloud sofort einsatzbereit und erfordert nur minimalen Konfigurationsaufwand. Man kann sogar direkt SSL‑Zertifikate über Let’s Encrypt installieren.

(https://community-scripts.github.io/ProxmoxVE/scripts?id=nextcloudpi)

Der Proxmox‑Server ist von außen über Port 8006 per SSL erreichbar. Der Zugriff ist jedoch auf 2–3 feste IP‑Adressen beschränkt, um die Sicherheit weiter zu erhöhen.

Die Test‑Umgebung

Für das Management und die tägliche Arbeit mit der Umgebung nutze ich eine virtuelle Ubuntu‑Maschine. Diese VM befindet sich ebenfalls in einem separaten Netzwerksegment.

Die Datenschleuse ist fest eingebunden, sodass hochgeladene Nextcloud‑Daten sofort in der VM‑Umgebung genutzt und analysiert werden können.

Zur Überprüfung der Daten kommt ein Windows‑System (Windows 11) zum Einsatz. Dieses läuft mit dem Flare VM Framework. (https://github.com/mandiant/flare-vm)

Die virtuelle Maschine wird jede Nacht automatisch um 03:00 Uhr per Cronjob zurückgesetzt, um stets einen sauberen Ausgangszustand zu gewährleisten.

0 3 * * * /root/reset_vm.sh

#!/bin/bash

PATH=/sbin:/bin:/usr/sbin:/usr/bin

# VM-ID und Snapshot-Name anpassen
VM_ID=105
SNAPSHOT_NAME="Clean"

# VM stoppen, falls sie läuft
qm stop $VM_ID

# Snapshot wiederherstellen
qm rollback $VM_ID $SNAPSHOT_NAME

# VM wieder starten
qm start $VM_ID

echo "VM $VM_ID wurde erfolgreich auf Snapshot '$SNAPSHOT_NAME' zurückgesetzt."

Im nächsten Schritt plane ich, den Zugang zum Proxmox‑Server so weit einzuschränken, dass er von außen nicht mehr erreichbar ist. Die Verwaltung soll dann ausschließlich über die interne Management‑VM erfolgen. Diese kann sicher über ein Fernwartungstool wie z. B. RustDesk betrieben werden.

Kosten und Aufwand des Projekts

• Server bei Hetzner: ca. 60 € pro Monat
• Arbeitszeit für Setup und Grundkonfiguration: ca. 2 Tage
• Zeitaufwand für individuelle Anpassungen: geschätzt weitere 2–3 Tage, je nach Bedarf

Alternativ kann das ganze Setup auch auf einem kleinen mini PC laufen

Wichtiger Hinweis

Bitte überprüfe unbedingt die AGB des Hosters genau – insbesondere im Hinblick auf die geplante Nutzung. Das Ziel ist nicht die Entwicklung oder das absichtliche Testen von Schadsoftware, sondern ausschließlich die Analyse und Prüfung verdächtiger E‑Mails. Gefundene Bedrohungen sollen selbstverständlich umgehend gelöscht werden.

Achte außerdem darauf, dass die Testumgebung durch eine Firewall abgesichert ist – idealerweise mit Intrusion Detection und Prevention. So stellst du sicher, dass im Falle eines Schadcodes (z. B. in einem Anhang) kein Risiko für andere Systeme im Rechenzentrum oder im Netzwerk bei Hetzner entsteht.