35-W-CPU im Homeserver: 5,1 W im Leerlauf, 31,6 W unter Volllast

Kurz gesagt: Die CPU dieses Homeservers zieht im Leerlauf 5,1 Watt und unter Volllast 31,6 Watt — gemessen am Energiezähler im Prozessor selbst, nicht geschätzt. Der wichtigste Satz dieser Messreihe ist aber die Einschränkung: Das ist nicht der Verbrauch an der Steckdose. Und der zweitwichtigste Befund war ein Sensor, der zwei Wochen lang „alles in Ordnung" meldete und dabei überhaupt nichts lieferte.

Warum diese Messung #

Ein Homeserver läuft 24 Stunden am Tag. Die Frage „was kostet das eigentlich?" beantworten die meisten Quellen mit der TDP aus dem Datenblatt — hier also 35 Watt. Das ist aber eine Auslegungsgrenze für die Kühlung, kein Messwert.

Moderne Intel-Prozessoren führen selbst Buch: RAPL (Running Average Power Limit) ist ein Energiezähler im Chip, den der Kernel über /sys/class/powercap bereitstellt. Er zählt Joule; wer die Zunahme pro Sekunde bildet, bekommt Watt. Damit lässt sich beantworten, wie viel von der Datenblattzahl im Alltag tatsächlich anfällt.

Was RAPL misst — und was nicht #

Das ist die Abgrenzung, ohne die jede dieser Zahlen falsch gelesen wird:

Enthalten	Nicht enthalten
Rechenkerne	Netzteil und dessen Wirkungsgrad
Speichercontroller, Uncore	Bildschirm (hier: ein 24-Zoll-Panel im Gehäuse)
Integrierte Grafik (sofern der Zähler läuft)	Festplatten, Lüfter, Chipsatz, USB-Geräte

Bei einem All-in-One-Gerät mit eingebautem Bildschirm ist die Differenz zwischen CPU-Leistung und Steckdosenleistung besonders groß. Wer wissen will, was das Gerät wirklich aus der Wand zieht, braucht ein Messgerät zwischen Stecker und Dose — RAPL ersetzt das nicht. Beide Werte werden hier deshalb bewusst getrennt geführt und nie miteinander verrechnet; die Steckdosenmessung steht noch aus.

Methodik #

• Gemessen wurde nicht direkt am Sysfs, sondern über die vollständige Kette node_exporter → Prometheus → HTTP-API — also genau der Weg, über den die Werte auch im Alltag angezeigt werden.
• Leistung als rate(node_rapl_package_joules_total[1m]), kein eigener Abfrage-Dienst.
• Last erzeugt durch sechs parallele openssl speed aes-256-cbc, also volle Auslastung aller sechs Kerne, 125 Sekunden lang.
• Vor der Leerlauf-Ablesung 100 Sekunden Beruhigung.
• Drei Läufe: Leerlauf, Volllast, Leerlauf danach. Die beiden Leerlaufwerte lagen bei 5,12 W und 4,97 W.
• Raumtemperatur nicht erfasst — die Temperaturwerte sind deshalb Betriebswerte dieses Geräts, keine normierten Messungen.

Die Zahlen #

	Leerlauf	Volllast (6 Kerne)
CPU Package	5,12 W	31,55 W
davon Rechenkerne	4,35 W	30,75 W
Speicher-Domain	0,67 W	0,63 W
CPU-Temperatur	54 °C	69 °C
Ø Taktfrequenz	3,19 GHz	3,10 GHz
Throttling-Ereignisse	0	0

Zwei Dinge fallen daran auf.

Die 35-Watt-CPU bleibt unter ihrem Limit. 31,6 W gegen ein PL1 von 35 W — das Gerät läuft bei voller Rechenlast nicht ins Temperatur- oder Leistungslimit, der All-Core-Turbo hält 3,1 GHz. Für einen Server, der gelegentlich rechnet und meistens wartet, ist das eine beruhigende Auskunft.

Der Leerlauf ist der eigentliche Kostenfaktor. Ein Homeserver verbringt den größten Teil des Tages im Leerlauf. 5,1 W CPU-Leistung sind dort der relevante Wert — nicht die 31,6 W, die vielleicht eine Stunde pro Woche anfallen. Was daraus an Stromkosten wird, hängt am Gesamtgerät und damit an einer Messung, die noch fehlt; grob überschlagen lässt sich das mit dem Stromkosten-Rechner, solange klar bleibt, dass CPU-Leistung nur ein Teil davon ist.

Der Chipsatz ist wärmer als die CPU #

Der Wert, mit dem hier niemand gerechnet hatte: Der Chipsatz läuft dauerhaft bei 70–73 °C, während die CPU im Normalbetrieb zwischen 46 und 60 °C liegt. Für diese Plattform ist das normal und unkritisch — aber ohne einen Blick auf die Chipsatz-Temperatur wäre es nie aufgefallen. Wer Temperaturen überwacht und dabei nur „die CPU-Temperatur" nimmt, sieht den wärmsten Punkt des Systems möglicherweise gar nicht.

Ebenfalls aus der Messreihe: Der I/O-Druck liegt bei rund 2,4 %, der CPU-Druck bei 0,2 %, der Speicherdruck praktisch bei null. „Druck" (im Kernel: Pressure Stall Information) misst, wie viel Zeit Prozesse mit Warten verbringen — anders als eine Auslastungsangabe in Prozent. Der Engpass dieses Hosts ist damit belegbar I/O, nicht CPU. Aus reinen Auslastungswerten war das nicht ablesbar.

Was die Hardware nicht hergibt #

Die Hälfte der Arbeit bestand darin, sauber zu belegen, was dieses Gerät nicht messen kann. Das ist kein Nebenergebnis, sondern spart beim nächsten Mal die Suche:

Gesucht	Warum es nicht geht
Lüfterdrehzahl	Die Lüfterobjekte des Geräts kennen nur „an" und „aus" — kein Drehzahlgeber vorhanden.
Spannungen	Kein einziger Spannungssensor in irgendeinem Sensor-Chip des Geräts.
Mainboard-/VRM-Temperatur	Existiert nicht. Einen vorhandenen Sensor einfach „Mainboard" zu nennen wäre plausibel und falsch.
ECC-Fehlerzähler	Kein ECC-Speicher verbaut.
GPU-Temperatur und -Last	Die integrierte Grafik meldet nur ihren Takt, keine Temperatur.

Der Grund dahinter ist einer, der vor jeder Monitoring-Planung gehört: Der Gehäusetyp entscheidet über die Sensorik. Ein Fertiggerät vom Markenhersteller legt seinen Sensor-Baustein nicht offen — dort ist keine Konfiguration möglich, die daran etwas ändert. Diese Frage gehört an den Anfang einer Monitoring-Planung, nicht ans Ende.

Die drei Fallen #

Ein Sensor-Modul, das Erfolg meldet und nichts liefert. Der RAPL-Collector meldete zwei Wochen lang Status „erfolgreich" und exportierte dabei null Messreihen. Der Fehler war vollständig stumm. Ursache: Dem Exporter im Container fehlten zwei dokumentierte Standard-Optionen, mit denen er das Dateisystem des Hosts statt sein eigenes liest. Die Lehre gilt für jedes Monitoring: Ein Collector mit Status „ok" ist kein Beleg dafür, dass er Daten liefert. Immer einmal in die tatsächliche Ausgabe schauen.

Eine Kernel-Härtung im Weg — und die verbreitete Anleitung dazu ist schlecht. Der Energiezähler ist seit einer Sicherheitslücke von 2020 (PLATYPUS, CVE-2020-8694) nur noch für root lesbar, weil sich aus feinem Energieverlauf Rückschlüsse auf verarbeitete Daten ziehen lassen. Die überall zu findende Lösung ist ein chmod -R o+r auf das ganze Verzeichnis — das macht den Seitenkanal für jeden lokalen Prozess wieder lesbar. Der bessere Weg kostet zwei Zeilen mehr: eine eigene Systemgruppe anlegen, per udev-Regel nur die Zählerdatei lesend für diese Gruppe freigeben, den Exporter in die Gruppe stecken. Die Schreibrechte auf die Leistungslimits bleiben dabei unangetastet. Eine Härtung dreht man nicht zurück, man öffnet gezielt.

Fehlend ist nicht null. Drei Werte in dieser Messreihe waren „0" und meinten „kein Wert": eine Temperaturzone des abgeschalteten WLAN-Chips (0 °C), eine Leistungsdomain, deren Zähler auf dieser Plattform schlicht nicht hochzählt (0 W — gegengeprüft unter Volllast, nicht nur im Leerlauf), und leere Messreihen, die als leeres Diagramm statt als „keine Daten" gezeichnet wurden. 0 °C heißt „eiskalt", 0 W heißt „verbraucht nichts", 0 rpm heißt „Lüfter steht" — alle drei sind etwas anderes als „kein Sensor". Dieser Unterschied muss bis in die Anzeige durchgehalten werden, sonst fällt er genau dort um.

Einschränkungen #

• RAPL ist keine Steckdosenmessung. Netzteil, Bildschirm, Laufwerke, Lüfter und Chipsatz sind nicht enthalten.
• Je ein Messpunkt pro Betriebszustand, kein Dauerlauf über Stunden. Der Leerlaufwert wurde zweimal bestätigt, der Lastwert einmal.
• Raumtemperatur nicht erfasst.
• Alle Werte gelten für dieses Gerät. Andere CPUs derselben Klasse können im Leerlauf deutlich abweichen — die Größenordnung „einstellige Wattzahl im Leerlauf, unterhalb der TDP unter Last" ist übertragbar, die konkrete Zahl nicht.

Was als Nächstes fehlt #

Die Steckdosenmessung. Erst sie beantwortet die Frage, die am Anfang stand: was das Gerät im Jahr kostet. Bis dahin bleibt hier stehen, was gemessen wurde — und was nicht.