Software-Bloat

Es ist eine oft gemachte empirische Beobachtung, dass die Performancegewinne der Hardware meist durch die Software bald wieder wettgemacht werden. Mit jeder neuen Version hat Software oft gesteigerte Anforderungen an die Hardware, nicht selten führt ein Upgrade der Software auch zur Notwendigkeit die Hardware zu tauschen.

Seit den Anfängen der Informationstechnologie hat sich der Schwerpunkt bei der Softwareerstellung von Laufzeiteffizienz hin zu „Programmierproduktivität“ verschoben [Bhattacharya u.a., 2011]. Softwaresysteme sind heutzutage sehr modular aufgebaut, die Flexibilität und Wiederverwendbarkeit von Bibliotheken steht im Vordergrund, die Anwendungskomplexität wird meist mittels einer Schichtenarchitektur abstrahiert. Auch wenn in einem Softwareprojekt nur eine Teilmenge der verfügbaren Funktionalität benötigt wird, so ist doch oft der Overhead des gesamten Frameworks zu tragen. Dies kann zur Erzeugung großer Mengen von Objekten, übermäßig vielen Funktionsaufrufen und übertrieben großen Datenstrukturen führen. So benötigte beispielsweise in einer Börsensoftware die Übermittlung eines Datumsfeldes von einer SOAP-Message in ein Java-Objekt 58 Umwandlungen und generierte 70 Objekte [Mitchell u.a., 2006].

Es hängt von verschiedenen Faktoren ab, wie sehr die Überbeanspruchung von Ressourcen durch „Software Bloat“, zu einem erhöhten Energieverbrauch führt. Eine zu hohe Ausnutzung des Hauptspeichers, wie sie beim sogenannten „Datastructure Bloat“ vorkommt, ist vom Standpunkt der Energieeffizienz her als geringeres Problem einzustufen als eine zu hohe Auslastung der CPU, wie sie beim „Execution Bloat“ durch vermehrte Funktionsaufrufe und Objektgenerierungen auftritt [Bhattacharya u.a., 2011].

Ein bestimmender Faktor ist auch der durch ineffiziente Software ausgelöste Auslastungsgrad der Hardwareressourcen und ob diese im Gesamtsystem zum Engpass werden. Bei einer „bottleneck“-Ressource wird die allgemeine Systemleistung herabgesetzt, ohne dass die Energieeffizienz maßgeblich beeinflusst wird. Wirkt sich die Auslastung einer Ressource nicht beschränkend auf die Gesamtperformance aus, handelt es sich also um keinen Engpass, wird sich der Energieverbrauch des Systems durch Software Bloat stärker verändern lassen. Der Grad dieser Beeinflussung wiederum ist abhängig von der Energieproportionalität der betroffenen Ressource, also davon, wie sehr der Energieverbrauch vom Nutzungsgrad abhängig ist [Bhattacharya u.a., 2011].

Allgemein ist zu sagen, dass zur Erreichung eines energieeffizienten Gesamtsystems auch die Rolle der Software zu beachten ist. Bei der Planung und Implementierung einer Applikation sollten stets auch die Auswirkungen auf die Hardware in Betracht gezogen werden. Das Ziel von nachhaltiger Softwareentwicklung ist die Einbeziehung des direkten und indirekten Ressourcenverbrauches und auch die Berücksichtigung der Auswirkungen der Softwaresysteme über ihren gesamten Lebenszyklus hinweg [Johann u.a., 2011].

Holistische Ansätze zur Bewertung des Lebenszyklus

Bei holistischen Ansätzen, wie sie in [Ranganathan und Chang, 2011] besprochen werden, wird die Auffassung vertreten, dass es notwendig ist, alle Ebenen eines Systems zu betrachten, von der Chipebene bis zur Rechenzentrumsebene, und alle Aspekte der IT, von der Hardware zur Software. Der Energiebedarf muss von der Nachfrageseite (Energieverbrauch während des Betriebes) wie auch von der Angebotsseite (Energie zur Erstellung eines Systems) betrachtet werden.

Es ist also notwendig, die Nachhaltigkeit eines Systems über den gesamten Lebenszyklus hinweg zu beurteilen. Dazu kann man das thermodynamische Maß des Exergieverbrauches heranziehen. Es kann nämlich gezeigt werden, dass Optimierungen des Exergieverbrauches über den Lebenszyklus hinweg relativ gut den Optimierungen basierend auf Kriterien des Umweltschutzes und der Nachhaltigkeit, wie zum Beispiel Emissionen und Verschmutzung, entsprechen [A. Shah, 2009].

In [Chang u.a., 2010] wurde der Exergieverbrauch aufgeteilt in

  • „Embedded Exergy“ (Zur Erzeugung eines Systems aufgewendete Exergie),
  • „Operational Exergy“ (der Exergieverbrauch während des Betriebes) und
  • Exergie, die zum Betrieb der Infrastruktur (Kühlung, Beleuchtung etc.) aufgewendet wird,
  • um den Exergieverbrauch über den gesamten Lebenszyklus hinweg zu modellieren. Mit dieser Methode kann unter anderem gezeigt werden, dass die Optimierung eines IT-Systems auf eine möglichst hohe Energieeffizienz während der Betriebsphase nicht notwendigerweise zu einer Optimierung des Exergieverbrauches über den gesamten Lebenszyklus hinweg führt.

    Im Sinne eines holistischen Ansatzes reicht es also nicht, die Nachhaltigkeit eines IT-Systems nur in Bezug auf die Betriebsphase zu optimieren, sondern es muss der Lebenszyklus aller beteiligten Komponenten und der damit einhergehende Exergieverbrauch in die Bewertung einbezogen werden.

    Weiterentwicklungen des PUE

    pPUE: Beim „partial PUE“ [Azevedo u.a., 2011b] wird nicht der Gesamtverbrauch, sondern nur ein Teil des Verbrauches eines Rechenzentrums berücksichtigt (darum „Partial“). Beispielsweise wird dem IT-Verbrauch nur die Gebäudekühlung oder nur die einer bestimmten Abteilung im Unternehmen zuzurechnende Infrastruktur gegenübergestellt. Der pPUE hat in bestimmten Situationen eine höhere Aussagekraft als der allgemeine PUE und ermöglicht eine zielgerichtetere Optimierung.

    ERE: Die „Energy Reuse Effectiveness“ [Azevedo u.a., 2011b] soll die Tatsache berücksichtigen, dass es in der Berechnung des PUE nicht erlaubt ist, die zurückgewonnene Energie zu berücksichtigen, das heißt ein PUE kann niemals kleiner als eins sein. Wenn zum Beispiel die Abwärme eines Rechenzentrums über Wärmerückgewinnung zur Beheizung des Bürogebäudes verwendet wird, darf diese Energie vom Gesamtverbrauch nicht abgezogen werden, sondern muss als ERE ausgewiesen werden. Diese ist deshalb definiert als:
    ERE=(Gesamtenergieverbrauch−rückgewonnene Energie)/IT−Verbrauch

    DCcE: Die „Data Center compute Efficiency“ [Azevedo u.a., 2011b] berechnet sich aus dem Durchschnitt der „Server compute Efficiency“ (ScE) aller im Rechenzentrum betriebenen Server und ist ein Maß der „nützlichen“ Arbeit, die in einem Rechenzentrum verrichtet wird. Dabei berechnet sich die ScE wiederum aus dem Grad der von jedem einzelnen Server geleisteten „nützlichen“ Arbeit, welche sich definitionsgemäß aus dem Anteil der primären Services an der Gesamtauslastung des Servers berechnet. Diese primären Services beinhalten jene Aufgaben, für die der Server in Betrieb genommen wurde und nicht sekundäre und tertiäre Dienste wie Virenscanning, Backup, Defragmentierung und ähnliches.

    WUE, CUE: Die beiden Maße „Carbon Usage Effectiveness“ (CUE) und „Water Usage Effectiveness“ (WUE) sind Weiterentwicklungen des PUE, welche nicht auf die Effizienz der eingesetzten (elektrischen) Energie abzielen, sondern die Effizienz der Nutzung der Ressource Wasser (WUE) und die Effizienz in der Erzeugung von Emissionen (eine hohe Effizienz entspricht hier natürlich geringen Emissionen!) darstellen [Azevedo u.a., 2011a].

    GPUE: Die primäre Motivation für dieses Maß ist es, der Instrumentalisierung des PUE für „Greenwashing“ durch die Marketingabteilungen mancher Unternehmen entgegenzuwirken. Die „Green Power Usage Effectiveness“ versucht, die Art der zum Betrieb eines Datacenters verwendeten Energie in ein Effizienzmaß einfließen zu lassen, das heißt der PUE wird anhand der durch die Energieerzeugung verursachten Emissionen gewichtet [Hrafnsson, 2012]. So wird beispielsweise Energie aus Kohlekraftwerken mit einem Faktor 1,05 gewichtet, Energie als Wasserkraft hingegen mit 0,013.
    Für die Gewichtung der Energiearten wird dabei eine Studie herangezogen, in der der Anteil der Emissionen an der aus einer gegebenen Energiequelle erzeugten Energie geschätzt wird, und zwar über den gesamten Lebenszyklus dieser Energiequelle hinweg [Sovacool, 2008].

    EUE: Die „Energy Usage Effectiveness“ wurde von der „United States Environmental Protection Agency“ (EPA) vorgeschlagen und ist in ihrer Berechnung dem PUE sehr ähnlich. Sie berechnet sich als
    EUE=Total Energy/UPS Energy
    wobei sich „Total Energy“ nicht auf elektrische Energie beschränkt, sondern alle Energiearten, die zum Betrieb eines Rechenzentrums benötigt werden, einschließt, und „UPS Energy“ der von der IT verbrauchten Energie entspricht.

    Onlineressourcen

    Eine unvollständige, unsortierte, unkommentierte Liste von Onlineressourcen zum Thema:

    www.oeko.de
    uptimeinstitute.com
    www.thegreengrid.org
    www.giswatch.org
    www.cio.bund.de/Web/DE/Innovative-Vorhaben/Green-IT/green_it_node.html
    www.eembc.org
    www.energystar.gov
    iet.jrc.ec.europa.eu/energyefficiency/ict-codes-conduct/data-centres-energy-efficiency
    www.energyefficiency.at
    blog.greenqloud.com
    maps.klimaaktiv.at/index.php?id=190&cat=2155
    www.blauer-engel.de
    www.tcodevelopment.de
    www.emas.de