Das Fraunhofer FOKUS hat für seine Green-Streaming-Untersuchung einen CDN-Server über längere Zeit vermessen. Der Grundverbrauch lag bei rund 450 Watt. In den Abendstunden, also genau dann, wenn Millionen Menschen streamen, kamen ganze 50 Watt hinzu. Die Maschine verbrauchte über 90 Prozent ihrer Energie dafür, verfügbar zu sein, und nicht dafür, zu arbeiten.
Das ist kein Einzelfall. Über die Netze hinweg fallen zwischen 50 und 70 Prozent des Energiebedarfs im Leerlauf und bei geringer Auslastung an, der Netzwerkausrüster Nokia nennt für seine Technik rund 70 Prozent. Rechenzentren und Telekommunikationstechnik können eben nicht wie ein Smartphone in Sekundenbruchteilen in einen Sparzustand wechseln.
Die unbequeme Konsequenz
Ich muss an dieser Stelle etwas einräumen, das meiner eigenen Argumentation zunächst widerspricht. Wenn der Löwenanteil der Energie ohnehin im Leerlauf verbraucht wird, dann spart ein einzelner vermiedener Seitenaufruf eben nicht proportional Strom. Ein nicht gestarteter Stream schaltet keinen Router ab. Ein nicht geladenes Bild lässt keinen Server kühler werden.
Wer behauptet, jedes eingesparte Megabyte reduziere den Verbrauch im gleichen Verhältnis, argumentiert schlicht falsch. Diese Rechnung geht nicht auf.
Schaut man genauer hin, verschiebt sich der Hebel aber nur, er verschwindet nicht. Denn entscheidend ist, wonach diese Infrastruktur überhaupt dimensioniert wird: nach der Spitzenlast. Fraunhofer formuliert es deutlich, dass Telekommunikationsnetze für Spitzenlasten ausgelegt sind und daraus ineffiziente Überkapazitäten in Phasen geringer Auslastung entstehen. Gebaut wird für den schlimmsten Moment, bezahlt wird er das ganze Jahr.
Damit ist klar, wo der eigentliche Ansatzpunkt liegt. Nicht beim Durchschnitt, sondern bei der Spitze. Jede Lastspitze, die gar nicht erst entsteht, ist Kapazität, die niemand bauen muss.
Punkt sechs, Punkt sieben, Punkt acht
Bei einem Rechenzentrumsbesuch hat mir jemand eine Beobachtung erzählt, die mir seitdem nicht mehr aus dem Kopf geht. In den Auslastungskurven sieht man zuverlässig Spitzen zur vollen Stunde, etwas abgeschwächt auch zur halben. Der Grund ist banal: Dort laufen die Cronjobs. Sicherungen, Importe, Cache-Aufbau, Reports. Tausende Systeme tun im selben Moment etwas Aufwendiges, weil ihre Betreiber unabhängig voneinander dieselbe runde Zahl gewählt haben.
Sein Fazit war, dass ein Verschieben um wenige Minuten bereits Strom sparen würde. Das klang zunächst nach einer netten Randnotiz. Tatsächlich ist es ein bekanntes Phänomen mit eigenem Namen: Thundering Herd, die donnernde Herde.
Google beschreibt es im eigenen SRE-Handbuch ausdrücklich. Der Cron-Dienst könne erhebliche Spitzen in der Auslastung eines Rechenzentrums verursachen, weil Menschen bei einem täglichen Job fast immer Mitternacht wählen. Google hat deswegen das crontab-Format um eine Möglichkeit erweitert, den Zeitpunkt vom System verteilen zu lassen. Wenn ein Konzern mit dieser Infrastruktur das Problem für gravierend genug hält, um ein Jahrzehnte altes Format zu ändern, ist es keine Randnotiz.
Und die Lösung ist erfreulich unspektakulär. Man nennt sie Jitter: ein wenig Zufall im Startzeitpunkt. Statt
0 6 * * * /pfad/zum/skript
schreibst Du einfach
7 6 * * * /pfad/zum/skript
Unter systemd erledigt das die Direktive RandomizedDelaySec, die jeden Start um eine zufällige Spanne verzögert. In klassischem cron genügt ein vorgeschaltetes sleep mit einer Zufallszahl. Eine deutsche Hosting-Anleitung empfiehlt sogar ganz konkret, Wartungsjobs auf Minute 7 und 37 zu legen statt auf 0 und 30.
Ich schreibe das übrigens nicht von außen. Der nächtliche Build meiner eigenen Seite startet um Punkt sechs. Runde Zahl, wie bei allen anderen auch.
crontab -l auf dem Server oder in der Oberfläche Deines Hosters. Wetten, dass fast alles auf einer glatten Null oder Dreißig steht? Verschiebe die Jobs auf krumme Minuten und ziehe sie auseinander, also 6:07 statt 6:00, 6:23 statt 6:30. Es kostet Dich zwei Minuten, ändert an Deinem Betrieb nichts und nimmt ein winziges Stück aus einer Spitze heraus, die viele gemeinsam erzeugen.Der nächste Schritt: nicht nur verteilen, sondern verlegen
Wer den Gedanken weiterdenkt, landet bei einer zweiten Frage. Wenn der Zeitpunkt ohnehin flexibel ist, warum dann nicht gleich in eine Stunde legen, in der viel erneuerbarer Strom im Netz ist? Die CO₂-Intensität einer Kilowattstunde schwankt je nach Wetter und Nachfrage erheblich.
Genau daran arbeitet die Green Software Foundation unter dem Stichwort Carbon-aware Computing. Eine Untersuchung des Berlin Institute for the Foundation of Learning and Data mit dem hübschen Titel „Let’s Wait Awhile“ hat die Netze in Deutschland, Großbritannien, Frankreich und Kalifornien analysiert und kommt zu dem Ergebnis, dass sich durch das zeitliche Verschieben zeitunkritischer Rechenlasten ein erheblicher Teil der Emissionen vermeiden lässt. Google betreibt für seine Rechenzentren längst ein System, das flexible Aufgaben gezielt in emissionsärmere Stunden verzögert.
Für Deinen Hugo-Build oder Dein nächtliches Backup ist das offensichtlich eine Nummer zu groß. Das Prinzip ist aber dasselbe, nur eine Etage höher: Nicht jede Rechenoperation muss sofort passieren, und was warten kann, sollte warten, bis es günstiger ist.
Effizienz fragt üblicherweise, wie viel wir verbrauchen. Die interessantere Frage lautet, wann. Denn gebaut wird nicht für den Durchschnitt, sondern für den einen Moment, in dem alle gleichzeitig etwas wollen. Und der günstigste Zeitpunkt für eine Berechnung ist fast nie die volle Stunde.
Quellen: Fraunhofer FOKUS: Green Streaming Whitepaper 2024 · Google SRE Book: Distributed Periodic Scheduling with Cron · BIFOLD: Let’s Wait Awhile, zeitliche Lastverschiebung in der Cloud