Den Energieverbrauch von Software sichtbar machen – Prozess für Prozess

Wenn Software Strom verschlingt

Wer in der Softwarebranche arbeitet, hat wahrscheinlich gelernt, in Performance-Diagrammen zu denken. Repsonse Times, Speicherverbrauch und Request-Rates sind allesamt Zahlen, die dabei helfen zu verstehen, was vor sich geht und wo an Stellschrauben gedreht werden muss. Energie dagegen wird oft als ein weit entferntes Infrastrukturproblem betrachtet: etwas, um das sich das Rechenzentrum, der Cloud-Anbieter oder das „Ops-Team” kümmern muss.

Aber Energie ist nicht weit weg. Sie ist die physische Seite jedes digitalen Dienstes. Und heutzutage wird diese physische Seite immer schwerer zu ignorieren: Die globalen Stromsysteme stehen unter Druck, die Klimaziele werden verschärft, und die Ressourcen hinter unserer Hardware – von Chips über Kühlung bis hin zu Stromnetzen – sind alles andere als unbegrenzt. Bei der Senkung des Energiebedarfs geht es nicht nur darum, Geld zu sparen, sondern auch darum, Emissionen in einer Welt zu reduzieren, die noch immer einen Großteil ihres Stroms aus fossilen Brennstoffen gewinnt, und in Zeiten zunehmender Knappheit und Konkurrenz um Energie verantwortungsbewusst zu handeln.

Der Haken ist jedoch, dass es selbst dann, wenn Teams den Energiebedarf senken wollen, in der Praxis schwierig ist, dies umzusetzen. Denn in der Regel ist nicht bekannt, wofür die Energie tatsächlich verwendet wird.

Diese Lücke versucht ProcPower zu schließen.

Das Problem mit dem „Gesamtverbrauch”

Die meisten Systeme können Ihnen die gesamte CPU-Auslastung oder die gesamte Cloud-Nutzung anzeigen. Das ist genauso nützlich wie Ihre monatliche Stromrechnung: Sie wissen, dass Sie Ressourcen verbraucht haben, aber Sie wissen nicht, *warum* oder was sich geändert hat oder was Sie zuerst beheben müssen.

Softwaresysteme bestehen aus verschiedenen Teilen: einem Webserver, einer Datenbank, Hintergrundaufgaben, geplanten Aufgaben, Plugins, Bildverarbeitung, Suchindexierung, Videotranskodierung… und die Liste wird immer länger, wenn man Container und Microservices hinzufügt. Wenn Energie nur als Gesamtwert sichtbar ist, wird sie zu einer vagen Gesamtzahl. Niemand kann den genauen Verbrauch bestimmen und niemand übernimmt die Verantwortung.

Deshalb ist die Messung des Energieverbrauchs pro Prozess eine so große Veränderung.

Sie verwandelt „das System verbraucht Energie” in „dieser Prozess macht den Ausschlag”. Dadurch wird Nachhaltigkeit weniger zu einem Slogan und mehr zu einer Debugging-Aufgabe. Und das ist wichtig, denn die Klima- und Ressourcenseite digitaler Dienste wird zunehmend von der Nachfrage bestimmt: Mit steigender Arbeitslast wächst auch der Energieverbrauch – es sei denn, wir wirken dem aktiv mit besserer Software, besseren Abläufen und besseren Feedbackschleifen entgegen.

Warum der Energiebedarf jetzt wichtig ist

Es ist verlockend, digitale Dienste im Vergleich zu anderen Sektoren als „sauber“ zu bezeichnen, da weder Schornsteine noch Auspuffrohre zu sehen sind. Aber die Emissionen verschwinden nicht, sie verlagern sich in das Stromsystem und die Lieferketten, die unsere Infrastruktur aufbauen und betreiben.

Und hier wird der Energiebedarf im Zusammenhang mit dem Klimawandel und der Ressourcenknappheit kritisch:

• Auswirkungen auf das Klima: Solange Teile des Netzes noch auf fossile Energieerzeugung angewiesen sind, bedeutet ein höherer Strombedarf in der Regel mehr Emissionen – oder zumindest einen langsameren Weg zur Dekarbonisierung, da die saubere Versorgung einen ständig wachsenden Bedarf decken muss.
• Ressourcenknappheit: Energie ist nicht der einzige knappe Input. Hardware erfordert Materialien, Produktionskapazitäten, Kühlung und zunehmend umkämpfte Netzanschlüsse. Eine Verringerung der Nachfrage auf Softwareebene kann den Druck auf die gesamte Infrastruktur verringern.
• Systemresilienz Spitzenlasten sind wichtig. Wenn Software unnötige Arbeit vermeiden kann – insbesondere burstartige Hintergrundaufgaben –, kann sie die Spitzenlast reduzieren und den Betrieb der Infrastruktur vereinfachen. Selbst kleine Verbesserungen summieren sich, wenn sie auf Millionen von Bereitstellungen angewendet werden.

Energie dort sichtbar machen, wo Entscheidungen getroffen werden

ProcPower ist Teil der Open-Source-Arbeit rund um das Green-Kernel Projekt.

Der Schwerpunkt liegt nicht auf „einem weiteren Nachhaltigkeitsbericht“, sondern auf etwas viel Praktischerem: der Energiesichtbarkeit auf der Ebene von Prozessen und Diensten unter Linux. Damit lässt sich der Energieverbrauch mit tatsächlichen Entscheidungen - Code-Pfaden, Jobs, Plugins, Deployments - in Verbindung bringen anstatt Energie als abstrakte Kosten für den „Betrieb von Computern“ zu behandeln.

Und sobald Energie zugeordnet werden kann, werden andere Diskussionen möglich:

• Man kann über einen teuren Hintergrundjob genauso diskutieren wie über eine langsame Abfrage.
• Man kann zwei Implementierungen nicht nur hinsichtlich der Latenz, sondern auch hinsichtlich des Energiebedarfs vergleichen.
• Man kann feststellen, dass ein Plugin, eine neue Funktion oder eine Konfigurationsänderung den Energieverbrauch unbemerkt erhöht hat.

Eines der schwierigsten Dinge an der Nachhaltigkeit in der Technik ist, dass sie sich eher wie eine moralische als wie eine technische Diskussion anfühlt. ProcPower bringt sie zurück in den technischen Bereich: messen, zuordnen, lernen, verbessern. Und da es sich um Open Source handelt, lädt es zur Zusammenarbeit ein: neue Integrationen, bessere Modelle, bessere Benutzererfahrung, bessere Standardeinstellungen.

Wie funktioniert das technisch?

ProcPower fügt Linux eine leichtgewichtige „Messschicht” hinzu, die Ressourcenaktivitäten den Prozessen und Prozessgruppen (Diensten/Containern) zuordnen kann, die sie verursacht haben. Anstatt zu versuchen, den Energieverbrauch anhand einer einzigen systemweiten Zahl zu schätzen, sammelt es die gleichen Signale, auf die Sie sich bereits für die Leistungsarbeit verlassen - CPU-Zeit, Wakeups/Kontextwechsel, Speicherbedarf und E/A-Aktivität - und kombiniert sie mit Hardware-Energiezählern, sofern diese verfügbar sind. Das Ergebnis ist eine prozess- (und container-)bezogene Ansicht, die im Laufe der Zeit ausgewertet werden kann, sodass Spikes erkannt, mit Deployments oder Jobs korreliert und „Vorher-Nachher“-Veränderungen verglichen werden können. Entscheidend ist, dass in Container-Setups die Metriken auf Cgroup-Ebene angezeigt werden, sodass ein Dienst seinen eigenen Speicherbedarf einsehen kann, ohne dass Host-Berechtigungen erforderlich sind. Dies macht es für reale Deployments praktisch, bei denen Isolation und Sicherheit eine Rolle spielen.

ProcPower erinnert uns daran, dass Nachhaltigkeit nicht nur in Jahresberichten oder abstrakten Zielen vorkommen muss, sondern Teil der täglichen Entwicklungsarbeit sein kann. Wenn Energie auf der Ebene von Prozessen und Diensten sichtbar wird, können Teams sie wie jede andere Betriebsmetrik behandeln: sie untersuchen, Kompromisse diskutieren und iterativ verbessern. In einer Welt, in der Strom, Hardware und Netzkapazität zunehmend begrenzt sind, ist diese Art der praktischen Sichtbarkeit eine kleine Veränderung mit großer Wirkung.