Analyse der Korrelation zwischen der IT- Ressourcenauslastung und dem Energieverbrauch einer beispielhaften Unternehmensanwendung

Größe: px
Ab Seite anzeigen:

Download "Analyse der Korrelation zwischen der IT- Ressourcenauslastung und dem Energieverbrauch einer beispielhaften Unternehmensanwendung"

Transkript

1 FAKULTÄT FÜR INFORMATIK DER TECHNISCHEN UNIVERSITÄT MÜNCHEN Bachelorarbeit in Wirtschaftsinformatik Analyse der Korrelation zwischen der IT- Ressourcenauslastung und dem Energieverbrauch einer beispielhaften Unternehmensanwendung Marius Popp

2 FAKULTÄT FÜR INFORMATIK DER TECHNISCHEN UNIVERSITÄT MÜNCHEN Bachelorarbeit in Wirtschaftsinformatik Analyse der Korrelation zwischen der IT-Ressourcenauslastung und dem Energieverbrauch einer beispielhaften Unternehmensanwendung Analysis of the correlation between the IT resource utilization and the energy consumption of an exemplary enterprise application Bearbeiter: Marius Popp Aufgabensteller: Prof. Dr. Helmut Krcmar Betreuer: Andreas Brunnert Abgabedatum: 11. November 2013

3 Erklärung Ich versichere, dass ich diese Bachelorarbeit selbständig verfasst und nur die angegebenen Quellen und Hilfsmittel verwendet habe. Garching b. München, den Ort, Datum Unterschrift II

4 Zusammenfassung Die Bachelorarbeit beschäftigt sich mit der Analyse der Korrelation zwischen der IT- Ressourcenauslastung und dem Energieverbrauch von Unternehmensanwendungen. Motivation hierfür liefert die Erkenntnis, dass der Stromverbrauch von Hardware von der ausgeführten Software abhängig ist. Eine effiziente Nutzung der zugrundeliegenden Hardware durch Software ermöglicht Unternehmen die Einsparung von Betriebskosten durch die Einsparung von Stromkosten. Mehrschichtige Mehranwender-Anwendungen (sog. Unternehmensanwendungen ), die in einem Unternehmen typischerweise vertreten sind, sind der Fokus dieser Bachelorarbeit. Die untersuchten IT-Ressourcen setzen sich aus der zentralen Recheneinheit, dem Arbeitsspeicher und der Festplatte zusammen. Ziel der Bachelorarbeit ist daher eine Aussage für einen beispielhaften Anwendungsfall in wie weit man aus dem Wissen über die Hardwareauslastung durch Software auf den Energieverbrauch dieser Software schließen kann. Auf Basis dieser Information können Aussagen über den Einfluss unterschiedlicher Software- und Hardware-Komponenten auf den Energieverbrauch getroffen werden. Um eine wissenschaftliche Basis für die Analyse der Korrelation zwischen der IT- Ressourcenauslastung und dem Energieverbrauch einer beispielhaften Unternehmensanwendung zu schaffen, werden zunächst die theoretischen Hintergründe zum Thema Energieverbrauch von Software aufbereitet und Methoden zur Gewinnung von Informationen über den Energieverbrauch von Software anhand von Informationen über den IT-Ressourcenbedarf von Software auf ihre Praktikabilität im Unternehmensumfeld untersucht. Davon ausgehend werden die IT-Ressourcenauslastung einer beispielhaften Unternehmensanwendung und der Energieverbrauch der zugrundeliegenden Hardware erhoben. Bedeutsam dabei ist die Analyse der anwendungsbezogenen Veränderungen auf den Energieverbrauch. Gewonnene Erkenntnisse können unter anderem für die Softwareentwicklung im Hinblick auf die Optimierung der Nutzung von IT-Ressourcen verwendet werden, wodurch einerseits der Hardwarebedarf verringert und andererseits der Energieverbrauch gesenkt werden kann. Stichworte: Korrelationsanalyse, Regressionsanalyse, IT-Ressourcenauslastung, Energieverbrauch, Unternehmensanwendung, Experiment. III

5 Inhaltsverzeichnis Erklärung... II Zusammenfassung... III Inhaltsverzeichnis... IV Abbildungsverzeichnis... VI Tabellenverzeichnis... VII Abkürzungsverzeichnis... VIII 1 Einführung Problemstellung Forschungsfragen und Forschungsmethoden Aufbau der Arbeit Grundlagen IT-Ressourcen Unternehmensanwendung Benchmark Performanz-Metriken Energie-Metriken Korrelation Energieverbrauch von Software Energieverbrauch von Systemsoftware Anwendungsspezifischer Energieverbrauch Energieverbrauch von Software in eingebetteten Systemen Ermittlung des Energieverbrauchs von Software Diskussion Vom Hardwarebedarf zum Energieverbrauch von Software Bemessungsgrundlage Hardware Diskussion Von Hardwareauslastung durch Software zum Energieverbrauch von Software Evaluation Experimentaufbau und Messdurchführung Messergebnisse IV

6 5.3 Korrelationsanalyse Validierung von Forschungsergebnissen Zusammenfassung Ausblick Literaturverzeichnis V

7 Abbildungsverzeichnis Abbildung 1: Architektur einer mehrschichtigen Unternehmensanwendung... 6 Abbildung 2: Architektur von SPECjEnterprise Abbildung 3: Vergleich des CPU-bezogenen Stromverbrauchs von Datenbankoperatoren Abbildung 4: Durchschnitt und Variation des Stromverbrauchs von verschiedenen Betriebssystem-Services Abbildung 5: Architektur von SPECpower_ssj Abbildung 6: Stromverbrauch eines Laptops unter verschiedenen Workloads Abbildung 7: Zustandsdiagramm eines Serviceverlaufes Abbildung 8: Unterteilung des Stromverbrauchs eines Servers Abbildung 9: Fehlerrate von High-Level-Energiemodellen Abbildung 10: Architektur des Experiments Abbildung 11: Vergleich Scale und Stromverbrauch Abbildung 12: Vergleich Scale und CPU-Auslastung Abbildung 13: Vergleich Scale und Arbeitsspeicher-Auslastung Abbildung 14: Korrelationskoeffizienten von CPU und Arbeitsspeicher VI

8 Tabellenverzeichnis Tabelle 1: Frequenzbereiche und Energiekoeffizienten Tabelle 2: Evaluation ausgewählter Energiemodelle VII

9 Abkürzungsverzeichnis ACP CPU DVFS FF GPU I/O IPMI IT J JVM s SAN SDRAM W Average CPU Power Zentrale Recheneinheit Dynamic Voltage and Frequency Scaling Forschungsfrage Grafische Recheneinheit Datenübertragungssystem Intelligent Platform Management Interface Informationstechnologie Joule Java-basierte virtuelle Maschine Sekunde Storage Attached Network Synchronous Dynamic Random Access Memory Watt VIII

10 1 Einführung 1.1 Problemstellung Die Informationstechnologie (IT) unterstützt Unternehmen bei der Ausführung ihrer Prozesse und der Datenverarbeitung. Unternehmensanwendungen, welche diese Aufgaben erfüllen, benötigen Rechenkapazität, die von Hardwarekomponenten zur Verfügung gestellt wird. Neben den Anschaffungskosten für Hardwarekomponenten, haben sich die Betriebskosten als drittgrößter Kostenfaktor der IT-Kosten erwiesen (Egle et al. 2008). Zu den laufenden Betriebskosten zählen die Energiekosten, welche unter anderem aufgrund des Energieverbrauchs durch Kühlung und Betrieb von Hardwarekomponenten anfallen. In den Jahren vor der Studie von Buhl/Laartz (2008) ist durch den steigenden Einsatz von IT der Bedarf an Speicher- und Rechenkapazität um 60% gewachsen, wodurch auch die Energiekosten dramatisch anstiegen. EU-weit wurde ein Energieverbrauch von Serverumgebungen und vergleichbaren Hardwareinfrastrukturen in Rechenzentren im Wert von über sechs Milliarden Euro gemessen. Es gibt also einen erheblichen Einsparbedarf hinsichtlich des Energieverbrauchs [ ] (Buhl/Laartz 2008, 261). Für Hardware-Hersteller ergibt sich hieraus ein enormes Einsparpotential. So sollte Hardware energieproportional arbeiten (Barroso/Holzle 2007), sodass Hardware bei Nicht-Nutzung keine Energie und bei aktiver Nutzung Energie in konstantem Verhältnis zur Auslastung verbraucht. Neben dem Aspekt der Energieeffizient von Hardware, gilt es auch den Aspekt des Einflusses von Software zu beachten. Da die auf der Hardware ausgeführte Software einen wesentlichen Einfluss auf den IT-Ressourcen- (zentrale Recheneinheit, Arbeitsspeicher, Festplattenlaufwerke) und Energieverbrauch hat (Mehta et al. 1997), ist es wichtig diesen Einfluss zu quantifizieren, um von Messungen des IT-Ressourcenbedarfs von Software auf den Energieverbrauch von Software zu schließen. Ziel der Arbeit ist daher eine Aussage für einen beispielhaften Anwendungsfall in wie weit man aus dem Wissen über die Hardwareauslastung durch Software auf den Energieverbrauch dieser Software schließen kann. Auf Basis dieser Information können Aussagen über den Einfluss unterschiedlicher Software- und Hardwarekomponenten auf den Energieverbrauch getroffen werden. Gewonnene Erkenntnisse können unter anderem für die Softwareentwicklung im Hinblick auf die Optimierung der Nutzung von IT-Ressourcen verwendet werden, wodurch einerseits der Hardwarebedarf verringert und andererseits der Energieverbrauch gesenkt werden kann. Aus dem optimierten Bedarf an IT-Ressourcen können sich außerdem Potentiale zur Senkung sowohl von einmaligen Kosten (Hardwareanschaffung) als auch von laufenden Kosten (z.b. Energieverbrauch der Hardware (Garrett 2008)) ergeben. 1.2 Forschungsfragen und Forschungsmethoden Die vorliegende Arbeit legt der Analyse der Korrelation von IT-Ressourcenauslastung und Energieverbrauch von Software die folgenden Forschungsfragen zugrunde. Um die Forschungsfragen (FF) zu beantworten, werden die genannten Forschungsmethoden angewandt. 1

11 (1) Frage: Welche Literatur existiert zum Thema Energieverbrauch von Software? Methode: Literatur-Review In FF 1 wird in einem Literatur-Review analysiert, welches Wissen über den Energieverbrauch von Software bereits existiert, um eine Übersicht über geleistete Forschung und theoretische Grundlagen zu erhalten. Weiterhin dient das Literatur-Review dazu, um Anhaltspunkte für die Struktur der Vorgehensweise dieser Forschungsarbeit zu sammeln. (2) Frage: Welche Möglichkeiten existieren, um von dem IT-Ressourcenbedarf von Software auf den Energieverbrauch von Software zu schließen? Methode: Literatur-Review Die Ergebnisse aus FF1 werden in FF2 genutzt um weiterführende Analysen durchzuführen. Es sollen unter anderem Ansätze analysiert werden, um von dem IT-Ressourcenbedarf einer beispielhaften Unternehmensanwendung in Abhängigkeit der zugrundeliegenden beispielhaften Hardwareumgebung auf ihren Energieverbrauch zu schließen. Letztendlich ist die Hardware nur mittelbar der Auslöser für den Bezug von Energie. Da softwaregesteuerte Prozesse jeweils auf bestimmten Hardwareoperationen aufbauen, stellt sich die Frage, in wie weit mögliche Auswirkungen von Softwareaktionen in Form von resultierenden Hardwareoperationen auf den Energieverbrauch erfasst werden können. Hintergrund dieser Untersuchung ist, dass sich Messungen des IT-Ressourcenbedarfs von Software leichter durchführen lassen als Messungen des Energieverbrauchs von Software (z.b. virtualisierte Maschine (Kumar 2010)). Deshalb wäre es vorteilhaft, die Informationen über den IT-Ressourcenbedarf von Software nutzen zu können, um auf den Energieverbrauch von Software zu schließen. (3) Frage: Welche Korrelation existiert zwischen dem IT-Ressourcenbedarf von Software und dem Energieverbrauch einer beispielhaften Unternehmensanwendung? Methode: Experiment, Datenanalyse Ausgewählte Aussagen und Theorien aus den FF1 und FF2 werden schließlich anhand der Forschungsergebnisse in FF3 evaluiert, indem die IT-Ressourcenauslastungen einer beispielhaften Unternehmensanwendung erhoben werden und ihr jeweiliger Einfluss auf den Energieverbrauch untersucht wird. 1.3 Aufbau der Arbeit In Kapitel 2 wird zunächst eine Basis an theoretischem Hintergrundwissen gelegt. Dies beinhaltet die Erläuterung des zugrunde liegenden Unternehmensanwendungs- Begriffes in Verbindung mit der Erläuterung des Benchmark-Begriffes, die Eingrenzung des IT-Ressourcen-Begriffes und die Erläuterung relevanter Performanz- und Energie-Metriken. In Kapitel 3 wird eine Übersicht über aktuelle Forschungsergebnisse zum Thema Energieverbrauch von Software gegeben. Diese theoretische Grundlage beinhaltet die Diskussion über aktuelle Forschungslücken. Basierend auf den Forschungsergebnissen werden Richtlinien für die Durchführung des Experiments anhand ausgewählter Aussagen erarbeitet. 2

12 Kapitel 4 beschäftigt sich mit Methoden zur Ermittlung des Energieverbrauchs von Software anhand von Informationen über die IT-Ressourcenauslastung von Software. Es werden vorgestellte Methoden im Hinblick auf die Praktikabilität der Anwendung im Experiment 1 (mittels einer beispielhaften Unternehmensanwendung) diskutiert. Kapitel 5 beschäftigt sich mit der Analyse der Korrelation von der IT-Ressourcenauslastung von einer beispielhaften Unternehmensanwendung und dem Energieverbrauch von einer beispielhaften Unternehmensanwendung anhand eines Experiments. Zunächst wird der Aufbau des Experiments vorgestellt. Dies beinhaltet eine Einführung in die verwendeten Technologien des Experiments. Nachfolgend wird die Korrelation anhand einer Übersicht von Messergebnissen und einer Analyse dieser Messergebnisse analysiert. Anschließend werden ausgewählte Methoden zur Ermittlung des Energieverbrauchs einer beispielhaften Unternehmensanwendung anhand von Informationen über die IT-Ressourcenauslastung angewendet und diskutiert. Kapitel 6 schließt die Arbeit mit einem Ausblick auf noch mögliche, ausstehende Forschungsarbeiten ab. 1 Vgl. Kapitel 5 3

13 2 Grundlagen Zur Schaffung einer gemeinsamen Grundlage werden im Folgenden die wichtigsten Begriffe und theoretischen Grundlagen erläutert. 2.1 IT-Ressourcen Aufgaben der IT in einem Unternehmen sind Datenhaltung, -aufbereitung, Informationsgewinnung und -management. Diese Aufgaben werden in einem Informationssystem (Krcmar 2005) gemeinsam von Mensch und Technik bewältigt. Die Umsetzung sowohl der Aufgaben Datenhaltung und -aufbereitung als auch der Informationsgewinnung findet primär durch Technik Unterstützung. Dies geschieht mittels Hardware. Die Begriffswelt Hardware umfasst dabei verschiedene Gruppen von Hardwarekomponenten zur Abarbeitung unterschiedlicher Aufgaben. Es existieren Hardwarekomponenten zur Speicherung von Daten (Datenhaltung), zur Weiterverarbeitung von Daten (Datenaufbereitung) und zur Darstellung aufbereiteter Daten (Informationsgewinnung). Nachfolgend werden die im Sinne dieser Arbeit relevanten und zusammengehörigen Hardwarekomponenten vorgestellt. Zur Gruppe der Hardwarekomponenten zur Speicherung von Daten gehören Speichermedien. Speichermedien wiederum lassen sich in die Gruppen der beständigen (einmal erstellte Daten sind nicht veränderbar; z.b. nicht-wiederbeschreibbare Datenträger), der flüchtigen (Daten stehen nur für bestimmte Zeit zur Weiterverarbeitung zur Verfügung; z.b. Arbeitsspeicher) und der halb-beständigen (Daten bleiben beständig erhalten, können jedoch verändert werden; z.b. Festplatten) Speichermedien unterteilen. Zur Gruppe der Hardwarekomponenten zur Weiterverarbeitung von Daten gehören hauptsächlich die zentrale Recheneinheit (CPU) und die grafische Recheneinheit (GPU) und nebensächlich diejenigen Hardwarekomponenten, die zur uneingeschränkten Funktion benötigt werden (z.b. Kühlungsvorrichtungen). Sowohl die CPUs als auch die GPUs basieren technisch auf Prozessoren, die auf rohen Daten bestimmte Rechenoperationen ausführen und somit für die Informationsgewinnung aufbereiten. Im Gegensatz zu CPUs, die für die allgemeine Weiterverarbeitung von Daten Verwendung finden, werden GPUs lediglich speziell für die Aufbereitung von grafischen Daten verwendet. Im Bereich der Darstellung aufbereitete Daten spielen Hardwarekomponenten eine untergeordnete Rolle. Hauptsächlich werden hier Anzeigesysteme (z.b. Bildschirme) verwendet. Ein Informationssystem besteht technisch betrachtet sowohl aus Hardwarekomponenten benötigt für die Abarbeitung der Aufgaben Datenhaltung, -aufbereitung und Informationsgewinnung als auch für den Transport der Daten zwischen den einzelnen Hardwarekomponenten. Dabei können die Hardwarekomponenten physisch zentral (z.b. in einem Server) oder dezentral (z.b. Auslagerung der Hardwarekomponenten für die Datenhaltung mittels eines Storage Attached Network (SAN)) aufgebaut sein. Ein dezentraler Aufbau ermöglicht die gemeinsame Nutzung durch verschiedene Informationssysteme von einzelnen Hardwarekomponenten zur Abarbeitung gemeinsamer Aufgaben. 4

14 Abgrenzung IT-Ressourcenbegriff von Hardwarebegriff Die Eigenentwicklung des IT-Ressourcenbegriffes erfolgte Aufgrund der Notwendigkeit die große Anzahl an Hardwarekomponenten, die in einem Informationssystem enthalten sein können, auf die für diese Arbeit relevante Hardwarekomponenten zu reduzieren. Die Eingrenzung erfolgt nach den in dieser Arbeit zu untersuchenden Hardwarekomponenten. Da in der IT primär die Aufgabenbereiche Datenhaltung und Datenaufbereitung durch Hardware unterstützt werden, werden jeweils die Primärkomponenten im Experiment 2 untersucht. Somit liegt der Fokus auf den Hardwarekomponentenarten CPU (Datenaufbereitung), Arbeitsspeicher und Festplatte (Datenhaltung) und der Begriff IT-Ressourcen umfasst nachfolgend exakt diese drei Hardwarekomponenten. Der hier für die Aufzählung der einzelnen Hardwarekomponenten verwendete Singular umfasst dabei nicht einzelne Hardwarekomponenten, sondern steht stellvertretend für alle Hardwarekomponenten der jeweiligen Hardwarekomponentenart. 2.2 Unternehmensanwendung Die Aufgaben Informationsgewinnung und -management in einem Unternehmen werden primär durch Software unterstützt. Die in dieser Arbeit fokussierte Art von Software ist Anwendungssoftware (Krcmar 2005), die von Mitarbeitern (Anwendern) in einem Unternehmen für ein bestimmten Anwendungsgebiet genutzt wird. Es gibt unterschiedliche Typen von Anwendungen. Anwendungen unterscheiden sich in Einzelanwender-Anwendungen, die von einem einzelnen Anwender genutzt werden, und Mehranwender-Anwendungen, die von mehreren Anwendern gemeinsam genutzt werden. Letztere Anwendungen werden als Unternehmensanwendungen bezeichnet, da sie typisch für die in einem Unternehmen genutzte Anwendersoftware sind. Der Aufbau (vgl. Abbildung 1) einer typischen Unternehmensanwendung ist wie folgt. Die typische Unternehmensanwendung ist dreischichtig aufgebaut. Die drei Schichten sind die Präsentationsschicht, die Applikationsschicht und die Datenbankschicht. Ein Anwender ( User ) greift mittels Client (Laptop, PC, PDA, etc.) über die Präsentationsschicht, die für die Benutzeroberfläche und die Navigation verantwortlich ist, auf die Applikationsschicht zu, die die Geschäftslogik enthält und die definierten Geschäftsprozesse umsetzt. Zum Umsetzen der Geschäftsprozesse kommuniziert die Applikationsschicht mit den anderen beiden Schichten. Die Datenbankschicht ist für die Datenhaltung verantwortlich. Unternehmensanwendungen sind verteilt aufgebaut. Bei verteilten Anwendungen sind die unterschiedlichen Schichten nicht in derselben Software enthalten. Unternehmensanwendungen sind dahingehend verteilt, da sie die Präsentationsschicht auf den Client verlagern und sich die anderen beiden Schichten jeweils getrennt voneinander oder gemeinsam auf einem zentralen Server befinden. Somit ist es den Anwendern möglich, von unterschiedlichen Geräten auf dieselben Daten und Geschäftsprozesse zuzugreifen. 2 Vgl. Kapitel 5 5

15 2.3 Benchmark Die Unternehmensanwendung, die in dieser Arbeit untersucht 2 wird, ist eine Benchmarking- Software (kurz: Benchmark). Gabler Wirtschaftslexikon (o. J.) definiert Benchmarking wie folgt: Abbildung 1: Architektur einer mehrschichtigen Unternehmensanwendung Quelle: (SPO Consulting GmbH 2009, 1) Instrument der Wettbewerbsanalyse. Benchmarking ist der kontinuierliche Vergleich von Produkten, Dienstleistungen sowie Prozessen und Methoden mit (mehreren) Unternehmen, um die Leistungslücke zum sog. Klassenbesten (Unternehmen, die Prozesse, Methoden etc. hervorragend beherrschen) systematisch zu schließen. Grundidee ist es, festzustellen, welche Unterschiede bestehen, warum diese Unterschiede bestehen und welche Verbesserungsmöglichkeiten es gibt. (Gabler Wirtschaftslexikon o. J.) Ein Benchmark ist ein Softwarepaket, das ein bestimmtes Testsystem (Software- oder Hardwarekomponente oder ein komplettes, geschlossenes System von Hardware- und Softwarekomponenten) unter Last stellt (Lasttest), um die Performanz dieses Softwarepaketes zu testen. Dieser Lasttest ist dahingehend wiederholbar, dass die Performanz-Messungen sich von Testlauf zu Testlauf nur minimal unterscheiden und er somit vergleichbare Messergebnisse liefert. Auf Basis dieser Grundlage ist es möglich, an dem Benchmark bzw. dem Test- 6

16 system Änderungen vorzunehmen, um herauszufinden, ob dies eine Erhöhung bzw. eine Verringerung der Performanz zur Folge hat. Die Art der Auslastung eines Lasttests eines Benchmarks, bestimmt sein Workload. Ein Workload definiert, welche Art und Größe von Operationen in einem bestimmten Zeitraum auf dem Testsystem durchgeführt werden, um eine bestimmte Last zu erzeugen. Benchmark SPECjEnterprise2010 Die in dieser Arbeit zu untersuchende Unternehmensanwendung ist die Unternehmensanwendung des Benchmarks SPECjEnterprise2010 (Standard Performance Evaluation Corporation 2012b). SPECjEnterprise2010 erlaubt das messen der Performanz von auf Java EE 5 (Oracle Corporation o.j.-a) basierenden Applikations-Servern und der zugrundeliegenden Hardware. Der Workload modelliert ein betriebliches Umfeld aus der Automobilindustrie (vgl. Abbildung 2). Dazu gehören die Prozesse Bestellung, Herstellung und Lieferung. Die Unternehmensanwendung des Benchmarks beinhaltet eine Auftragsdomäne (Bearbeitung der Aufträge von Verkäufern; Orders Domain ), eine Herstellungsdomäne (Emulation von Automobilproduktion; Manufacturing Domain ) und eine Versorgungsdomäne (Bestellung von Einzelteilen von externen Zulieferern; Supplier Domain ). Die Unternehmensanwendung besteht aus einem Applikationsserver (umfasst die Anwendungsdomänen) und einem Datenbankserver ( Database Server ). Der Applikationsserver stellt die Anwendungsdienste bereit und ist für die Kontrolle der Transaktionen verantwortlich. Der Datenbankserver hat lediglich die Aufgabe des Datenmanagements inne. Diese beiden Server zusammen ergeben das Testsystem ( System Under Test ). Der Workload wird durch den Lasttreiber ( Benchmark Driver ) ausgeführt. Der Lasttreiber simuliert Domänen-bezogene Anwender, die über Schnittstellen die Unternehmensanwendung ansteuern. Bezüglich der Auftragsdomäne kommunizieren die simulierten Anwender mittels einer Webschnittstelle mit der Unternehmensanwendung. Sowohl in der Herstellungsdomäne als auch in der Versorgungsdomäne werden Web Services, als Enterprise Java Beans realisiert, angesteuert. Die Stärke des Workloads wird durch den Scale Faktor bestimmt. Der Scale Faktor bezeichnet die Anzahl der simulierten Anwender, wobei der Wert des Scale Faktors der Anzahl der simulierten Anwender dividiert durch zehn entspricht. 7

17 Abbildung 2: Architektur von SPECjEnterprise2010 Quelle: (Standard Performance Evaluation Corporation 2012c) 2.4 Performanz-Metriken Benchmarks vergleichen die Performanz von Systemen. Um diese Vergleichbarkeit zu ermöglichen, bedarf es der Quantifizierung der Performanz. Dazu messen Benchmarks bestimmte Eigenschaften der zu untersuchenden Systeme und aggregieren verschiedenartige Messwerte zu einheitlichen und vergleichbaren Werten. Solche Vergleichswerte, auf deren Basis verschiedene Systeme miteinander verglichen werden können, nennt man Performanz- Metriken. Performanz-Metriken müssen bestimmte Eigenschaften besitzen, damit ein Vergleich zwischen unterschiedlichen Systemen möglich ist. Nach Lilja (2000) müssen gute Performanz-Metriken folgende Eigenschaften besitzen: 1. Linearität: Mit der Veränderung des Wertes der Metrik um ein bestimmtes Verhältnis, sollte sich die Performanz des Systems um dasselbe Verhältnis verändern. 2. Verlässlichkeit: Eine Metrik ist dann verlässlich, wenn ein System A, dass anhand der Messergebnisse für diese Metrik ein anderes System B zu übertreffen scheint, in Bezug auf diese Metrik, System B immer übertrifft. 8

18 3. Wiederholbarkeit: Ein Messwert der Metrik muss jedes Mal dann gemessen werden können, wenn das Experiment unter den identischen Bedingungen wiederholt wird. Dies impliziert ebenfalls, dass eine gute Metrik deterministisch ist. 4. Leichtigkeit der Messung: Eine Metrik muss einfach zu messen sein, da sie sonst entweder nicht verwendet wird oder die Anfälligkeit für Fehlermessungen zu groß sind, als dass sie verwertbare Vergleiche ermöglicht. 5. Konsistenz: Eine Metrik gilt als konsistent, wenn ihre Einheit und ihre genaue Definition über mehrere Ausführungen und Konfigurationen desselben Systems identisch sind. 6. Unabhängigkeit: Ist eine Metrik unabhängig von äußerlichen Einflüssen von Herstellern (z.b. Absicht eines Herstellers zur Optimierung eines Produktes um lediglich eine bestimmte Metrik zu verbessern), gilt diese Metrik als unabhängig. Bekannte Performanz-Metriken sind Antwortzeit (Zeit von dem Auslösen einer Anfrage an ein System durch einen Anwender bis zum Erhalt einer Antwort von dem System), Durchsatz (Anzahl an Aufgaben bzw. Operationen, die ein System pro Zeiteinheit erledigt bzw. ausgeführt hat), Bandbreite (Anzahl an Bits, die in einem Netzwerk pro Sekunde übertragen werden können) und Effizienz (geleistete Arbeit pro Zeiteinheit). Performanz-Metrik Hardwareauslastung In dieser Arbeit findet die Performanz-Metrik Auslastung von Hardwarekomponenten (insbesondere die von IT-Ressourcen) Verwendung. Diese Performanz-Metrik gibt prozentual zu einem bestimmten Zeitpunkt den Anteil der Belastung von der maximal möglichen Belastung einer Hardwarekomponente an. Die Belastung bezieht sich z.b. bei der CPU auf die Anzahl an Rechenoperationen, bei dem Arbeitsspeicher auf die Größe des verwendeten Speichers und bei der Festplatte auf die Anzahl an Lese- und Schreiboperationen. Diese Auslastung lässt sich auf verschiedene Arten ermitteln. Zum einen lassen sich die Auslastungen verschiedener Hardwarekomponenten durch das Betriebssystem ermitteln. Das Betriebssystem ermittelt anhand von Algorithmen die Auslastung der einzelnen Hardwarekomponenten und ermöglicht es diese Daten abzuspeichern. Neben der Möglichkeit die Hardwareauslastung offline zu ermitteln (Auslesen archivierter Daten über die Hardwareauslastung; z.b. mittels Microsoft Windows' Leistungsüberwachungs-Tool perfmon.exe (Microsoft Corporation o.j.) bzw. Linux-Befehl sar (Godard o.j.)), ist es möglich diese online zu ermitteln (Ermittlung der Hardwareauslastung zum aktuellen Zeitpunkt). Gemäß den Eigenschaften von geeigneten Performanz-Metriken nach Lilja (2000), ergibt sich, dass sich die Metrik Hardwareauslastung durch Software als eine geeignete Performanz- Metrik erweist. Mit dem Anstieg der Auslastung von IT-Ressourcen steigt bis zu einem gewissen Schwellwert ebenfalls die Performanz des Systems (Linearität). Unabhängig von der zugrundeliegenden Hardware, belastet eine CPU-lastige Software stets die CPU am stärksten (Verlässlichkeit). Wie bereits erwähnt ist es selbst auf verschiedenen Betriebssystemen auf verschiedenen Arten möglich, die Auslastung der Hardware zu ermitteln (Leichtigkeit der Messung). Jede IT-Ressourcen-bezogene Art der Auslastung ist identisch definiert (Konsistenz). Da die Belastung von Hardware durch die ausgeführte Software initiiert wird (Mehta et al. 1997), ist die Hardwareauslastung irrelevant für die Wettbewerbsfähigkeit eines Hardware- Produktes (Unabhängigkeit). 9

19 2.5 Energie-Metriken Eine weitere Art von Metriken, mit der sich diese Arbeit beschäftigt, sind Energie-Metriken. Insbesondere wird elektrische Energie untersucht. Elektrische Energie wird verbraucht, wenn elektronische Geräte (z.b. Hardware) Arbeit vollrichten. Wird Arbeit, die mittels einer bestimmten Menge an elektrischer Energie erbracht wurde, über einen gewissen Zeitraum gemessen, so wurde eine bestimmte Leistung erbracht: Formel 1: Leistung Quelle: Eigene Darstellung Leistung Arbeit eit Die Einheiten für Arbeit bzw. für Zeit sind als Joule (J) bzw. als Sekunden (s) definiert. Die Einheit für Leistung lautet Watt (W) bzw. ist als J/s definiert. Strom, aus dem elektrische Energie (als J definiert) bezogen wird, ist ebenfalls als W definiert und liefert 1 J elektrische Energie pro s. Hardwarekomponenten haben eine bestimme Betriebsleistung. Diese ändert sich je nach Intensität der Auslastung. So verbraucht Hardware im ungenutzten, aber aktiven Zustand (Ruhezustand) weniger elektrische Energie, da eine geringere Betriebsleistung von Nöten ist, um diesen Zustand aufrechtzuerhalten. Steigt die Auslastung, nimmt ebenfalls die Betriebsspannung zu und somit der Energieverbrauch, da in dem gleichen Zeitraum mehr Arbeit vollrichtet werden muss. Hier spielt die Energieeffizienz der Hardware eine Rolle. Je energieeffizienter eine Hardwarekomponente ist, desto mehr Arbeit kann bzw. weniger Energie wird in der gleichen Zeit von der Hardwarekomponente geleistet bzw. verbraucht. Mit einem höheren (elektrischen) Energieverbrauch, nimmt somit der Strombedarf zu, wodurch sich im Endeffekt höhere Betriebskosten durch zunehmende Stromkosten ergeben. Stromkosten ergeben sich aus dem Produkt von Stromverbrauch (kwh) und Strompreis (als Geldeinheit pro Kilowattstunden (kwh) definiert). Da 1 kwh gleichbedeutend mit J ist (vgl. Formel 2), der Verbrauch von elektrischer Energie sich somit direkt auf dem Stromverbrauch auswirkt und großes Potential in der Einsparung von Kosten in der IT existiert 3, liegt eine Betrachtung des Energieverbrauchs im Hinblick auf den Kontext der Untersuchung einer Unternehmensanwendung nahe, um auf mögliche Energiesparpotentiale von Unternehmensanwendungen aufmerksam zu machen. Energiemodell kwh Wh W s Ws Formel 2: Vergleich Kilowattstunde und Joule Quelle: eigene Berechnung Ein Energiemodell errechnet aus einer bestimmten Anzahl an Parametern einen Energiewert. Energiemodelle im Sinne dieser Arbeit sind Funktionen, die auf Basis von Hardwarebedarf 3 Vgl. Kapitel

20 den Energieverbrauch dieser Hardware berechnen. Die resultierenden Energiewerte können entweder in der Einheit Joule oder in der Einheit Watt angegeben werden. Nach Rivoire et al. (2007b) muss ein ideales Energiemodell genau (Fehlerrate von maximal 10%) sein, auf verschiedene Hardware- und Softwareumgebungen übertragbar werden können (übertragbar) und kosteneffektiv (minimale Mehrbelastung von Hardware- bzw. Softwaresystem) sein. 2.6 Korrelation Ziel dieser Arbeit ist es, herauszufinden, inwieweit sich IT-Ressourcenauslastungen auf den Energieverbrauch auswirken. Um diese Auswirkungen zu quantifizieren, werden statistische Verfahren zur Analyse der Korrelation von IT-Ressourcenauslastung und Energieverbrauch herangezogen. Korrelationskoeffizient Die Auswirkungen einer messbaren Eigenschaft (unabhängige Variable) auf eine andere Eigenschaft (abhängige Variable) lassen sich in der Statistik mittels der Korrelationsanalyse quantifizieren. Eine Metrik, die die Stärke des Zusammenhangs zwischen einer unabhängigen Variablen X und einer abhängigen Variablen Y beschreibt, ist der Korrelationskoeffizient r XY (Fahrmeir et al. 2007). Der Wertebereich des Korrelationskoeffizienten reicht von -1 bis +1. Dabei bezeichnet der Bereich von -1 bis 0 einen antiproportionalen Zusammenhang während der Bereich von 0 bis +1 einen proportionalen Zusammenhang bezeichnet. Im positiven Bereich (von 0 bis +1) gilt: je größer der Korrelationskoeffizient, desto stärker ist der Zusammenhang von unabhängiger Variable und abhängiger Variable. Gegenteiliges gilt im negativen Bereich (von -1 bis 0): der Zusammenhang von unabhängiger Variable und abhängiger Variable ist größer, je kleiner der Korrelationskoeffizient ist. Sie Stärke der Korrelation lässt sich in die drei Kategorien einordnen. schwache Korrelation : r XY < 0,5, mittlere Korrelation : 0,5 r XY < 0,8 und starke Korrelation : 0,8 r XY Einfache lineare Regression Bei einem großen Korrelationskoeffizienten (unabhängig vom Vorzeichen), liegt es nahe, dass die unabhängige Variable X die abhängige Variable Y zu beeinflussen scheint. Solch ein Zusammenhang lässt sich im Idealfall (keine Streuung der Messwerte) mathematisch durch eine Funktion der Form Y = f (X) beschreiben. Um auftretende Streuungen zu berücksichtigen, wird die Funktion um einen Fehlerterm e ergänzt: Y = f (X) + e. Dieses Modell wird Regressionsmodell (Fahrmeir et al. 2007) genannt. Um den Zusammenhang von unabhängiger Variable X und abhängiger Variable Y linear zu beschreiben, wird die Funktion f durch α + β X ersetzt. Somit ergibt sich das (einfache) lineare Regressionsmodell wie folgt: 11

21 Y = α + β * X + e. Formel 3: Einfaches lineares Regressionsmodell Quelle: (Fahrmeir et al. 2007) Multiple lineare Regression Sind mehrere unabhängige Variablen Teil der Untersuchung auf einen möglichen Zusammenhang zu einer abhängigen Variablen, ist das einfache lineare Regressionsmodell nicht hinreichend. Um die Korrelation von n unabhängigen Variablen X i (i,, n), zu einer abhängigen Variable Y zu quantifizieren, ergänzt man die Funktion f des einfachen linearen Regressionsmodells entsprechend um n unabhängigen Variablen und erhält das multiple lineare Regressionsmodell wie folgt: α + β X + + β n X n + e. Formel 4: Multiples lineares Regressionsmodell Quelle: (Fahrmeir et al. 2007) 12

22 3 Energieverbrauch von Software Um Anhaltspunkte auf die Herangehensweise und die Durchführung des für die Korrelationsanalyse von IT-Ressourcenauslastung und Energieverbrauch einer beispielhaften Unternehmensanwendung zugrundeliegende Experiment 4 im Hinblick auf den Softwareaspekt zu erhalten (FF1), wurde ein Literatur-Review gemäß dem Modell nach Webster/Watson (2002) zu dem Thema Energieverbrauch von Software durchgeführt. Anschließend wurden die Ergebnisse konzeptspezifisch kategorisiert. Die folgenden fünf Kategorien haben sich herauskristallisiert: Energieverbrauch von Systemsoftware, Energieverbrauch spezifischer Anwendungen, Energieverbrauch von Software in eingebetteten Systemen und Ermittlung des Energieverbrauchs von Software. Im Folgenden werden wichtige Forschungsergebnisse der angesprochenen Kategorien dargestellt. Abschließend erfolgt eine Zusammenfassung inklusive einer Diskussion über mögliche Forschungslücken. 3.1 Energieverbrauch von Systemsoftware Strom- und Energieverbrauch durch Virtualisierung Ziming/Song (2011) untersuchen die Auswirkungen von dem Virtualisieren einer Anwendung (Ausführen einer Anwendung in einer virtuellen Maschine) auf den Energieverbrauch. Dazu führen sie verschiedene Benchmarks bei unterschiedlichem Virtualisierungsgrad (Aufteilung der Anwendung auf 1, 2 oder 4 virtuelle Maschinen) auf einer Serverumgebung bestehend aus 64 Servern aus. Die getesteten Anwendungen sind zum einen die NAS Benchmark Suite (NASA Advanced Supercomputing Division o.j.), die mehrere sog. Microbenchmarks (primitive Rechenoperationen) beinhaltet, mit denen die isolierte Auslastung bestimmter Hardwarekomponenten (z.b. CPU, Arbeitsspeicher) möglich ist und zum anderen der IOzone Benchmark (Norcott 2006), der für die Auslastung von Festplatten entwickelt wurde. Der Unterschied zwischen Virtualisierung und direktem Betrieb ist sowohl in Hinsicht auf den Energie- als auch auf den Stromverbrauch sehr gering: 5,5% bzw. 2% Mehrverbrauch als ohne Virtualisierung. Bei niedriger CPU-Frequenz (1,2 GHz) steigt bei höherem Virtualisierungsgrad der Stromverbrauch linear an, wohingegen bei steigender CPU-Frequenz ein erhöhter Virtualisierungsgrad eine exponentielle Wirkung auf den Stromverbrauch hat. Das Erhöhen der Frequenz des Arbeitsspeichers hat keine nennenswerten Auswirkungen auf den Stromverbrauch und ein höherer Grad an Virtualisierung führt beim Arbeitsspeicher zu einem exponentiellen Abfall des Energieverbrauchs. Ein erhöhter Virtualisierungsgrad führt beim IOzone Benchmark dazu, dass die Dauer der Abarbeitung der Operationen anwächst und somit die Festplatten durch längere Aktivzeiten mehr Strom verbrauchen. 4 Vgl. Kapitel 5 13

23 Die zugrundeliegende Hardware ist eine Unternehmenstypische Hardwareumgebung. Sie besteht aus mehreren Servern mit leistungsstarken Hardwarekomponenten. Obwohl die Virtualisierung von Unternehmensanwendungen in Datencentern genutzt wird, sind die verwendeten Benchmarks keine typischen Unternehmensanwendungen. Energieverbrauch von Datenbankoperationen Tsirogiannis et al. (2010) untersuchen die Auswirkungen von unterschiedlichen Datenbankoperationen eines Datenbankmanagementsystems. Die verwendete Software sind eigens entwickelte Microbenchmarks, die mittels gleichartiger Datenbankoperationen (z.b. Join, Scan oder Sortieren) entweder die Festplatten oder die CPU auslasten. Die zugrundeliegende Hardware ist ein leistungsstarker Server. Der Stromverbrauch variiert zwischen den verwendeten Datenbankoperationen bis zu 60%. Abbildung 3 zeigt den CPU-bezogenen Stromverbrauch unterschiedlicher Datenbankoperatoren mit Performanz-orientierter CPU-Konfiguration (Abbildung 3 (a)) und energieeffizienter CPU-Konfiguration (Abbildung 3 (b)). Hieraus wird ersichtlich, dass trotz energieeffizienter CPU-Konfiguration, CPU-intensive Operationen ( RowScan, Hashjoin ) tendenziell einen höheren Stromverbrauch der CPU verursachen können als weniger CPU-intensive Operationen. Abbildung 3: Vergleich des CPU-bezogenen Stromverbrauchs von Datenbankoperatoren Quelle: (Tsirogiannis et al. 2010, 232) Energie- und Performanzmessung eines Dateikompressionsalgorithmus Li et al. (2011) untersuchen verschiedene Dateikompressionsalgorithmen auf ihren Energieverbrauch und ihre Performanz auf Systemebene. Die verschiedenen Testparameter umfassen die Art des Kompressionsalgorithmus, das Kompressionslevel, den Dateityp, das Speichermedium und den Festplatten-Scheduler. Die zugrundeliegende Hardware ist ein leistungsstarker Server. 14

24 Der Workload besteht darin 20 identische, 65 Megabyte große Dateien mit 20 nebenläufigen Threads zu komprimieren und anschließend die komprimierten Dateien auf die Festplatte zu schreiben. Die Analyse ergab, dass sowohl der Energieverbrauch und die Dauer des jeweiligen Tests bezüglich der Kompressionsrate eine nicht-lineare Beziehung eingehen. Zudem zeigt sich auf verschiedenen Speichermedien bei unterschiedlichen Kompressionsalgorithmen ein mit der Zeit stark variierender Stromverbrauch. Bei unterschiedlichen Kompressionslevels schwankt der Stromverbrauch ebenfalls während der Kompression, da die Lesezugriffe mit den Schreibzugriffen konkurrieren. Durch eine Erhöhung der Taktrate steigt bei gleichbleibendem Kompressionslevel tendenziell der Energieverbrauch. Der Grund hierfür ist, dass die CPU mit einer geringeren Taktrate mehr Zeit braucht, um die Kompression abzuschließen. Neben der Dimension Taktrate der CPU, gelten für die übrigen Konfigurationsdimensionen (Festplatten- Scheduler, Festplattentyp, Dateityp) ebenfalls komplexe Eigenschaften hinsichtlich des Stromverbrauchs. So bringt eine Änderung des Festplattentyps bzw. Dateityps bzw. Festplatten-Schedulertyp ein sich stark unterscheidendes und nicht verallgemeinerndes Verhalten des Stromverbrauchs mit sich als bei einem anderen Festplattentyp bzw. Dateityp bzw. Festplatten-Schedulertyp. Energieeffizienz von Management Informationssystemen Capra et al. (2012) untersuchen die Energieeffizienz von verschiedenen Management Informationssystemen. Untersucht wurden zwei ERP (Enterprise Resource Planning) Systeme, zwei CRM (Customer Relationship Management) Systeme und vier Datenbanksysteme auf zwei verschiedenen Betriebssystemen (Linux CentOS und Microsoft Windows). Die Architektur der untersuchten Workloads war der eines Unternehmens nachgestellt: Clients generieren Anfragen und Server bearbeiteten diese Anfragen (Client-Server-Architektur). Gemäß Capra et al. (2012) gibt es signifikante Unterschiede in den Energieverbräuchen innerhalb von Applikationen derselben Kategorie. Ebenfalls laufen die gleichen Applikationen unter Linux energiesparender als unter Microsoft Windows. Der größte Energieverbraucher unter den IT-Ressourcen ist die CPU. Anwendungen, die weniger Festplattenzugriffe ausüben und dafür mehr Daten in den Arbeitsspeicher laden und dort verwalten, können den Energieverbrauch der Anwendung messbar senken. Die untersuchte Hardware sind leistungsstarke Server. Sowohl die zugrundeliegende Hardware als auch die ausgeführten Anwendungen sind somit typisch für ein Unternehmensumfeld. Metrik Energieeffizienz von Software Johann et al. (2012) untersuchen zwei Sortieralgorithmen und eine Unternehmensanwendung auf ihre Energieeffizienz, da nicht nur Hardware, sondern auch Software energieeffizient konstruiert sein sollte. Sie definieren die Metrik Energieeffizienz als Quotient aus erbrachter nützlicher Arbeit und dafür verbrauchter Energie. Dabei spielt es keine Rolle, ob die erbrachte nützliche Arbeit im Zähler oder im Nenner steht, solange die Definition für die gleiche Testreihe einheitlich gehalten wird. 15

25 Johann et al. (2012) greifen dabei auf White-Box-Tests zurück. Ihrer Meinung nach sollte man auf White-Box-Tests (Code Instrumentation) zur Ermittlung des Energieverbrauchs von Software zurückgreifen, da z.b. Benchmarks (Black-Box-Test) lediglich für bestimmte Einsatzgebiete (z.b. Datenbank-Benchmarks fokussieren auf die Auslastung von Festplatten, da sie mehr Lese- und Schreibzugriffe auf Festplatten ausführen als Berechnungsbenchmarks) zweckmäßig sind. Somit sind Black-Box Verfahren für die Instrumentierung von Software nicht geeignet, da sie grundlegende Einblicke in die Struktur von Software verweigern und somit konkrete Stellen zur Energieoptimierung nicht beleuchten. Ihre Instrumentierung der Software wird über Intels API Intel Energy Checker Software Development Kit (Intel Corporation 2010) durchgeführt. Die untersuchten Sortieralgorithmen sind Bubble Sort mit einer Komplexität von O (n 2 ) und Heap Sort mit einer Komplexität von O (n * log (n)). Bezüglich der Metrik Energieeffizienz ist die erbrachte nützliche Arbeit gleich der Anzahl an sortierten Elementen. In der Testumgebung hat Bubble Sort eine Energieeffizienz von 18 sortierten Elementen je Joule und Heap Sort eine Energieeffizienz von 27,3 sortierten Elementen je Joule. Der Algorithmus mit der besseren Performanz hat die bessere Energie-Effizienz. Die dritte untersuchte Anwendung ist eine Unternehmensanwendung. Ihre Architektur ist eine drei-schichten-architektur bestehend aus einem Web Browser (Client), Web Server und einem Datenbankserver. Die Unternehmensanwendung sammelt Daten über verbrauchswerte von z.b. Strom und Wasser und ermöglicht es, diese Daten grafisch in Form von Graphen zu visualisieren. Für jede Anfrage eines Anwenders wird ein solcher Graph erstellt, über das Netzwerk transferiert und schließlich dem Anwender angezeigt. Bezüglich der Metrik Energieeffizienz bezeichnet die erbrachte nützliche Arbeit das Erstellen eines Graphen. Energieeffizienz ist für diesen Testzweck definiert als verbrauchte Energie (Joule) je erstellter Graph. Bei 15 gleichzeitig simulierten Anwendern wurden je erstelltem Graph 7,3 Joule Energie bei einer Antwortzeit von 0,5 Sekunden verbraucht. Wurden hingegen 25 Anwender simuliert, sank der Energieverbrauch pro erstellten Graphen auf 5,5 Joule, jedoch stieg die Antwortzeit auf 0,8 Sekunden. Dieses Verhalten im zweiten Testlauf (25 simulierte Anwender) lässt sich dadurch erklären, dass die Unternehmensanwendung über ihre Performanz-Grenzen hinaus gefordert ist, da maximal 17 simulierte Anwender gleichzeitig von der Unternehmensanwendung bedient werden können. Somit ist es notwendig bei dem Einsatz einer Unternehmensanwendung neben der Performanz (z.b. Antwortzeit) des Systems ebenfalls die Energieeffizienz zu berücksichtigen und zwischen diesen Metriken abzuwägen, da der Untersuchung nach zu urteilen einen gleichzeitiges Erreichen beider Metriken nicht problemlos möglich ist. Energiecharakterisierung und -ermittlung von Betriebssystemen Li/John (2003) untersuchen ein Betriebssystem auf seine Energieverteilung und erstellen ein Modell zur Ermittlung des Energieverbrauchs von Betriebssystemen. Mittels SoftWatt (Gurumurthi et al. 2002) wird eine Mikroarchitektur, bestehend aus einem Mikroprozessor inklusive Speicherhierarchie und einer Festplatte, simuliert. SoftWatt simuliert das Betriebssystem SGI IRIX

26 Die Analyse ergab, dass es einen großen Unterschied beim Stromverbrauch von den verschiedenen Services eines Betriebssystems gibt. Jeder Service erfordert eine spezifische Abwicklung der Instruktionen durch die unterschiedlichen Hardwarekomponenten der CPU, wodurch eine für jeden Service des Betriebssystems charakteristische Aktivität in der CPU herrscht, die sich wiederum von Service zu Service unterscheiden kann. In Abbildung 4 werden der durchschnittliche Stromverbrauch und die prozentuale durchschnittliche Variation des Stromverbrauchs von Betriebssystem-Services dargestellt. Services, die primär auf die Speicherhierarchie zugreifen (z.b. vfault, COW_fault, demand_zero, cacheflush), verbrauchen mehr Strom als solche Services, die primär Berechnungen erfordern (z.b. utlb, clock). Manche Ein-/Ausgabe-Interrupts (z.b. simscsi_intr, if_etintr), Prozess-Scheduling-Services (z.b. getcontext) und Lese-/Schreibzugriffe auf Dateien (z.b. fcntl, lseek, getdents) weisen eine höhere Variation im Stromverbrauch auf, da sie stark vom Systemstatus abhängen. Betriebssystem- Services wie z.b. utlb, utssys und cacheflush leisten bei jedem Aufruf die gleiche Arbeit und haben deswegen eine vernachlässigbare Variation im Stromverbrauch. Abbildung 4: Durchschnitt und Variation des Stromverbrauchs von verschiedenen Betriebssystem-Services Quelle: (Li/John 2003, 164) Eine Analyse von unterschiedlichen Benchmark Suites ergab, dass für unterschiedliche Workloads unterschiedliche Services des Betriebssystems aufgerufen wurden. Somit haben unterschiedliche Anwendungen zum einen unterschiedliche Auswirkungen auf das Verhalten des Betriebssystems und zum anderen einen unterschiedlich starken Stromverbrauch durch das Betriebssystem als Folge ihrer Ausführung. Eine Analyse von Stromverbrauch und den verschiedenen Services eines Betriebssystems ergab, dass der Stromverbrauch stark mit der Performanz korreliert. Diese Erkenntnis wird zur Erstellung des Modells zur Ermittlung des Stromverbrauchs verwendet. Das zur Ermittlung der Stromverbräuche der verschiedenen Betriebssystem-Services verwendete Energiemodell basiert auf der Metrik IPT (Instruktionen pro Takt). Der Stromverbrauch P i eines Betriebssystem-Services i ergibt sich demnach aus dem linearen Regressions- 17

27 modell i α i T i + β i, wobei und Modellparameter und die IPT eines Betriebssystem-Services i sind. Der Gesamtenergieverbrauch E OS eines Betriebssystems OS ergibt sich wie folgt. E OS i ( i T i ), wobei die Dauer der Ausführung des Betriebssystem-Services i ist. Die Fehlerrate des Energiemodells liegt unter zehn Prozent. Wird hingegen die IPT als Durchschnitt aller Betriebssystem-Services verwendet, da z.b. eine genauere Messung einzelner Betriebssystem-Services nicht möglich ist, liegt die Fehlerrate des Energiemodells im Fehlerbereich von 20%-50%. 3.2 Anwendungsspezifischer Energieverbrauch Energiebewusster Benchmark Rivoire et al. (2007a) haben einen energiebewussten Sortierungsbenchmark (JouleSort) entwickelt, um die Energieeffektivität von einheitlichen Systemen abzuschätzen, damit Verbesserungen im Energieverbrauch kontrollierter durchgeführt werden können. JouleSort ist ein Eingabe-/Ausgabe-orientierter, auf Systemebene ansetzender, energieeffizienter Benchmark, der Performanz, Strom- und gewisse Kühlungskosten berücksichtigt. Stromwerte werden dabei über externe Messgeräte ausgelesen. JouleSort ermöglicht neben ganzen Systemen, auch einzelne Komponenten auf Energieeffizienz miteinander zu vergleichen. Da der Workload von JouleSort auf einem Sortieralgorithmus basiert, ermöglicht JouleSort den Vergleich von unterschiedlichen Sortieralgorithmen auf ihre Energieeffizienz. Um die Energieeffektivität von einheitlichen Systemen abschätzen zu können, muss ein Benchmark bestimmte Eigenschaften haben. So muss der Benchmark nicht nur den Kompromiss zwischen Strom und Performanz (in die Benchmark Bewertung müssen sowohl Performanz als auch Stromverbrauch gemeinsam eingehen) und das Maximum der Energieeffizienz des Systems evaluieren, sondern auch ausgeglichen (möglichst viele vorhandene und verschiedene Hardwarekomponenten (z.b. CPU, Festplatten und Arbeitsspeicher) des Systems sollen gleichermaßen ausgelastet werden) und inklusiv (viele Systemkonfigurationen unterstützend) sein. JouleSort ermittelt den Stromverbrauch bei maximaler Auslastung, da, der Stromverbrauch der zugrundeliegenden Hardware schwieriger einzuschätzen ist, als im Ruhezustand. Der Workload besteht aus dem Sortieren einer Datei mit zufällig vertauschten 100-Byte Einträgen mit 10-Byte Schlüsseln. Das Ergebnis wird zur zeitbezogenen Vergleichbarkeit in einer neuen Datei gespeichert. Der Vergleichswert eines Benchmark-Laufes von JouleSort wird in der Performanz-Metrik sortierte Einträge pro Joule gemessen. Dabei gilt: je energieeffizienter das System, desto größer ist diese Performanz-Metrik. Der Energieverbrauch von JouleSort wurde bei unterschiedlichen Softwarekonfigurationen (unterschiedliches Betriebssystem und unterschiedlicher Sortierungsalgorithmus) untersucht. Die Tests ergaben, dass eine CPU-orientierte Sortierungskonfiguration am energieeffizientesten ist, da der Stromverbrauch von Eingabe-/Ausgabe-orientierten (z.b. Festplatte) Sortieralgorithmen größer ist, als der von CPU-orientierten Sortieralgorithmen. 18

28 Benchmark zur Evaluierung der Performanz und des Stromverbrauchs von Hardware SPECpower_ssj2008 (Standard Performance Evaluation Corporation 2013) ist ein Benchmark, der es ermöglicht, die Stromverbrauchs- und Performanz-Charakteristiken einzelner Server oder mehrerer Computern in einem Netzwerk zu evaluieren. SPECpower_ssj2008 ermöglicht das Messen des Stromverbrauchs in Verbindung mit der Performanz-Metrik Performanz/Stromverbrauch. Die Performanz des zu testenden Systems ist gleich der Anzahl an ssj_ops. Ssj_ops ist definiert als die Anzahl an Operationen, die in einem Messzeitraum durchgeführt wurden, dividiert durch die Dauer des Messzeitraumes. Abbildung 5 zeigt die Architektur von SPECpower_ssj2008. SPECpower_ssj2008 besteht aus einem Controller, der das Control and Collection System (CCS) und zwei PTDaemons, die Informationen über Stromverbrauch und Temperatur sammeln, verwaltet, einem Stromverbrauchssensor ( PowerAnalyzer ), einem Temperatur Sensor und einem Workload. Das CCS bzw. die PTDaemons kommunizieren über TCP/IP-Verbindung mit dem Workload bzw. mit den Sensoren (Strom- und Temperatursensor). Der Temperatursensor wird im Testsystem und der Stromsensor zwischen Stromquelle und Testsystem installiert. Der Workload besteht aus einer der Java Anwendung, aus dem Director, der für die Koordination der ausgeführten Instanzen und für die Kommunikation mit dem CCS verantwortlich ist, dem Validator, der die Konfiguration und Ergebnisse des Testlaufes gemäß bestimmter Regeln validiert und dem Reporter, der aus den Ergebnissen des Testlaufes Reports erstellen kann. Abbildung 5: Architektur von SPECpower_ssj2008 Quelle: (Standard Performance Evaluation Corporation 2012a, 5) Zum Workload gehört eine Java Anwendung, welche eine Zusammenstellung von verschiedenen Operationen auf dem Testsystem ausführt. Die Anwendung lastet alle IT-Ressourcen gleichmäßig aus. Das Testsystem wird mittels dieser Anwendung in 10%-Schritten von 0% bis 100% ausgelastet, dabei kann die Java Anwendung in mehreren Instanzen ausgeführt werden. Vor Beginn eines Testlaufes, kalkuliert die Java Anwendung die maximal mögliche An- 19

29 zahl an Operationen, die das Testsystem ausführen kann. Auf dieser Grundlage, werden anschließend die 10%-Auslastungsschritte errechnet. Studie der Energieeffizienz des SPECjEnterprise2010 Benchmarks Oi/Niboshi (2013) haben den SPECjEnterprise2010 Benchmark hinsichtlich seiner Energieeffizienz auf unterschiedlichen Applikationsservern untersucht. Es wurden die verschiedenen Transaktionstypen des Benchmarks hinsichtlich ihres Energieverbrauchs unter variiertem Scale Faktor analysiert. Der Scale Faktor bestimmt die Stärke des Workloads des Benchmarks. Die zugrundeliegende Hardware sind zwei Laptops, von denen einer mit einer AMD Phenom und der andere mit einer Intel Atom CPU ausgestattet ist. Die verschiedenen Transaktionsarten des SPECjEnterprise2010 Benchmarks zeigen auf den getesteten Servern hinsichtlich des Energieverbrauchs eine unterschiedliche Energieeffizienz. Der Atom rozessor ist energieeffizienter, wenn er Manage -Transaktionen ausführt, wohingegen der Phenom rozessor energieeffizienter ist, wenn er CreateVehicleWS - Transaktionen ausführt. Somit lautet ein Fazit, dass Applikationsserver am effizientesten unterschiedliche Software-Operationen ausführen können, wenn unterschiedliche Prozessoren in ihnen verbaut sind, da bestimmte CPUs für manche Transaktionstypen besser geeignet sind als andere CPUs. Dies zeigt außerdem, dass ein Vergleich von Software auf verschiedenen Hardwarekonfigurationen nur bedingt möglich ist. Ein weiterer Aspekt der Arbeit ist eine Untersuchung von Dynamic Frequency Scaling (DFS) auf die CPU-Auslastung der Applikationsserver, da die AMD Phenom CPU DFS unterstützt. Ergebnis dieser Untersuchung ist, dass die Standardeinstellung von DFS zwar für die verschiedenen Situationen (Hardwarekonfiguration und Art der durchgeführten Operationen durch Software) grundlegend messbares Energiesparpotential besitzt, jedoch eine spezifische Anpassung der Standardparameter wie Sampling Rate und Threshold speziell auf die jeweilige Situation mehr Energiesparpotential mit sich bringen kann. Stromverbrauch verschiedener Einzelanwender-Anwendungen Mahesri/Vardhan (2005) untersuchen verschiedene Einzelanwender-Anwendungen auf ihren Stromverbrauch hin auf einem Laptop. Untersuchte Anwendungen sind der PCMark2002 und der 3DMark2001 Benchmark. PCMark2002 ist ein Benchmark, der IT-Ressourcen gemäß der typischen Nutzung eines Anwenders auslastet. 3DMark2001 ist ein Benchmark, der vorzugsweise die GPU und die CPU auslastet. Weitere Workloads sind das Abspielen einer Audio-CD und das Versenden von Daten mittels dem FTP (File Transfer Protocol). Das Abspielen einer Audio-CD beansprucht vor allem die Festplatte. Das Versenden von Daten mittels FTP dient der Auslastung von Netzwerkkarte und Festplatte. Untersuchte Hardwarekomponenten sind die CPU, die GPU, der Arbeitsspeicher, die Festplatte, der Bildschirm, die Netzwerkkarte und das Netzteil. Der Stromverbrauch wurde für jede einzelne Hardwarekomponenten gemessen. Hardwarekomponenten wie Festplatte oder Bildschirm, bei denen eine direkte Messung möglich ist, werden mittels externen Messgeräten versehen. Bei integrierten Hardwarekomponenten wie die CPU oder der Arbeitsspeicher werden spezielle hardwarekomponentenbezogenen Benchmarks ausgeführt und der resultierende Stromverbrauch von dem Stromverbrauch des Laptops im Ruhezustand abgezogen, sodass der Stromverbrauch jeder Hardwarekomponente feststeht. Auswirkungen von unterschiedlichen 20

30 Hardwarekonfigurationen wie die Energiesparfunktion DVS (Dyamic Voltage Scaling) der CPU und verschiedene Helligkeitsstufen des Bildschirms wurden ebenfalls untersucht. Ergebnis der Analyse (vgl. Abbildung 6) ist, dass diejenigen Workloads (PCMark, 3DMark), die vor allem die CPU auslasten, am meisten Strom verbrauchen. Wird die Festplatte ausgelastet (Abspielen der Audio-CD), steigt der Stromverbrauch ebenfalls signifikant an. Der Stromverbrauch variiert sehr stark abhängig von der verwendeten Anwendung. In der Untersuchung stieg der Stromverbrauch durch eine der verwendeten Anwendungen gegenüber dem Stromverbrauch im Ruhezustand um 8 W bis 30 W an. Eine weitere Erkenntnis war, dass im Ruhezustand der Stromverbrauch unter Verwendung des Betriebssystems Microsoft Windows höher ist als unter Linux. Abbildung 6: Stromverbrauch eines Laptops unter verschiedenen Workloads Quelle: (Mahesri/Vardhan 2005, 5) Energieverbrauch von Anwendungen in Cloud Computing Systemen Chen et al. (2013) untersuchen Cloud Computing Systeme auf ihren Stromverbrauch. Das Modell basiert dabei auf drei Arten von Arbeiten, die in einem Cloud Computing System durchgeführt werden: rechen-, datenverarbeitungs- und kommunikationsintensive Arbeiten. Testparameter sind die Anzahl an Prozessen, die abzuarbeitende Dateigröße, die zu versendende Dateigröße und der Workload für die jeweilige Arbeit. Die ausgeführte Software wird in virtuellen Maschinen ausgeführt. Die zugrundeliegende Hardware ist ein Datencenter bestehend aus mehreren leistungsstarken Servern. Als Workload für rechenintensive Arbeiten wurde ein Tool implementiert, dass Fibonacci Zahlen errechnet. Die Workload-Größe hängt dabei von der größten Fibonacci Zahl der Fibonacci Sequenz ab. Die Berechnung wurde dabei auf mehrere Rechenkerne aufgeteilt, um eine möglichst hohe Auslastung der CPU zu erreichen. Der Workload der datenverarbeitungsintensiven Arbeiten besteht aus dem Ausführen einer gewissen Anzahl eines Benchmark Durchlaufes (bestehend aus jeweils 50% Schreib- und Leseoperationen auf Dateien der Festplatte). Betrachtete Parameter für datenverarbeitungsintensive Arbeiten sind einerseits die Dateigröße 21

31 der zu verarbeitenden Datei, die Datensatzgröße, die Anzahl der Benchmark Durchläufe und die Anzahl der Prozesse pro Benchmark Durchlauf. Bei kommunikationsintensiven Arbeiten besteht der Workload darin, dass eine verteilte (Web- und Datenbankserver) Java Web Applikation Benutzeranfragen abarbeitet, die von dem Web-Server an den Datenbankserver verschickt, die Anfragen auf dem Datenbankserver abgearbeitet und die Ergebnisse an den Web- Server zurückgesendet werden. Ergebnisse der Analyse von rechenintensiven Arbeiten ergaben, dass bei konstant vier virtuellen Maschinen, auf die die Last aufgeteilt wurde, und konstanter Anzahl an Arbeiten ein Anstieg des Stromverbrauchs der Server mit höherer CPU-Auslastung erfolgte. Mit Aktivierung von mehr Rechenkernen sank einerseits der Energieverbrauch und andererseits stieg der Datendurchsatz an. Bei konstanter Workload-Größe stieg der Energieverbrauch sowohl mit zunehmender Anzahl an Arbeiten als auch mit zunehmender Anzahl an virtuellen Maschinen. Der Datendurchsatz ist bei einer virtuellen Maschine am geringsten, bei zwei und drei in etwa auf dem gleichen Level, jedoch signifikant höher als bei lediglich einer virtuellen Maschine. Bei den datenverarbeitungsintensiven Arbeiten steigen, bei konstant bleibender Anzahl an virtuellen Maschinen, abzuarbeitenden Arbeiten und Prozessen pro Arbeit, sowohl der Stromverbrauch als auch der Energieverbrauch bei zunehmender Datensatzgröße als auch bei zunehmender Dateigröße. Unabhängig von der Datensatzgröße sinkt der Datendurchsatz bei zunehmender Dateigröße. Werden lediglich die Anzahl der virtuellen Maschinen und die Datensatzgröße verändert, ist eine Abnahme des Energieverbrauchs sowohl bei zunehmender Anzahl an virtuellen Maschinen als auch bei abnehmender Anzahl der Datensatzgröße zu beobachten. Der Datendurchsatz sinkt einerseits tendenziell bei Abnahme der Anzahl an virtuellen Maschinen und verhält sich andererseits sehr unterschiedlich von Datensatzgröße zu Datensatzgröße. Verändert man lediglich die Prozessanzahl je abzuarbeitender Aufgabe und die Datensatzgröße, ist ersichtlich, dass bei zunehmender Anzahl an Prozessen und bei sinkender Datensatzgröße zwar der Energieverbrauch steigt jedoch der Stromverbrauch tendenziell sinkt. Die Analyse der kommunikationsintensiven Arbeiten ergab, dass mit zunehmender Anzahl an Benutzer-Sessions und zunehmendem Datenverkehr, der Energieverbrauch pro Arbeit zunimmt. Dabei nimmt jedoch der Datendurchsatz signifikant ab. Generell steigen einerseits der Energieverbrauch einer Arbeit mit zunehmender Hardwareauslastung und andererseits die Performanz des Systems an. Herrscht jedoch ab einem gewissen Punkt eine Überallokation von Hardwarekomponenten, sinkt insgesamt die Performanz des Systems. Profilierung von Software mittels Eprof Schubert et al. (2012) haben ein Energieprofilierungs-Tool namens Eprof entwickelt, mit dessen Hilfe Entwickler energiehungrige Stellen im Softwarecode ausfindig machen können. Um Eprof einsetzen zu können, müssen weder der Softwarecode vorher instrumentiert noch externe Messgeräte und Schaltungen angebracht, sondern lediglich der Kernel um wenige Code- Zeilen ergänzt werden. 22

32 Eprof ermöglicht den Energieverbrauch von einzelnen Funktionen zu ermitteln. Eprof ermittelt das Energieprofil anhand von Stacktraces von Operationen und operationsbezogenen Energieverbräuchen. Wenn eine Operation aufgenommen wird, speichert Eprof die aktuelle Position im Softwarecode und legt einen Stacktrace angefangen bei der aufgenommenen Position im Softwarecode an. Verbrauchte Energie wird anhand der Energiemodelle der zugrundeliegenden Hardwarekomponenten auf Basis der für eine Hardwarekomponente entsprechenden Energieverbräuche der einzelnen Operationen ermittelt. Neben den synchronen Energieverbräuchen (von z.b. CPU, Arbeitsspeicher), die während der Softwarecode- Abarbeitung stattfinden, nimmt Eprof auch asynchrone Energieverbräuche auf. Asynchrone Energieverbräuche ergeben sich z.b. durch Festplatten, da z.b. ein Lesezugriff sowohl von der Festplatte selbst als auch vom Betriebssystem in eine Warteschlange gelegt werden kann und somit erst später Energie verbraucht, während bereits weiterer Code von der CPU abgearbeitet wird. Die Daten aus den StackTraces und Energie-abschätzungen ergeben schließlich das Energiemodell des getesteten Softwarecodes. Für die Energieermittlung berücksichtigt Eprof IT-Ressourcen als Hardware-bezogene Energieabschätzung. Sowohl für die CPU als auch für den Arbeitsspeicher verwendet Eprof lineare Energiemodelle. Für die Ermittlung des Energieverbrauchs der Festplatte modelliert Eprof den linearen Zusammenhang von Dauer einer Anfrage und Energieverbrauch von Festplatten. Die Energiemodelle werden mittels hardwarekomponentenbezogenen Benchmarks trainiert. Die Fehlerrate von Eprof für das CPU-bezogene Energiemodell beträgt weniger als 10%. Die durchschnittliche Mehrbelastung durch Eprof während der Laufzeit des Benchmarks SPEC CPU2006 (Standard Performance Evaluation Corporation 2011) beträgt weniger als 3%. Green Mining: Analyse von Softwareänderungen auf ihren Stromverbrauch Hindle (2012) verbindet Mining von Software Repositories und die Analyse des Stromverbrauchs von Software: Green Mining. Mittels Green Mining werden unterschiedliche Versionen einer Software miteinander verglichen und überprüft, welche Art und Stärke von Änderung des Energieverbrauchs eine neuere Software-Version hervorgerufen hat. Die generelle Methodik ist wie folgt: 1. Auswahl eines Softwareproduktes und den Kontext, in dem diese Software getestet werden soll 2. Entscheiden über den Grad der Instrumentierung und die unterschiedlichen festzuhaltenden Daten (inklusive Strommessung) 3. Auswahl eines Sets an Versionen, Snapshots oder Revisionen eines Softwareproduktes 4. Entwickeln eines Testfalls, der bei allen Versionen, Snapshots und Revisionen durchgeführt werden kann 5. Konfiguration der Testumgebung zur Ausschaltung von Einflüssen von Hintergrundprozessen 6. Für jede Version - werden der Testfall durchgeführt und die Testdaten gesammelt, - werden die Testdaten kompiliert und gespeichert und - werden sowohl die Testumgebung als auch der Test neu aufgebaut. 7. Kompilierung und Analyse der erhobenen Testdaten. 23

33 Untersucht wurden der Web Browser Mozilla Firefox (Mozilla Corporation o.j.) in den Versionen 2.0 bis 3.6 und der BitTorrent Client Vuze (Azureus Software Corporation 2013). Die zugrundeliegende Testumgebung ist ein Notebook. Im Laufe der Versionen zeigte sich bei Mozilla Firefox eine Abnahme des durchschnittlichen Stromverbrauchs. Die Variation des Stromverbrauchs hingegen stieg mit späteren Versionen an. Gleiches Ergebnis ist bei Vuze zu erkennen: mit späteren Versionen sank tendenziell der durchschnittliche Stromverbrauch, jedoch stieg die Variation des Stromverbrauchs an. Die Ergebnisse zeigen, dass eine energieeffiziente Softwareentwicklung zu einer energiesenkenden und somit kosteneffektiven Softwarenutzung führen kann. Für Vuze wurden zwei verschiedenartige Testfälle konzipiert. Der erste Testfall besteht aus dem Initialisierungs-, dem Startvorgang und dem Ruhezustand von Vuze. Der zweite Testfall besteht aus dem herunterladen einer 2GB großen Datei. Die Analyse der erhobenen Testdaten für die Vuze-Testfälle wurde durch eine Korrelationsanalyse auf Basis unterschiedlicher Metriken aus der Objekt-orientierten Programmierung durchgeführt. Diese Metriken sind Datenzugriff (Verhältnis von Anzahl an als private und protected deklarierten Variablen zur Anzahl aller deklarierten Variablen einer Klasse), Maß der Aggregation (Anzahl an Feldern in einer Klasse, die von Anwender-basierten Klassen bereitgestellt werden), Tiefe der Vererbung (einer Klasse) und Anzahl an Kindern (einer Klasse). Die Korrelation wurde mittels des Rangkorrelationsverfahrens untersucht und die Rangkorrelationskoeffizienten für die vorgestellten Metriken bezogen auf die Vuze-Testfälle deuten auf eine mittlere Korrelation zwischen jeweils einer Metrik und dem Stromverbrauch hin. 3.3 Energieverbrauch von Software in eingebetteten Systemen Energieverbrauch einer eingebetteten Java Anwendung Lafond/Lilius (2006) haben ein Modell entwickelt, um den Energieverbrauch von in einer eingebetteten Java-basierten virtuellen Maschine ausgeführtem Softwarecode zu ermitteln. Das Modell ermittelt auf Basis der Anzahl und Art von Instruktionen der JVM abhängig vom ausgeführten Softwarecode den Energieverbrauch dieses Softwarecodes. Bei der JVM handelt es sich um die Software K Virtual Machine (Oracle Corporation o.j.-b). Die zugrundeliegende Hardware (CPU, Arbeitsspeicher) besteht aus für mobile Geräte optimierten Hardwarekomponenten. Zur Ermittlung des Energieverbrauchs haben sie Lafond/Lilius (2006) unterschiedliche Softwarecodes in der virtuellen Maschine ausgeführt und dabei den Stromverbrauch und den Anteil von CPU und Arbeitsspeicher am Energieverbrauch gemessen. Bei leerem (instruktionsfreiem) Softwarecode, ist der Anteil des Arbeitsspeichers am Energieverbrauch entsprechend hoch (75%). Wird hingegen lediglich mittels einer Schleife einer bestimmten Länge eine Reihe an Objektinstanziierungen vorgenommen, sinkt der Anteil des Arbeitsspeichers am Energieverbrauch auf 70%. Bei der Ausführung von arithmetischen Operationen, bleibt die Verteilung von CPU und Arbeitsspeicher am Energieverbrauch bei 30% und respektive 70%. 24

34 Die Untersuchungen ergaben unter anderem, dass es keinen Unterschied bei der Verteilung von CPU und Arbeitsspeicher am Energieverbrauch zwischen Applikationen mit Vorherrschen der Objekt-Instanziierung und Applikationen mit überwiegend arithmetischen Operationen gibt. Jedoch ergaben die Experimente, dass Objektinstanziierungen mehr Energie verbrauchen als arithmetische Operationen. Von den verschiedenen Stationen des Lebenszyklus einer Java-basierten Applikation, verbraucht der Interpreter (unabhängig davon ob nun Arbeitsspeicherzugriffe oder Maschinencode-Instruktionen abgearbeitet werden) den größten Anteil am gesamten Energieverbrauch. Werden stets gleichartige Objekte instanziiert, steigt der Energieverbrauch des Interpreters linear und proportional mit der Schleifenlänge. Analyse des Energieverbrauchs von Software unter Android Yi-Fan et al. (2011) haben ein Tool zur Charakterisierung des Energieverbrauchs einer Anwendung unter Android, ANEPROF (Android Energy Profiler), entwickelt. Somit ist es möglich, kritische Stellen in Bezug auf den Energieverbrauch einer Anwendung zu finden. ANEPROF sammelt Anwendungs-bezogene Daten darüber, zu welchem Zeitpunkt eine bestimmte Methode dieser Anwendung aufgerufen wurde und wie lange der Methodenaufruf dauerte. Dazu werden unterschiedliche Softwareebenen durch ANEPROF instrumentiert: das Betriebssystem, die virtuelle Maschine, in der die Anwendung läuft, und das Anwendungsframework. Der Energieverbrauch wird mittels eines speziellen Messgerätes, National Instruments DAQ (National Instruments Corporation 2013), gemessen. Ein Computer dient zur Abbildung der zeitbezogenen Methodenaufrufe auf die Messergebnisse zum Energieverbrauch und zur Visualisierung der Ergebnisse. Um ANEPROF zu testen, werden die Anwendungen Gmail, Browser, YouTube und Facebook unter Android mittels ANEPROF analysiert. Die folgenden Metriken und entsprechende Einheiten in Klammern zur Beschreibung des Energieverhaltens der zu testenden Anwendung finden dabei Verwendung: EPI: Energieverbrauch pro Instruktion (mj/s) VS: Stromverbrauch, wenn Anwendung im Vordergrund (mw) HS: Stromverbrauch, wenn Anwendung im Hintergrund (mw) und BDS: Bereich für durchschnittlichen Stromverbrauch (mw). Gmail und Browser haben einen höheren EPI als Facebook und YouTube. Dies zeugt von einer geringeren Energieeffizienz von Gmail und Browser. Browser und YouTube haben einen hohen VS und einen niedrigen HS, wohingegen gegensätzliches für Facebook und Gmail gilt. Somit wird das Beenden der Anwendungen Facebook und Gmail, wenn im Hintergrund laufend, empfohlen. Analyse des Energieverbrauchs einer eingebetteten Java virtuellen Maschine Farkas et al. (2000) quantifizieren den Energie- bzw. Stromverbrauch einer eingebetteten Java-basierten virtuellen Maschine (JVM), namentlich die Kaffe JVM (Transvirtual Technologies Corporation o.j.). Die zugrundeliegende Hardware ist ein Kompakt-Computer. Die JVM wurde hinsichtlich des Energieverbrauchs unterschiedlicher Design-Konzepte für 25

35 sowohl den Startvorgang als auch die Laufzeit der JVM analysiert. Die untersuchten Design- Konzepte für den Startvorgang sind: Einzelne JVM oder mehrere JVMs: Es können mehrere Anwendungen in einer einzigen JVM oder jede Anwendung in einer separaten JVM ausgeführt werden. Standardmäßig werden unter anderem aus Sicherheitsgründen Anwendungen in separaten JVMs ausgeführt. Komprimierte oder dekomprimierte.class-dateien: Beständiger Speicher ist in mobilen Systemen begrenzt. Somit können die.class-dateien in sowohl komprimierter als auch in dekomprimierter Form beim Startvorgang zur Verfügung stehen. Laden unterschiedlicher Anzahl von Klassen: Normalerweise werden in der JVM Klassen erst dann geladen, wenn sie benötigt werden. Neben der Standardeinstellung werden zwei weitere Verfahren untersucht. Zum einen wird eine minimale Anzahl von Klassen und zum anderen alle verfügbaren Klassen beim Startvorgang mitgeladen. Unterschiedliche Pufferspeicher-Leerung: Nach dem Übersetzen von Quellcode muss der Pufferspeicher ungültig gemacht werden. Es kann entweder lediglich der Instruktionsspeicher oder sowohl der Instruktionsspeicher als auch der Datenspeicher geleert werden. Für die Laufzeit werden die folgenden Design-Konzepte untersucht: Just-in-Time Kompilierung oder Interpretation: Zur Laufzeit können entweder lediglich zum aktuellen Zeitpunkt gebrauchte Methoden (Just-in-Time Kompilierung; Standardeinstellung) oder komplette Klassen (Interpretation) übersetzt werden. Länge des Abfrageintervalls: Eingabeelemente, wie z.b. eine Taste oder ein Berührungsbildschirm, werden in unterschiedlichen Intervallen auf Ereignisse abgerufen. Diese Intervalle werden in der Länge variiert. Mittels drei verschiedener Workloads wurden die angesprochenen Design-Konzepte untersucht. Der Web Workload führt das Browsen von verschiedenen Webseiten durch. Der Schach Workload spielt eine Schachspiel-Anwendung und der Kompositum Workload führt die anderen beiden Workloads aus und bedient zusätzlich eine Taschenrechner-Anwendung. Der Web Workload wurde zum Testen der Auswirkung unterschiedlicher JMVs auf den Energie- bzw. Stromverbrauch verwendet. Die Ausführung von mehreren JVMs erhöht sowohl die Last und somit die Dauer als auch die Anzahl an Operationen und schließlich die Energie. Unter der Nutzung einer einzigen JVM sank der Energieverbrauch um 10% bzw. der Stromverbrauch um 25% und die Ausführungszeit sank um 17%. Werden komprimierte.class-dateien verwendet, muss die JVM diese zum Kompilieren dekomprimieren, wodurch mehr Energie verbraucht wird. Bei dem Kompositum und dem Schach Workload zeigte sich lediglich eine minimale Erhöhung des Energie- bzw. Stromverbrauchs. Beim Web Workload hingegen, stieg der Energie- bzw. Stromverbrauch um 5%. Um die Auswirkungen des Ladens unterschiedlicher Anzahlen von Klassen auf den Energie-bzw. Stromverbrauch zu untersuchen, wurde der Kompositum Workload verwendet. Werden nur solche Klassen geladen, die 26

36 als unwichtig für die spätere Laufzeit eingeschätzt wurden (minimales Laden), ist der Energie- bzw. Stromverbrauch minimal. Die Standardeinstellung verbraucht hingegen ein wenig mehr Energie bzw. Strom. Werden alle verfügbaren Klassen beim Startvorgang der JVM mitgeladen (maximales Laden), steigt der Energie- bzw. Stromverbrauch auf 18% mehr an als beim minimalen Laden. Die Auswirkungen der unterschiedlichen Arten der Pufferspeicher- Leerung auf den Energie-bzw. Stromverbrauch wurden mittels allen drei Workloads untersucht. Die Art der Pufferspeicher-Leerung hat eine vernachlässigbar geringe Auswirkung unabhängig vom Workload. Werden sowohl Instruktionsspeicher als auch der Datenspeicher nach dem Übersetzen von Quellcode geleert, sind Energie- bzw. Stromverbrauch am höchsten. Zur Analyse der Auswirkungen unterschiedlicher Kompilierungskonzepte zur Laufzeit auf den Energie- bzw. den Stromverbrauch wurde der Schach Workload verwendet. Interpretation verursacht eine Steigerung des Energieverbrauchs um 21% bzw. des Stromverbrauchs um 22% gegenüber der Just-in-Time Kompilierung. Durch die Just-in-Time Kompilierung stieg jedoch die Zeit, in der sich die CPU im Ruhezustand befand, wodurch ein größerer Stromverbrauch während des Ruhezustands zu verzeichnen ist. Zur Analyse unterschiedlicher Längen der Abfrageintervalle von Ereignissen von Anwenderinteraktionen auf den Energie- bzw. Stromverbrauch wurden der Web und der Schach Workload verwendet. Wurde die Intervalldauer gegenüber der Standardeinstellung verringert, stiegen Energie- bzw. Stromverbrauch. Durch das Verlängern der Intervalldauer gegenüber der Standardeinstellung, sanken Energiebzw. Stromverbrauch. Analyse einer Java-Anwendung hinsichtlich Energieverhalten und Speicherverwendung Vijaykrishnan et al. (2001) untersuchen eine Java-basierte Anwendung in einer Mikroprozessarchitektur hinsichtlich ihrer Energieverhalten und ihrer Speicherhierarchieverwendung (Caches und Arbeitsspeicher), da Java-basierte Anwendungen mehr die Speicherhierarchie verwenden als andere Anwendungen und der Energieverbrauch der Speicherhierarchie von Java-basierten Anwendungen über 50% vom Gesamtenergieverbrauch beträgt. Die betrachtete Java-basierte Anwendung ist der SPEC JVM98 (Standard Performance Evaluation Corporation 2008) Benchmark. Der SPEC JVM98 Benchmark ermöglicht das Messen der Performanz einer Java-basierten virtuellen Maschine. Das Energieverhalten der betrachteten JVM wird sowohl auf Software- als auch auf Hardwareebene untersucht. Bezüglich der Softwareebene wird die JVM hinsichtlich Just-in-Time Kompilierung und Interpretation untersucht. Wird die JVM im Interpretationsmodus verwendet, besteht der Energieverbrauch hinsichtlich zu 98% aus Interpretation von Softwarecode. Bei Verwendung der Just-In-Time Kompilierung besteht der größte Anteil am Gesamtenergieverbrauch aus der Ausführung von Softwarecode. Generell ist der Gesamtenergieverbrauch im Interpretationsmodus höher als bei Just-In-Time Kompilierung, da zwar bei Interpretation weniger Speicherplatz belegt wird, jedoch häufigere und längere Zugriffe auf den Speicher geschehen als bei der Just-In-Time Kompilierung. Der Energieverbrauch der Garbage Collection einer JVM hängt sowohl von der Heap-Größe als auch von der Größe des Datensatzes ab. Mit einem größeren Heap wird die Garbage Collection öfters ausgeführt und bei einem größeren Datensatz sorgt die Garbage Collection dafür, dass mehr Speicherzugriffe auf den Arbeitsspeicher gemacht werden. In einer JVM haben unterschiedliche Prozesse nicht nur einen 27

37 unterschiedlich großen sondern auch einen sich im Charakter unterscheidenden Energieverbrauch (z.b. kann der Anteil des Energieverbrauchs während der Ausführungs-Phase eines Prozesses A größer sein als der Anteil des Energieverbrauchs während der Ausführungs- Phase eines Prozesses B, obwohl Prozess B einen höheren Gesamtenergieverbrauch aufweist). Der Energiecharakter eines Prozesses verändert sich ebenfalls mit der Größe des zu verarbeitenden Datensatzes. Aus der Perspektive der Hardware betrachtet, ergeben sich folgende Erkenntnisse. Erhöht man die Cache-Größe bis zu einem gewissen Punkt, sinkt der Gesamtenergieverbrauch linear. Ab einem gewissen Punkt ist aufgrund einer größeren Adressdecodierung und einer größeren kapazitiven Last auf den Cache-Zeilen der Aufwand die benötigten Daten zu holen größer als der Energievorteil durch die Möglichkeit eine größere Datenmenge in den Cache zu laden. Ein Erhöhen der Cache-Größe bewirkt eine Reduktion im Energieverbrauch von Zugriffen auf den Instruktionsspeicher. 3.4 Ermittlung des Energieverbrauchs von Software Energieverbrauchsframework für verteilte Java-basierte Systeme Seo et al. (2007) haben ein Modell zum Ermitteln des Energieverbrauchs von Architekturstilen von Java-basierten, verteilten Anwendungen entwickelt. Es werden die Architekturstile Client-Server, Publish-Subscribe, Peer-To-Peer, geschichtetes Client-Server und C2 untersucht. Die Untersuchungen ergaben, dass der Architekturstil einer Software nicht nur Auswirkungen auf Qualitätsmerkmale wie z.b. Funktionalität, Zuverlässigkeit oder Effizienz einer Software sondern auch auf die Energieeffizienz der Software hat. Ihr Modell richtet sich auf die Energieabschätzung von einzelnen Anwendungs-Komponenten und deren Transaktionskosten bei der Kommunikation untereinander. Der Fokus des Frameworks liegt auf der Berechnung der komponentenspezifischen Energiekosten und der durch die Verwaltung der laufenden JVM durch das Betriebssystem anfallenden Infrastrukturkosten. Die Energiekosten EC(Comp i ) einer Komponente Comp i ist die Summe aus den Energiekostenarten Berechnungskosten E logic,i (Energieverbrauch, der für Berechnungen von Hardwarekomponente Comp i aufgrund der Ausführung seiner Anwendungslogik verbraucht wird) und Kommunikationskosten E commwithconn,i (Energieverbrauch, der für den Austausch von Daten mittels eines an der Komponente Comp i verbundenen Konnektors verbraucht wird). Die durch einen Connector Conn j anfallenden Energiekosten EC(Conn j ) sind sie Summe aus aus dem Energieverbrauch für den Kommunikation E comm,j des Konnektors Conn j und dem Energieverbrauch für sonstige Services E logic,j des Konnektors Conn j. E comm,j ist die Summe aus dem Energieverbrauch für den Austausch von Daten E commwithcomp,j des Konnektors Conn j mit angeschlossenen Komponenten und den Energieverbräuchen für den Austausch von Daten mit lokalen bzw. mit entfernten Konnektoren, E localcomm,j bzw. E remotecomm,j, zusammen. E logic,j ist die Summe aus dem Energieverbrauch für die Koordination von Komponenten E coordin,j mittels dieses Konnektors Conn j, dem Energieverbrauch für die Anpassung E conver,j der Interaktion einer Komponente für eine andere Komponente und dem Energieverbrauch für die Weiterleitung E facili,j der Interaktion von Komponenten. Der Gesamtenergieverbrauch overallec der Anwendung ergibt sich schließlich aus der Summe von der Summe aller Energiekosten der n Komponenten und der Summe aller Energiekosten der m Konnektoren: ( ) ( ). 28

38 Energieverbrauchsmodell für Unternehmensanwendungen Jwo et al. (2011) entwickeln ein Energieverbrauchsmodell für Unternehmensanwendungen, die auf der Drei-Schichten-Architektur (Präsentations-, Verarbeitungs- und Datenschicht) basieren. Dieses Modell ermöglicht es den Energieverbrauch jedes Schrittes eines Serviceverlaufes (angefangen bei einer Anfrage durch einen Client bis hin zur GUI Anpassung gemäß der erhaltenen Antwort) zu ermitteln. Die Architektur des Ablaufes eines solchen Services ist in Abbildung 7 dargestellt. Abbildung 7: Zustandsdiagramm eines Serviceverlaufes Quelle: (Jwo et al. 2011, 217) Die einzelnen Zustände sind: Zustand 1: Anwender löst eine Anfrage auf dem Client mittels (grafischer) Oberfläche aus. Zustand 2: Die Anfrage wird mitsamt dazugehörigen Daten durch das Internet zum Applikationsserver (AP Server) transferiert. Zustand 3: Die auf dem AP Server gehosteten Anwendungsdienste führen anfängliche Berechnungen durch. Zustand 4: Abhängig von der anfänglichen Berechnung wird möglicherweise eine Datenanfrage an die Datenbank über das LAN (Local Area Network) gesendet. Zustand 5: Die Datenbank führt Berechnungen auf den Daten aus. Zustand 6: Berechnete Daten (Resultate) werden über das LAN zurück an den AP Server gesendet. Zustand 7: Die Anwendungsdienste bearbeiten die Resultate und führen, falls nötig, weitere Berechnungen durch (Antwort). Werden weitere Berechnungen durchgeführt und dafür Daten benötigt, so können Zustände 4 bis 7 wiederholt werden. Zustand 8: Die Antwort wird von dem AP Server an den Client gesendet. Abhängig vom genutzten Web Protokoll können mehrere Übermittlungen stattfinden. Zustand 9: Der Client erstellt die (grafische) Oberfläche gemäß den erhaltenen Antwortdaten. Das Energieverbrauchsmodell für einen solchen Service ergibt sich wie folgt. E (Service) E ( ustand ) E ( ustand ) E ( ustand ) m(e ( ustand ) + E ( ustand ) + E ( ustand ) + E ( ustand )) + n E ( ustand ) E ( ustand ), wobei m für die Anzahl an Durchläufen der Zustände 4 bis 7 bzw. n für die Anzahl an Wiederholungen von Zustand 8 steht. Die einzelnen Energieverbräuche lassen sich wie folgt ermitteln. E (Zustand 1) ist definiert als der durchschn. Stromverbrauch des Client- 29

39 Computers multipliziert mit der Dauer für die Erstellung der Anfrage. E (Zustand 2) ist definiert als der durchschn. Energieverbrauch pro Gigabyte Daten versandt über das Internet multipliziert mit der zu versendenden Datengröße. E (Zustand 3) ist definiert als der durchschn. Energieverbrauch des AP Servers für Berechnungen multipliziert mit der zu berechnenden Datengröße. E (Zustand 4) ist definiert als der durchschn. Energieverbrauch pro Gigabyte Daten versandt über LAN multipliziert mit der zu versendenden Datengröße. E (Zustand 5) ist definiert als der durchschn. Energieverbrauch der Datenbank für Datenberechnungen multipliziert mit der zu berechnenden Datengröße. E (Zustand 6) ist definiert als der durchschn. Energieverbrauch des AP Servers für Berechnungen multipliziert mit der zu berechnenden Datengröße. E (Zustand 7) ist definiert als der durchschn. Energieverbrauch pro Gigabyte Daten versandt über das Internet multipliziert mit der zu versendenden Datengröße. E (Zustand 9) ist definiert als der durchschn. Stromverbrauch des Client-Computers multipliziert mit der Dauer für die Erstellung der Anfrage. WattApp Energiemodell auf Applikationsebene für verteilte Datencenter Koller et al. (2010) haben eine Strommessumgebung namens WattApp entwickelt, um auf Applikationsebene den Stromverbrauch von heterogenen Applikationen in verteilten Datencentern zu messen. Das Energiemodell, auf dem WattApp aufbaut, basiert auf der Metrik Durchsatz einer Anwendung. Der Durchsatz einer Anwendung beschreibt die Anzahl an abgearbeiteten Aufgaben pro Sekunde. Der resultierende Stromverbrauch P(A i ) einer Anwendung A i ergibt sich aus der Summe aus einem statischen Anteil α i und einem dynamischen Anteil. Der statische Anteil ist gleich dem Stromverbrauch der Hardware im Ruhezustand. Der dynamische Anteil besteht aus dem Produkt aus einem Konfigurationsparameter β i und dem Durchsatz λ i der Anwendung A i. Wird die Anwendung virtualisiert, so wird der Virtualisierungsfaktor d berücksichtigt. Der Virtualisierungsfaktor beschreibt die Anzahl an virtuellen Maschinen, in denen die Anwendung aufgeteilt ist. Der resultierende Stromverbrauch P(A i,d ) einer virtualisierten Anwendung A i ergibt sich aus der Summe aus einem statischen Anteil α i,d bei Virtualisierung d und dem dynamischen Anteil β i,d * λ i. Zur Ermittlung der Parameter α i und β i bzw. α i,d und β i,d, muss zunächst eine Kalibrierungsphase durchlaufen werden. Dazu werden in der jeweiligen Konfiguration (ausgewählter Durchsatz und Grad der Virtualisierung) Testläufe durchgeführt und anschließend die Parameter α i und β i bzw. α i,d und β i,d mittels linearer Regression bestimmt. Zur Ermittlung des Stromverbrauchs von n virtualisierten Anwendungen, werden die dynamischen Anteile der Energiemodelle aller n Anwendungen linear kombiniert und der größte statische Anteil dieser n Anwendungen ergibt den gemeinsamen statischen Anteil. Somit ergibt sich der Stromverbrauch von n Anwendungen wie folgt: P(A 1,d + A 2,d + + A n,d ) = max(α 1,d, α 2,d,, α n,d ) + β 1,d + β 2,d + + β n,d, wobei d der gemeinsame Virtualisierungsfaktor ist. Mit steigendem Applikationsdurchsatz steigt der Stromverbrauch linear an. Die Mehrauslastung ist durch Virtualisierung von Anwendung zu Anwendung unterschiedlich, je nachdem, ob die Anwendung eine hohe Lese- und Schreib-Rate (bezogen auf Festplatte bzw. Netzwerkkomponenten) hat. Eine Anwendung hat eine höhere Lese- und Schreib-Rate, wenn sich wenige Daten im Pufferspeicher befinden und somit mehr Daten von Festplatte und/oder Netzwerk geladen werden müssen. 30

40 WattApp besteht aus dem Model Builder Flow, dem Configuration Management Flow und dem Oracle Flow. Der Model Builder Flow liest die System- und Applikationsprotokolle, um Stromverbrauchsmodelle auf Applikationsebene zu erstellen. Der Configuration Management Flow identifiziert laufende Anwendungen, weist die erstellten Stromverbrauchsmodelle den entsprechenden Anwendungen zu und trägt dafür Sorge, dass für fehlende, benötigte Konfigurationsparameter und Durchsatzraten Testläufe durchgeführt werden, um die Stromverbrauchsmodelle vom Model Builder Flow generieren zu lassen. Mit Hilfe des Oracle Flow können die Stromverbrauchsmodelle gespeichert und abgerufen werden, damit WattApp jederzeit eine Einschätzung des Stromverbrauchs der laufenden Anwendungen ermitteln kann. Die Fehlerrate von WattApp beträgt weniger als 5% und ist somit signifikant genauer als Energiemodelle, die lediglich auf der Auslastung von der CPU basieren, eine Fehlerrate von mehr als 50% haben. Komplette Systemsimulation zur Ermittlung des Stromverbrauchs von Software Gurumurthi et al. (2002) haben das Betriebssystem SoftWatt entwickelt, mit dem es möglich ist, den Stromverbrauch von Software durch Simulation von Hardware und Software zu ermitteln. SoftWatt baut auf dem Simulationsbetriebssystem SimOS (Rosenblum et al. 1995) auf. Mittels SimOS ist es möglich, Hardware wie CPU, Speicherhierarchie und Festplatte und deren Performanz zu simulieren. SimOS simuliert das Betriebssystem IRIX 5.3. SimOS beherbergt eine Reihe von Schnittstellen zum Auslesen von Systemereignissen und zur Sammlung von Statistiken. SoftWatt ergänzt SimOS um analytische Stromverbrauchsmodelle. SoftWatt ermöglicht die Ermittlung des Stromverbrauchs einer Anwendung, indem die Stromverbräuche von CPU, Speicherhierarchie, Festplatte und der durch das Betriebssystem auftretende Energiemehrverbrauch ermittelt werden. Der durch das Betriebssystem auftretende Energiemehrverbrauch wird deswegen miteinbezogen, da dieser insbesondere bei Java Anwendungen auftreten kann. Neben der Ermittlung des Energieverbrauchs der Anwendung, ist es mittels SoftWatt möglich, die ausgeführte Software zu analysieren. So lassen sich z.b. kritische Stellen bezüglich des Energieverbrauchs ermitteln. Beim ausgeführten Betriebssystem werden 5% des Energieverbrauchs auf Systemebene durch die Ausführung des Ruhezustand-Prozesses unter anderem dadurch verbraucht, dass Hardwarekomponenten nicht komplett abgeschaltet werden, wenn sie nicht benötigt werden. JouleMeter Tool zum Ermitteln des Stromverbrauchs von virtuellen Maschinen Kansal et al. (2010) haben das Tool JouleMeter zur Ermittlung des Stromverbrauchs von virtuellen Maschinen entwickelt. Mit JouleMeter ist es möglich, auf Hardwareauslastung basierend, den Stromverbrauch von durch einen Hypervisor verwalteten virtuellen Maschinen zu ermitteln. Die untersuchten Hardwarekomponenten sind CPU, Arbeitsspeicher und Festplatte. Da die Hardwareauslastung innerhalb einer virtuellen Maschine nicht exakt der reellen Hardwareauslastung entspricht, wird die Hardwareauslastung der reellen Hardwarekomponenten und zusätzlich der virtuellen Maschine gemessen. 31

41 Das zugrundeliegende Energiemodell ist wie folgt aufgebaut. Der Stromverbrauch P CPU der CPU ist die Summe aus einem statischen Wert γ CPU und dem Produkt aus der CPU-Auslastung u CPU und einem Konfigurationsparameter α CPU. Der CPU-bezogene Stromverbrauch P CPU,A einer virtuellen Maschine A ist das Produkt aus der CPU-Auslastung u CPU,A durch die virtuelle Maschine A und dem Konfigurationsparameter α CPU. Der Stromverbrauch P Mem (T) des Arbeitsspeichers über den Zeitraum T kann verallgemeinert als die Summe aus einem statischen Wert γ Mem und dem Produkt aus der Anzahl an Last-Level-Cache Verfehlungen N LLCM und einem Konfigurationsparameter α Mem ausgedrückt werden. Der Arbeitsspeicher-bezogene Stromverbrauch P Mem,A (T) der virtuellen Maschine A ist das Produkt aus der Anzahl an Last-Level- Cache Verfehlungen N LLCM und dem Konfigurationsparameter α Mem. Der Stromverbrauch P Disk (T) einer Festplatte über den Zeitraum T kann verallgemeinert als die Summe aus einem statischen Wert γ disk, aus dem Produkt aus der Anzahl an gelesenen Bytes b r und einem Konfigurationsparameter α rb und aus dem Produkt aus der Anzahl an geschriebenen Bytes b w und einem Konfigurationsparameter α wb ausgedrückt werden. Der Festplatten-bezogene P Disk,A (T) Stromverbrauch einer virtuellen Maschine A über einen Zeitraum T ist die Summe aus dem Produkt von der Anzahl an gelesenen Bytes b r,a der virtuellen Maschine A und dem Konfigurationsparameter α rb und aus dem Produkt von der Anzahl an geschriebenen Bytes b w,a der virtuellen Maschine A und dem Konfigurationsparameter α wb. Die Anzahl an gelesenen Bytes b r,a einer virtuellen Maschine A und die Anzahl an geschriebenen Bytes b w,a einer virtuellen Maschine A kann man aufgrund eines vernachlässigbar kleinen Unterschiedes im Stromverbrauch von Lese- und Schreiboperationen zu einer gemeinsamen Variable, b IO, zusammenfassen. Somit ergibt sich der Festplatten-bezogenen Stromverbrauch P Disk,A (T) einer virtuellen Maschine aus dem Produkt aus der Anzahl an gelesenen und geschriebenen Bytes b IO,A der virtuellen Maschine A und einem Konfigurationsparameter α IO. Der Gesamtstromverbrauch P sys des Systems kann als Summe aus dem Stromverbrauch der CPU P CPU, dem Stromverbrauch des Arbeitsspeichers P Mem, dem Stromverbrauch der Festplatten P Disk und dem Stromverbrauch im Ruhezustand P static zusammengefasst werden. Da die CPU-Auslastung u CPU einen Wertebereich zwischen 0 und 1 hat, jedoch die Anzahl an Last-Level-Cache Verfehlungen N LLCM und die Anzahl an gelesenen und geschriebenen Daten b IO jegliche ganze, positive Zahl annehmen können, werden N LLCM und b IO bezüglich ihrer Maximalwerte normalisiert. Der Gesamtstromverbrauch einer virtuellen Maschine ergibt sich demnach wie folgt: P sys = α CPU * u CPU + α mem * u mem + α disk * u disk + γ, wobei u mem bzw. u disk die normalisierte Werte von N LLCM bzw. b IO darstellen und γ die Summe aus P static, γ CPU, γ Mem, und γ disk ist. Die verschiedenen α- und γ- Werte werden in einem Kalibrierungslauf und linearer Regression ermittelt. Werden n virtuelle Maschinen ausgeführt, werden alle nicht-statische Variablen (α, u) jeder virtuellen Maschine für die Berechnung des Gesamtstromverbrauchs berücksichtigt und dazu sinngemäß aufsummiert. Der Aufbau von JouleMeter ist wie folgt. Das system resource and power tracing Modul liest CPU- und Festplattenauslastung und den Stromverbrauch aus. Es werden keine Daten über die Anzahl von Last-Level-Cache Verfehlungen gesammelt, da diese über die CPU ermittelt werden und die Implementierung der CPU herstellerabhängig ist. Das VM resource tracing Modul zeichnet die individuelle Hardwareauslastung jeder virtuellen Maschine auf. Das base model training Modul ermittelt die Konfigurationsparameter einerseits beim Start und andererseits auch dynamisch erneut mit jeder hinzugefügten virtuellen Maschine. Der energy 32

42 calculation block errechnet anhand der ausgelesenen Hardwareauslastung und der Konfigurationsparameter die Stromverbräuche der virtuellen Maschinen. Die untersuchte Anwendung ist die SPEC CPU2006 (Standard Performance Evaluation Corporation 2011) Benchmark Suite. Die Fehlerraten von JouleMeter bezüglich der Ermittlung des Stromverbrauchs der einzelnen Anwendungen der Benchmark Suite liegen innerhalb des 0%-5%-Fehlerbereiches. Software-Framework zur Ermittlung von energiekritischen Stellen einer Java-basierten Anwendung Noureddine et al. (2012) haben ein Software-Tool namens e-surgeon entwickelt, um eine Java-basierte Anwendung auf energiekritische Stellen zu untersuchen. Mithilfe von e-surgeon lässt sich eine Java-basierte Anwendung auf Methodenebene instrumentieren und somit der Energieverbrauch eines Prozesses auf Methodenebene ermitteln. Das zugrundeliegende Energiemodell PowerAPI ermittelt auf Basis von Informationen über den Energieverbrauch von CPU und Netzwerkhardware (z.b. Netzwerkkarte) den Energieverbrauch einer Anwendung indem alle methodenbezogene Energieverbräuche aufsummiert werden. Auf Basis von einerseits vom Betriebssystem gewonnenen Auslastungsstatistiken über die zentrale Recheneinheit und andererseits über die von PowerAPI errechneten Energieverbräuche je Prozess und Zeiteinheit wird der zentrale Recheneinheit-basierte Energieverbrauch der Anwendung ermittelt. Der netzwerkressourcenbasierte Energieverbrauch lässt sich anhand von Informationen über die gelesene und geschriebene Datenmenge je Methode und über die von PowerAPI errechneten Energieverbräuche je Prozess und Zeiteinheit ermitteln. Mittels e-surgeon lassen sich somit sowohl der gesamte Energieverbrauch einer Anwendung als auch die Energieverbräuche einzelner Methoden und somit energiekritische Stellen innerhalb der Software ermitteln. Der durch die Code-Instrumentierung eingebrachte Mehraufwand von e-surgeon beim Ausführen der betrachteten Anwendung beträgt auf einem Laptop etwas mehr als 50%. Da eine Hardwareumgebung nicht mit einer anderen Hardwareumgebung zu vergleichen ist (z.b. Laptop und Server), können die zusätzlichen Auswirkungen der Code-Instrumentierung für Server-optimierte Ressourcen (z.b. mehr Rechenkerne pro CPU als bei einer Laptop-optimierten CPU) einen erhöhten, relevanten Energieverbrauch bei der Ausführung der instrumentierten Anwendung und somit ein zu stark verfälschtes Ergebnis bedeuten. Zur Ermittlung des Energieverbrauchs berücksichtigt PowerAPI lediglich die Hardwarekomponenten CPU und Netzwerkkarte. Obwohl der Energieverbrauch einiger Hardwarekomponenten (Netzwerkressourcen) im vorliegenden Werk im Vergleich mit dem Energieverbrauch der zentralen CPU sehr gering ist, ist es ratsam alle verfügbaren Hardwarekomponenten (z.b. Arbeitsspeicher) in das Energiemodell miteinzubeziehen, da somit die Genauigkeit steigt (Kansal et al. 2010). 3.5 Diskussion Die Erforschung von Energieverbrauch von Software ist ein junges Fachgebiet: 1998 haben Benini et al. (1998) einzelne Hardwarekomponenten eines Notebooks auf ihren Energieverbrauch hin untersucht. Obwohl der Fokus der Arbeit auf der Hardware lag, wurden spezifi- 33

43 sche Benchmarks zur Lastgenerierung verwendet. Bereits damals wurde ersichtlich, dass unterschiedliche Software unterschiedliche Auswirkungen auf die Auslastung der Hardware hat und somit auf den Stromverbrauch. Auf Basis dieser Erkenntnis gewann die Erforschung von Software hinsichtlich ihres Energieverbrauchs an Bedeutung 5. Der Fokus auf der Untersuchung der Energieeffizienz von Hardware verlagert sich zunehmend in Richtung der Untersuchung der Energieeffizienz von Software (Green Software Engineering 2013). Da sich durch energieeffiziente Software neben der Einsparung an Strom zudem Energiekosten senken lassen, hat die Untersuchung von Energieeffizienz von Software für Unternehmen einen Mehrwert im Hinblick auf die Möglichkeiten zur Senkung ihrer Betriebskosten. In Anbetracht dessen, erfolgt die nachfolgende Diskussion über gewonnene Aussagen im Hinblick auf das Unternehmensumfeld bzw. die Praktikabilität für Unternehmensanwendungen. Im Vergleich zu Einzelanwender-Anwendungen wie z.b. Textverarbeitungsanwendungen, die auf handelsüblichen Endanwendersystemen (Desktopcomputer oder Notebook) Verwendung finden, laufen Unternehmensanwendungen auf leistungsstarker Hardware, die für mehr Leistung konzipiert sind, da Unternehmensanwendungen mehr Anfragen abarbeiten müssen. Aus der Literatur zum Thema Energieverbrauch von Software ist ersichtlich, dass einige getestete Anwendungen auf leistungsstarker Hardware (z.b. Li et al. (2011), Tsirogiannis et al. (2010)) untersucht werden. Ein noch stärker untersuchtes Teilgebiet jedoch ist die Untersuchung von Energieeffizienz von Software in eingebetteten Systemen (Pocket-Computer, Mobiltelefone, etc.), da die geringe Hardware-Größe nicht nur leistungsärmere Hardwarekomponenten erzwingt und somit weniger Leistung bereitgestellt wird, sondern auch weniger Raum für einen leistungsstarken Energiespeicher zur Verfügung stellt. Eine große Forschungslücke ergibt sich bei der Untersuchung von Unternehmensanwendungen. Lediglich z.b. Jwo et al. (2011) und Capra et al. (2012) fokussieren ihre Arbeit auf Unternehmensanwendungen. Virtualisierung von Unternehmensanwendungen ist im Unternehmensumfeld ein probates Mittel zur effektiven Nutzung der vorhandenen Hardware (Xianmin 2011). Dabei werden Unternehmensanwendungen jeweils in einer eigenen virtuellen Maschine gehostet und die verfügbare Hardware nach Bedarf statisch oder dynamisch auf die verschiedenen virtuellen Maschinen verteilt. Mit dem Prinzip der Virtualisierung beschäftigen sich zwar unter anderem Kansal et al. (2010), jedoch ist die verwendete Software, die SPEC CPU2006 (Standard Performance Evaluation Corporation 2011) Benchmark Suite, keine Unternehmensanwendung, sondern besteht aus einer Vielzahl von Mikrobenchmarks, die primitive Rechenoperation ausführen. Java-basierte Anwendungen, die im Sinne der Architektur einer Unternehmensanwendung aufgebaut sind (verteilte Java-basierte Anwendungen) und die Java EE Technologie (Oracle Corporation o.j.-a)) verwenden (z.b. der SPECpower_ssj2008 (Standard Performance Evaluation Corporation 2013) Benchmark), benötigen je nach Anzahl der Anwender ebenfalls leistungsstarke Hardware (z.b. Datenbankserver) für die Durchführung ihrer Prozesse. Z.B. Oi/Niboshi (2013) untersuchen eine solche Java-basierte verteilte Anwendung, jedoch ist es ihnen nicht möglich große Anzahlen an Anwendern zu simulieren, da die zugrundeliegende Hardware ein Endanwendersystem ist. 5 Vgl. Kapitel

44 Eine Großzahl an Arbeiten beschäftigt sich mit der Untersuchung des Energieverbrauchs von Systemsoftware. In diesem Teilgebiet werden vorzugsweise Systemprozesse und -anwendungen des Betriebssystems untersucht, die zwar von Unternehmensanwendungen angestoßen werden, die Art der Ausführung dieser jedoch von der entsprechenden Unternehmensanwendung abhängt (z.b. Li/John (2003)). Bei dem Zugriff auf Systemprozesse bzw. -anwendungen ist es möglich die Energieeffizienz dieser zu berücksichtigen und es sollten unterschiedliche, gleichartige Systemprozesse verglichen werden, da ein Systemprozess mit dem effizienteren Algorithmus auch energieeffizienter ist (Johann et al. 2012). Bezüglich der Virtualisierung von Unternehmensanwendungen liegt Potenzial für Energieeinsparung auch in der Virtualisierungssoftware (Ziming/Song 2011): mit einem höheren Grad der Virtualisierung kann zum einen der Energieverbrauch steigen, zum anderen kann jedoch die Energieeffizienz z.b. von Festplatten sinken, da der Mehraufwand für die Bearbeitung einer Datei zu einem höheren Energieverbrauch durch eine höhere Belastung der Hardware führt. Die Untersuchung von Software in eingebetteten Systemen erfährt ebenfalls große Zuwendung. Client- Anwendungen können z.b. dahingehend optimiert werden, dass z.b. keine Werbung eingebaut wird, da diese bis zu 75% des Energieverbrauchs einer Anwendung auf mobilen Geräten verbrauchen kann (Pathak et al. 2011). Viele mobile Anwendungen basieren auf Java aufgrund der Tatsache, dass das Betriebssystem Android Java-basierte Anwendungen ausführt. Bei solchen mobilen Anwendungen kann eine höhere Energieeffizienz durch z.b. eine richtige Konfiguration der ausführenden JVM (Farkas et al. (2000), Vijaykrishnan et al. (2001)) eine längere Akkulaufzeit ermöglichen. Eine längere Akkulaufzeit ist direkt durch eine energiebewusste Softwareentwicklung der Java-basierten Anwendung zu ermöglichen. Client- Applikationen, die auf Java basieren, sollten so entwickelt werden, dass möglichst wenig Objekte instanziiert werden, da Arbeitsspeicherzugriffe sich stärker auf den Energieverbrauch auswirken, als arithmetische Operationen, die sich primär auf die CPU beziehen (Lafond/Lilius 2006). Wie zuvor erwähnt, kann Software Unternehmen helfen, ihre Betriebskosten durch Stromkosteneinsparung zu senken. Um diesen Kostenfaktor zu quantifizieren, muss der Energieverbrauch der verwendeten Unternehmensanwendungen ermittelt werden. Ausgewählte Methoden wie z.b. die Ermittlung anhand von Energiemodellen für bestimmte Arten von Unternehmensanwendungen (Jwo et al. 2011) spiegeln nicht den Ablauf aller Prozesse einer Unternehmensanwendung wieder und sind deshalb nur eingeschränkt für die Ermittlung des Energieverbrauchs von Unternehmensanwendungen geeignet. Solche Modelle erfordern eine tiefergehende Auseinandersetzung mit verwendeten Unternehmensanwendungen, da ein Unternehmen für die verschiedenen Unternehmensanwendungen jeweils speziell die einzelnen Faktoren des Energiemodells anhand dem Aufbau der jeweiligen Unternehmensanwendung ermitteln muss und das Energiemodell entsprechend anwenden muss. Zur korrekten Ermittlung einer kompletten Unternehmensanwendung können somit verschiedene Energiemodelle benötigt werden, da je spezieller ausgelegt ein Energiemodell ist, dieses Energiemodell einen kleineren Abschnitt der Unternehmensanwendung berücksichtigt. Bei Energiemodellen, die auf abstrakter Ebene den Energieverbrauch einer Software ermitteln (Seo et al. 2007), bedarf es einer Einschätzung darüber, wie die einzelnen Bestandteile der Unternehmensanwendung gemäß dem Energiemodell so aufbereitet werden (z.b. durch Instrumentierung), dass das Energiemodell angewendet werden kann. Neben der Aufbereitung der Unternehmensanwendung kann ein Gebrauch von Messinstrumenten für die Messung des Energieverbrauchs not- 35

45 wendig sein, da nicht alle Computersysteme über eingebettete Messgeräte verfügen. Neben der Aufbereitung der Unternehmensanwendung, der Ausführung der Unternehmensanwendung und ggf. der Installation der Messumgebung muss das verwendete Energiemodell mit den erhaltenen Daten gefüttert und ausgewertet werden (Analyse). Für die Aufbereitung der Unternehmensanwendung und der abschließenden Analyse bedarf es Aufwendung und Zeit, wodurch es durch z.b. Entwicklungsaufwand zu signifikanten Mehrkosten für das Unternehmen kommen kann. Softwarebasierte Komplettlösungen wie z.b. Noureddine et al. (2012), die einerseits die Aufbereitung einer Anwendung und andererseits die Analyse übernehmen, können hier Abhilfe schaffen und das Unternehmen entlasten. Solche Komplettlösungen beinhalten bereits Energiemodelle, auf deren Basis eine ausgewählte Anwendung hinsichtlich ihres Energieverbrauchs untersucht werden kann. Durch einen unterschiedlichen Fokus, sind solche Komplettlösungen unterschiedlich aufgebaut. Kansal et al. (2010) untersuchen den Stromverbrauch einer Anwendung indem die Hardwarekomponenten CPU, Arbeitsspeicher und Festplatte berücksichtigt werden, wohingegen Noureddine et al. (2012) lediglich die Hardwarekomponenten CPU und Netzwerkkomponenten berücksichtigt. Komplettlösungen wie Noureddine et al. (2012) beinhalten neben den Energiemodellen auch sog. Energietabellen, in denen Informationen über hardwarekomponentenbezogene Energieverbräuche enthalten sind, sodass anhand dieser die Energiemodelle bezüglich der zu untersuchenden Anwendung kalibriert werden können und somit keine Installation einer Messumgebung von Nöten ist. Da Noureddine et al. (2012) eine softwarebasierte Komplettlösung entwickelt haben, in der festgelegte Hardwarekomponenten simuliert werden, sind Informationen über den Energieverbrauch dieser bekannten Hardwarekomponenten bereits im vornherein ermittelbar. Bei softwarebasierten Lösungen wie JouleMeter (Kansal et al. 2010) ist eine Installation einer externen Messumgebung von Nöten, da aufgrund der Anwendbarkeit für unterschiedliche Hardware keine Energietabellen enthalten sind. Generell betrachtet sind softwarebasierte (Komplett-)Lösungen zur Ermittlung des Energieverbrauchs von Software geeignet, wenn die zugrundeliegende Hardware unterstützt wird und kein Entwicklungsaufwand zur Abänderung der softwarebasierten (Komplett-)Lösung erforderlich ist. Ein populäres Mittel zur Bestimmung des Energieverbrauchs von Software ist anhand von Informationen über den Hardwarebedarf von Software auf den Energieverbrauch von Software zu schließen. Der Hardwarebedarf lässt sich mittels unterschiedlicher Techniken ermitteln 6. Je nach Fokussierung und Ausrichtung der Forschungsarbeit werden unterschiedliche Hardwarekomponenten betrachtet und zur Untersuchung auf den Energieverbrauch verwendet. Tsirogiannis et al. (2010) z.b. betrachten bei ihrer Untersuchung eines Datenbankservers die CPU, den Arbeitsspeicher und die Festplatte. Mahesri/Vardhan (2005) betrachten die Hardwarekomponenten CPU, Arbeitsspeicher, Festplatte, Bildschirm, Grafikkarte und Netzwerkkomponenten. Diese beiden Werke und Capra et al. (2012) haben herausgefunden, dass die CPU den größten Anteil am Gesamtenergieverbrauch ausmacht. Neben der CPU macht der Arbeitsspeicher einen Großteil am Gesamtenergieverbrauch aus. Alle anderen Hardwarekomponenten außer der CPU und dem Arbeitsspeicher eines Servers machen lediglich 30%- 40% vom Gesamtenergieverbrauch aus (Economou et al. 2006), wobei Festplatte und Netzteil 6 Vgl. Kapitel 2.4 (Performanz-Metrik Hardwareauslastung ), Kapitel

46 davon den größten Anteil haben. In Abbildung 8 werden die anteiligen Stromverbräuche einzelner Hardwarekomponenten eines Servers zusammenfassend dargestellt, wobei der Anteil der Festplatte ( Disk ) mit zunehmender Anzahl an verbauten Festplatten signifikant zunimmt (Minas/Ellison 2009). Abbildung 8: Unterteilung des Stromverbrauchs eines Servers Quelle: (Minas/Ellison 2009, 6) Aufgrund der Tatsachen, dass die IT-Ressourcen zum einen wichtige Hardwarekomponenten zur Unterstützung der Erfüllung der Aufgaben in der IT sind 7 und zum anderen den größten Anteil am Gesamtstromverbrauch innerhalb eines Servers haben, werden dementsprechend IT-Ressourcen im weiteren Verlauf dieser Arbeit fokussiert. 7 Vgl. Kapitel

47 4 Vom Hardwarebedarf zum Energieverbrauch von Software In einem erweiterten Literatur-Review in FF2, das auf den Ergebnissen aus FF1 aufbaut, sollen existierende Möglichkeiten analysiert werden, um mit Hilfe von Informationen über den Hardwarebedarf von Software auf den Energieverbrauch von Software zu schließen. In Kapitel 4.1 werden unterschiedliche Möglichkeiten zur Ermittlung des Energieverbrauchs von Software anhand von Informationen über den Hardwarebedarf dargestellt. In Kapitel 4.2 werden die vorgestellten Ergebnisse aus Kapitel 4.1 im Hinblick auf die Praktikabilität zur Ermittlung des Energieverbrauchs einer Unternehmensanwendung diskutiert. Abschließend werden in Kapitel 4.3 Energiemodelle vorgestellt, deren Verwendung auf Basis der Ergebnisse aus Kapitel 4.2 in einem Unternehmensumfeld als praktikabel erachtet wird. 4.1 Bemessungsgrundlage Hardware Wie in dieser Arbeit bereits erörtert, hat Software einen signifikanten Einfluss auf den Stromverbrauch 8. Dabei hat verschiedenartige Software einen unterschiedlich starken Einfluss auf den Stromverbrauch (Li/John 2003), da Software je nach Architektur und Funktionalität unterschiedliche Hardwarekomponenten auslasten kann. So können für unterschiedliche Unternehmensprozesse, die in einer Unternehmensanwendung abgebildet sind, zugrundeliegende Hardwarekomponenten unterschiedlich ausgelastet werden, wodurch sich je nach ausgeführter Unternehmensanwendung ein verschiedenartiger Hardwarebedarf ergeben kann. Diese Variabilität kann es nicht nur Cloud Anbieter erschweren, den Hardwarebedarf der zu hostenden Anwendungen zu bestimmen (Chen et al. 2013). Auch für Unternehmen kann ein gravierender Unterschied im Verhalten von unterschiedlichen Unternehmensanwendungen die Ermittlung ihrer Betriebskosten erschweren, da verschiedenartige Software einen unterschiedlichen Hardwarebedarf hat und somit ein unterschiedlicher Strombedarf mit unterschiedlicher Software einhergeht. Um für Unternehmen die Ermittlung der Stromkosten ihrer Unternehmensanwendungen zu ermöglichen, gilt es einerseits den Hardwarebedarf von Unternehmensanwendungen korrekt zu ermitteln und andererseits aus Informationen über den Hardwarebedarf den Stromverbrauch von Software zu quantifizieren. Nachfolgend werden verschiedene Herangehensweisen zur Ermittlung von einerseits dem Hardwarebedarf von Software und andererseits dem Energieverbrauch von Software vorgestellt. Energiemodel basierend auf Performanzzähler-Events Performanzzähler [..] ermöglichen die Überwachung und die Messung von ausgewählten Prozessor Performanz Parametern (im Original in englischer Sprache) (Intel Corporation 2013a, 575). Diese sind in der CPU integriert. Intel Corporation (2013a) unterscheidet zwei Arten von Performanzzähler. Während 8 Vgl. Kapitel 3 38

48 architektonische Performanzzähler unabhängig von der Realisierung der CPU in der CPU integriert sind (hardwareunabhängige Performanzzähler), sind nicht-architektonische Performanzzähler nur in bestimmten CPU-Realisierungen integriert (hardwareabhängige Performanzzähler). Um die Performanz zu überwachen, erstellen Performanzzähler Events, in denen die aktuelle Hardwarenutzung aggregiert oder eine genommene Stichprobe der Hardwarenutzung enthalten ist. Bircher/John (2007) ermitteln den Energieverbrauch von Anwendungen basierend auf solchen Performanzzähler-Events. Auf Basis von verschiedenen Performanzzählern ermitteln sie Energiemodelle zur Ermittlung des Energieverbrauchs von der CPU, dem Arbeitsspeicher, der Festplatte, dem Chipsatz und dem Datenübertragungssystem (I/O) (z.b. PCI Bus, Datenkabel). Es werden verschiedene Performanzzähler-Events berücksichtigt. Zur Ermittlung des Energieverbrauchs der CPU werden die Events Taktrate (Kernfrequenz * Zeit), unterbrochene Taktrate (Taktrate bei der das Taktsignal ausgesetzt wurde) und Micro-operations fetched (uops) gesammelt, wobei Taktrate für alle fünf Energiemodelle verwendet wird, damit die Ermittlung von Events zur Basiseinheit Takt ermöglicht werden kann, da durch z.b. Latenzzeiten anderer Events die Ziehung von Stichproben ungenau ausfallen könnte. Zur Ermittlung des Energieverbrauchs des Arbeitsspeichers werden Level 3 Cache Misses gesammelt. Da der Level 3 Cache der in der Speicherhierarchie letzte Cache vor dem Arbeitsspeicher ist und Cache-Speicherzugriffe, die den Level 3 Cache-Speicher verfehlen (sog. Level 3 Cache Misses ), Daten vom Arbeitsspeicher laden, kann somit anhand der Tatsache, dass Level 3 Cache Misses direkt proportional zu Arbeitsspeicherzugriffen sind (Bircher/John 2007), der Energieverbrauch des Arbeitsspeichers auf Basis der Level 3 Cache Misses ermittelt werden. Da Level 3 Cache Misses nicht für alle Workloads geeignet sind, werden alternativ Processor Memory Bus Transaktionen verwendet. Processor Memory Bus Transaktionen sind alle zwischen dem Arbeitsspeicher und der CPU verlaufenden Transaktionen, die die CPU betreten oder verlassen möchten. Zur Ermittlung des Energieverbrauchs von der Festplatte, werden DMA Accesses und Interrupts verwendet. DMA Accesses sind Transaktionen, die von einer I/O Hardwarekomponente ausgelöst wurden. Mit DMA Accesses werden die Kohärenz des Arbeitsspeichers gewährleistet und Datenkonfigurationen in Bezug auf die Weiterverarbeitung durch die Festplatte im Arbeitsspeicher gespeichert. Interrupts sind Signale an die CPU, dass von der Festplatte aufbereitete Daten für die Weiterverarbeitung (durch die CPU) für die CPU zur Verfügung stehen. Für die Ermittlung des Energieverbrauchs der I/O werden lediglich Interrupts zur Basis Taktrate verwendet. Für die Ermittlung des Energieverbrauchs des Chipsatzes wird ein konstantes Energiemodell verwendet. Dies liegt zum einen daran, dass die Variation des Energieverbrauchs des Chipsatzes vernachlässigbar gering ist. Die durchschnittliche Fehlerrate aller Energiemodelle beträgt maximal 9%. Die durchschnittliche Fehlerrate für das Energiemodell für die CPU liegt bei 3,1%. Das Energiemodell für den Arbeitsspeicher hat eine durchschnittliche Fehlerrate von 2,2%. Die durchschnittliche Fehlerrate des Energiemodells für die Festplatte beträgt 1,75 % und die durchschnittliche Fehlerrate 39

49 für das Energiemodell für das I/O beträgt 1%. Durch die Verwendung der linearen Regression, haben die entwickelten Energiemodelle eine geringe Mehrbelastung der zugrundeliegenden Hardware bzw. Software. Nach den Merkmalen eines idealen Energiemodells 9 ist eine Anwendung dieser Energiemodelle nur bedingt zu empfehlen. Die entwickelten Energiemodelle liegen innerhalb des 0%- 10%-Fehlerbereiches, wodurch sie genau sind. Dadurch, dass die entwickelten Energiemodelle eine geringe Mehrbelastung auf die verwendete Hardware ausüben, sind sie somit kosteneffektiv. Jedoch sind die verwendeten Performanzzähler-Events speziell in der verwendeten CPU enthalten und bieten deshalb keine Grundlage zur Verallgemeinerung. Aus diesem Grund sind die entwickelten Energiemodelle bedingt übertragbar. Mantis Modellierung des Systemweiten Stromverbrauchs Economou et al. (2006) entwickeln Mantis, ein Tool zur Ermittlung des Energieverbrauchs einer auf einem Server laufenden Anwendung, das auf einem Energiemodell basiert. Das Tool besteht aus einem 3-phasigen Ablauf. Die erste Phase besteht darin, das Energiemodell zu kalibrieren. Dazu werden die einzelnen Hardwarekomponenten des Servers (CPU, Memory, Disk, Netzwerk) mit hardwarekomponentenbezogenen Benchmarks ausgelastet und sowohl die Auslastung der Hardwarekomponenten als auch der Stromverbrauch gemessen. Die Auslastung wird mittels Performanzzählern und Auslastungskennzahlen auf Systemebene (CPU- Auslastung und Lese- und Schreibzugriffe der Festplatte) über das Betriebssystem ermittelt. Der Stromverbrauch muss dabei (sofern benötigt) mittels externer Messgeräte gemessen werden. Der Stromverbrauch wird sowohl bei Belastung als auch im Ruhezustand gemessen. Anschließend werden Auslastung und Stromverbrauch in der zweiten Phase aufeinander abgebildet. Diese Abbildungen werden für die spätere Energiemodellierung abgespeichert. In der dritten Phase kann dann eine Anwendung nach Wahl ausgeführt und anhand der Auslastung kann der Energieverbrauch sowohl des gesamten Systems als auch jeder einzelnen Hardwarekomponente ermittelt werden. In ihren Untersuchungen haben Economou et al. (2006) Mantis auf zwei grundlegend verschiedene Hardwarekonfigurationen untersucht. Die Energiemodelle entsprechen der Form der linearen Regression. Bei beiden Energiemodellen ist ersichtlich, dass die Anteile von Festplatte und Netzwerkkomponenten am Gesamtstromverbrauch minimal sind. Mantis wurde für 30 verschiedene sowohl synthetische als auch kommerzielle Benchmarks getestet. Mit einem 90%-Quantil (bezüglich der Fehlerrate) von unter 10% gilt Mantis gemäß einem idealen Energiemodell als genau. Jedoch muss eine Kalibrierungsphase durchlaufen werden, die aus mehreren Einzel-Kalibrierungstestläufen besteht, da für jede Hardwarekomponente ein individueller Kalibrierungstestlauf durchgeführt werden muss. Zudem muss die zugrundeliegende Hardware instrumentiert werden: zum einen muss jede der betrachteten Hardwarekomponenten mit einem Messgerät versehen werden und zum anderen muss ein Analyse-Computer installiert werden, der einerseits die Messdaten ausliest und zum anderen 9 Vgl. Kapitel 2.5 (Energiemodell) 40

50 die Kalibrierung des Energiemodells übernimmt wodurch Mantis nicht kosteneffektiv ist. Der Hardwarebedarf wird einerseits über Auslastungskennzahlen und andererseits über Performanzzähler ermittelt. Da Mantis benötigte Performanzzähler-Events über Betriebssystemeigene Software ausliest, ist Mantis, obwohl der bedingten Übertragbarkeit-Eigenschaft von Performanzzählern, übertragbar. Mercury Temperaturermittlung und -management in Server Systemen Heath et al. (2006) haben Mercury, ein softwarebasiertes Framework zur Ermittlung und zum Management von Temperatur in Server Systemen, entwickelt. Mercury basiert auf einem eigens entwickelten Temperaturmodell. Mercury ermittelt auf Basis des zugrundeliegenden Temperaturmodells die Temperatur ausgewählter Hardwarekomponenten. Es werden ausschließlich die CPU, die Festplatte und die Netzwerkkomponenten berücksichtigt. Das Temperaturmodell ermittelt die hardwarekomponentenspezifische Temperatur anhand des gemessenen Energieverbrauchs der Hardwarekomponente und dem Zeitrahmen der Messung. Das Energiemodell basiert auf der Metrik Hardwareauslastung. Der Energieverbrauch P einer Hardwarekomponente bei Hardwareauslastung u wird dabei wie folgt ermittelt. P(u) = P idle + u * (P max - P idle ), wobei P idle für den Energieverbrauch der Hardwarekomponente im Ruhezustand und P max für den Energieverbrauch der Hardwarekomponente unter Maximalauslastung stehen. Die benötigte Hardwareauslastung wird mittels des Betriebssystems ausgelesen. Die Fehlerrate von Mercury liegt bei weniger als 10%. Der ermittelte Energieverbrauch im Temperaturmodell ist direkt proportional zu der ermittelten Temperatur. Da die Fehlerrate unter 10% liegt, ist somit das zugrundeliegende Energiemodell als genau einzustufen. Bezüglich des Energiemodells muss lediglich die Hardwareauslastung im Betriebssystem ausgelesen werden. Da z.b. auf Linux Betriebssystemen das Tool sar 10 laufend entsprechende Daten misst und für spätere Auswertungszwecke offline speichert, ist kein zusätzlicher Instrumentierungsaufwand bzw. keine Mehrbelastung durch Messung erforderlich, um entsprechende Werte zu ermitteln. Somit ist das Energiemodell kosteneffektiv. Dadurch, dass die zu ermittelnden Werte über das Betriebssystem zu ermitteln sind, ist das Energiemodell leicht auf anderen Systemen auszuführen und somit übertragbar. Vergleich von High-Level-Energiemodellen Rivoire et al. (2008) vergleichen verschiedene Energiemodelle. Die untersuchten Energiemodelle gehören zu den High-Level-Energiemodellen, da sie nicht detailliert (Low-Level), sondern oberflächig (High-Level) den Energieverbrauch einer Anwendung ermitteln. Da detaillierte Energiemodelle tiefergehende Kenntnisse nicht nur über die ausgeführte Anwendung sondern auch über die zugrundeliegende Hardware (z.b. Performanzzähler) vorrausetzen, sind High-Level-Energiemodelle zur Energieermittlung ohne großen Mehraufwand von Anwendungen eher geeignet. 10 Vgl. Kapitel 2.4 (Performanz-Metrik Hardwareauslastung ) 41

51 Das erste Energiemodell, dass Rivoire et al. (2008) zur Untersuchung heranziehen, ist ein konstantes Energiemodell, dass nach einem anfänglichen Kalibrierungsdurchlauf den durchschnittlichen Energieverbrauch festhält. Das zweite Energiemodell ist ein auslastungsbasiertes Energiemodell, dass linear auf der CPU-Auslastung u basiert: (u) α + β u, wobei α und β Konfigurationsparameter sind und mittels Kalibrierung ermittelt werden. Das dritte Energiemodell ähnelt dem zweiten darin, dass es einen empirischen Term β 2 * u r anhängt und somit nicht mehr linear ist: (U) α + β 1 * u + β 2 * u r, wobei r, α und die β-werte wiederum durch vorherige Kalibrierung ermittelt werden. Das vierte Energiemodell ermittelt den Energieverbrauch der Anwendung linear, indem einerseits die CPU-Auslastung und andererseits die Auslastung der Festplatte berücksichtigt werden. Im fünften Energiemodell werden neben der CPU-Auslastung und der Auslastung der Festplatte zusätzlich noch ausgewählte Performanzzähler berücksichtigt. Die verwendeten Performanzzähler ermitteln die Arbeitsspeicher- Bandbreite, die Größe des Parallelismus auf Instruktionsebene, die Aktivität der Cache- Speicherhierarchie und die Auslastung der Gleitkommazahl-Einheit. Die durchschnittliche Fehlerrate der verwendeten Energiemodelle liegt unter 10%. In Abbildung 9 werden die jeweiligen Fehlerraten der verwendeten Energiemodelle unter verschiedenartigen Benchmarks dargestellt. Lediglich das konstante Energiemodell ( Const ) weist nicht nur die größte Fehlerrate sondern auch eine Fehlerrate über 10% auf, da es keine großen Schwankungen korrekt abzubilden vermag. Von den linearen Energiemodellen ( CPUut-Lin bzw. CPU+Disk ) ist das CPU- und Festplatte-basierte Energiemodell durchschnittlich genauer. Am zweitgenauesten ist das empirische Energiemodell ( CPUut-Emp ). Das Energiemodell ( Perfctr ), das sowohl CPU- und Festplatten-Auslastung als auch Performanzzähler berücksichtigt, ist am genauesten der untersuchten Energiemodelle. Abbildung 9: Fehlerrate von High-Level-Energiemodellen Quelle: (Rivoire et al. 2008, 3) Rivoire et al. (2008) schließen mit verschiedenen Erkenntnissen ab. Zum einen sind Energiemodelle, die ausschließlich die CPU bezüglich des Energieverbrauchs als dominante Hardwarekomponente betrachten, bei heutiger Entwicklung der Bauweise der CPU ungenau. Die fünf verschiedenen Energiemodelle wurden auf verschiedenen Hardwarekonfigurationen 42

52 untersucht. Es wurden ein Server mit leistungsstarker CPU und Arbeitsspeicher, ein Server mit leistungsdurchschnittlicher CPU und geringem Arbeitsspeicher, ein mobiler Dateiserver in zwei Konfigurationen, einmal mit mehreren Festplatten und einmal mit einer Festplatte, und ein Notebook untersucht. Auf dem leistungsstarken Server erwies sich das empirische Energiemodell als das genaueste Energiemodell, da der leistungsstarke Server durch die CPU bezüglich seines Energieverbrauchs dominiert wurde. Zum anderen liefern Energiemodelle, die Hardwarekomponenten, die einen signifikanten Einfluss auf den Energieverbrauch haben, missachten, bei Workloads, die hauptsächlich ebensolche Hardwarekomponenten auslasten, ungenaue Ergebnisse. Ein weiterer zu beachtender Aspekt ist die unterschiedliche Implementierung von Performanzzählern unterschiedlicher Hersteller. Zwar existieren bestimmte Performanzzähler auch bei CPUs unterschiedlicher Hersteller, jedoch ist durch einen unterschiedlichen Aufbau ein Vergleich nicht möglich, wodurch somit detailliertes Wissen über unterschiedliche Hardware von Nöten ist. Ein weiterer Aspekt ist das Fehlen von Schnittstellen zu detaillierten Informationen (wie z.b. Performanzzählern bei der CPU) zur genaueren Ermittlung von Energieverbräuchen von Festplatte und Arbeitsspeicher. 4.2 Diskussion Aus den vorgestellten Werken zur Ermittlung des Energieverbrauchs anhand bestimmter Methoden geht hervor, dass zwei Faktoren bei der Ermittlung des Energieverbrauchs von Software anhand von Informationen über den Hardwarebedarf von Software sich herauskristallisieren. Diese Faktoren sind 1. Auswahl des Energiemodells und 2. Auswahl der Methodik zum Auslesen des Hardwarebedarfs. Auswahl des Energiemodells Bei der Auswahl des Energiemodells muss entschieden werden, ob ein detailliertes oder ein oberflächliches Energiemodell ausreicht. Je detaillierter ein Energiemodell ist, desto genauer kann es den Energieverbrauch von Software ermitteln. Mit einem großen Grad an Genauigkeit, steigt das Maß an Informationen, die für das detaillierte Energiemodell benötigt werden. Somit ist ein fundiertes Wissen über sowohl Hardware als auch über die auszuführende Software von Nöten. Um dies zu umgehen, können oberflächliche Energiemodelle zur Ermittlung des Energieverbrauchs von Software verwendet werden. Aufgrund einer geringen Variation in der Art der zu übergebenen Parameter, bedarf es an weniger hardware- bzw. softwarespezifischem Wissen zur korrekten Anwendung des Energiemodells. Oberflächliche Energiemodelle tendieren dazu, größere Schwankungen nicht genau abbilden zu können, wodurch ein gewisses Maß an Ungenauigkeit entsteht. Auswahl der Methodik zum Auslesen des Hardwarebedarfs Zum Befüllen eines ausgewählten Energiemodells mit Parametern, müssen die benötigten Werte ermittelt werden. Es wird zwischen detaillierten und einfachen Methoden zum Auslesen der Informationen über den Hardwarebedarf von Software unterschieden. Werden detaillierte Informationen benötigt, so können mit z.b. Performanzzählern hardwarekomponentenspezifische und -detaillierte Informationen gewonnen werden. Zur korrekten Zuord- 43

53 nung der möglichen Performanzzähler-Events zu den Operationen, die durch die ausgeführte Software angestoßen werden, sind sowohl detaillierte Hardware- als auch Software- Kenntnisse erforderlich. Eine sowohl hardware- als auch herstellerabhängige Implementierung von Performanzzählern erschwert zudem eine allgemeine Herangehensweise ohne spezifisches Detailwissen über die zugrundeliegende Hardware. Zur Vermeidung von benötigtem Detailwissen, ist es möglich anhand einfacher Methoden, weniger detaillierte Informationen über den Hardwarebedarf von Software zu gewinnen. Durch die Verwendung von z.b. Betriebssystem eigenen Tools ist es einfach (Yanfei et al. 2012), die hardwarekomponentenspezifische Auslastung zu ermitteln. Da jedoch das Betriebssystem selbst Auswirkungen auf den Energieverbrauch hat (Li/John 2003), wird die angezeigte Hardwareauslastung durch Betriebssystem eigene Prozesse beeinflusst. Im Folgenden werden die zwei genannten Faktoren im Sinne der Ermittlung des Energieverbrauchs einer Unternehmensanwendung diskutiert. Zur Senkung von Betriebskosten durch z.b. den Betrieb von Hardware, können Unternehmen ihre Unternehmensanwendung von einem Dienstleister hosten lassen. Der Dienstleister kann mittels Virtualisierung die verfügbare Hardware je nach dem Hardwarebedarf der zu hostenden Unternehmensanwendungen anpassen, wodurch die exakte Konfiguration und Zusammenstellung der zugrundeliegenden Hardware einerseits durch die Virtualisierung und andererseits durch die dynamische Anpassung dem Unternehmen verborgen bleiben kann. Dadurch kann für ein Unternehmen eine Aneignung detaillierter Kenntnisse über die zugrundeliegende Hardware erschwert werden. Da somit eine Ermittlung von Informationen über den Hardwarebedarf der Unternehmensanwendung mittels detaillierter Methoden (z.b. Performanzzähler) nicht möglich ist, sind einfachere Methoden eher geeignet. Die Ermittlung des Hardwarebedarfs von Software ist durch z.b. das Betriebssystem ohne tiefergehende Kenntnisse einfach zu erreichen. Somit empfiehlt es sich zudem oberflächliche Energiemodelle den detaillierten Energiemodellen im Unternehmensumfeld vorzuziehen, da benötigte Werte mit weniger Aufwand zu ermitteln sind. Im nachfolgenden Kapitel werden oberflächliche Energiemodelle dargestellt, die den Energieverbrauch von Software anhand von Performanzmetriken bezüglich Hardware, die durch das Betriebssystem auslesbar sind, ermitteln. Somit ist gewährleistet, dass ohne spezifische und detaillierte Kenntnisse, die Modellierung des Energieverbrauchs einer zu untersuchenden Unternehmensanwendung durchführbar ist. 4.3 Von Hardwareauslastung durch Software zum Energieverbrauch von Software Charakterisierung des Stromverbrauchs von Servern Hsu/Poole (2011) analysieren das Verhalten des Stromverbrauchs von Servern aus mehr als 170 Resultaten aus der Ausführung des SPECpower_ssj2008 Benchmarks (Standard Performanz Evaluation Corporation 2013) auf Servern aus dem Zeitraum von 2007 bis Der SPECpower_ssj2008 Benchmark lastet alle IT-Ressourcen gleichmäßig aus. Die Analyse ergab, dass sich das Verhalten von Servern Hinsichtlich ihrer Beziehung von Stromverbrauch und Hardwarebedarf von SPECpower_ssj2008 im Laufe des Untersuchungszeitraumes von einer linearen Beziehung zu einer nicht-linearen Beziehung hin entwickelt hat. 44

54 Die lineare Funktion (u) idle + ( peak idle) u Formel 5: Lineare Beziehung zwischen Stromverbrauch und Auslastung Quelle: (Hsu/Poole 2011, 230) zur Ermittlung des Energieverbrauchs von Servern P(u) für eine bestimmte Auslastung u, basierend auf den Werten Stromverbrauch P idle im Ruhezustand und dem Stromverbrauch P peak unter maximaler Auslastung, ist eine verbreitete Formel zur genauen Ermittlung des Energieverbrauchs von Servern (Fan et al. 2007). Das US Department of Energy rät zur Ermittlung des Energieverbrauchs von Servern zu dieser Funktion (Hsu/Poole 2011), da Formel 5 mit wenigen Parametern den Energieverbrauch abzuschätzen vermag. Die Analyse der Resultate jedoch zeigt, dass es im Laufe dieser vier Jahre immer schwieriger geworden ist, den genauen Energieverbrauch vorherzusagen. Die Fehlerrate betrug bis zu 40%. Für Formel 5 fallen weniger als 40% der Resultate in den 0%-5%-Fehlerbereich. Dies liegt zum einen an intensiven Energiesparfunktionen der zugrundeliegenden Hardware (CPU-Ebene: Dynamic Voltage and Frequency Scaling (DVFS); Server-Ebene: Abschalten nicht gebrauchter, einzelner Server). Zum anderen liegt dies daran, dass der Hardware-Trend in Richtung von weniger CPU-dominierter Hardware geht und somit die lineare Formel nicht mehr in der Lage ist, weiterhin exakt den Energieverbrauch von Servern durch eine Abnahme der anteiligen Gewichtung der Hauptbemessungsgrundlage, die CPU, zu ermitteln. Um die Genauigkeit aufrechtzuerhalten, wurde die lineare Beziehung (vgl. Formel 5) zwischen Auslastung und Stromverbrauch in die nicht-lineare Funktion (u) idle + ( peak - idle) ( u - u ) mit einem Kalibrierungsfaktor α weiterentwickelt. Mit dieser Funktion fallen 60% der Resultate in den 0%-5%-Fehlerbereich, was zu einer deutlichen Steigerung der Genauigkeit der Vorhersage des Stromverbrauchs führt (vgl. Formel 5). Eine weniger komplexe, jedoch genauere Funktion ist (u) idle + ( peak - idle) u, wodurch alle Resultate unabhängig vom Kalibrierungsfaktor α in den 0%-10%- Fehlerbereich und 80% der Resultate in den 0%-5%- Fehlerbereich fallen. Die Analyse von jedem Resultat in Bezug auf α hat ergeben, dass die Mehrheit der Resultate ein α von, hat. Dies führt schließlich zu der Funktion (u) idle + ( peak - idle) u. Formel 6: Nicht-lineare Beziehung zwischen Stromverbrauch und Auslastung Quelle: (Hsu/Poole 2011, 232) Mit Formel 6 fallen alle Resultate in den Fehlerbereich von 0%-24% und 71% der Resultate fallen in den 0%-10%-Fehlerbereich. Stromverbrauch von Hardwarekomponenten eines Servers Basmadjian et al. (2011) entwickeln Energiemodelle zur Ermittlung des Stromverbrauchs von Hardwarekomponenten eines Servers auf Basis ihrer Auslastung. Es werden dabei die folgenden Hardwarekomponenten berücksichtigt: die CPU, der Arbeitsspeicher, die Festplatte, das Mainboard, der Lüfter und das Netzteil. Für die CPU gilt eine lineare Beziehung zwischen Energieverbrauch und Auslastung (Fan et al. 2007). Der Stromverbrauch P CPU einer CPU bei Auslastung L ergibt sich wie folgt: 45

55 C U idle+ ( max - idle) (L ), Formel 7: Stromverbrauch einer Single-Kern-CPU Quelle: (Basmadjian et al. 2011, 5) wobei P max der Stromverbrauch der CPU unter Maximalauslastung (100%) und P idle der Stromverbrauch der CPU im Ruhezustand (0% Auslastung) sind. Da Formel 7 lediglich für CPUs mit nur einem Rechenkern (Single-Kern-CPU) bestimmt ist, gilt es Formel 7 für komplexere CPUs, die mehrere Rechenkerne beinhalten, anzupassen. Basmadjian et al. geben für die Ermittlung des Stromverbrauchs einer solchen Multi-Kern-CPU die folgende Funktion an: n P CPU = P idle + i Ci, Formel 8: Stromverbrauch einer Multi-Kern-CPU Quelle: (Basmadjian et al. 2011, 5) wobei der Stromverbrauch eines Rechenkerns C i und n die Anzahl der Rechenkerne einer Multi-Kern-CPU sind. Für den Stromverbrauch P C eines Rechenkerns C gilt ebenfalls der lineare Zusammenhang zwischen Auslastung und Energieverbrauch: P C = P max * (L C /100), Formel 9: Stromverbrauch eines Rechenkerns Quelle: (Basmadjian et al. 2011, 5) wobei P max der Stromverbrauch des Rechenkerns C unter Maximalauslastung (100%) und L C die Auslastung des Rechenkerns C sind. Der Stromverbrauch im Ruhezustand P idle einer CPU ist einerseits der Herstellerangabe zu entnehmen. Andererseits lässt sich P idle wie folgt ermitteln (Basmadjian et al. 2012): n t i i j, idle ji ji Formel 10: Stromverbrauch einer CPU im Ruhezustand Quelle: (Basmadjian et al. 2012, 4) wobei n die Anzahl der Rechenkerne, t i die Anzahl (in Mio.) an Transistoren eines Rechenkernes i, I ji die Stromstärke eines Transistors j und V ji die Spannung eines Transistors j sind. Enthält die CPU Energiesparfunktionen (z.b. DVFS), so wird Formel 10 um einen entsprechenden Energiesparfaktor δ i für einen Rechenkern i ergänzt: n t i i j ). idle i ( ji ji Formel 11: Stromverbrauch einer CPU im Ruhezustand inkl. Energiesparfunktion Quelle: (Basmadjian et al. 2012, 4) Der Energiesparfaktor δ i eines Rechenkerns i wird wie folgt ermittelt: i β i1 i + β i2 V i + β i3, wobei V i die Betriebsspannung des Rechenkerns i bei n Rechenkernen einer CPU ist und β ij, i {,, n} und j {,, }, die Energiekoeffizienten sind, deren Werte in Tabelle 1 für eine durch DVFS gesetzte Frequenz f i gegeben sind. Eine in Tabelle 1 angegebene Frequenz f 0,x entspricht dabei x% von der maximalen Frequenz f max eines Rechenkerns. Interessanterweise ergaben Tests von Basmadjian et al. (2011), dass der Stromverbrauch der CPU unter Linux Betriebssystemen höher ist, als unter Windows Betriebssystemen, da, von den geteste- 46

56 ten Betriebssystemen, Windows stärkere CPU-Energiesparfunktionen implementiert als Linux. Frequenz-Bereich β i1 β i2 β i3 f min < f i f 0,25 0, , ,60751 f 0,25 < f i f 0,68-1, , ,48657 f 0,68 < f i f 0,81-0, , ,56800 f 0,81 < f i f max - 0, , ,26095 Tabelle 1: Frequenzbereiche und Energiekoeffizienten Quelle: (Basmadjian et al. 2012, 5) Für den Arbeitsspeicher, RAM (Random Access Memory), existieren verschiedene Technologien. Basmadjian et al. (2011) fokussieren auf Synchronous Dynamic RAM (SDRAM). Für SDRAM existieren wiederum unterschiedliche Typen (z.b. DDR 2, DDR 3, etc.) unterschiedlicher Technologien (unbuffered und (fully-)buffered). Der Stromverbrauch P RAM_unbuff_DDR2 von unbuffered DDR 2 Arbeitsspeicher ergibt sich wie folgt: RAM unbuff DDR RAM idle +,, Formel 12: Stromverbrauch von unbuffered DDR 2 Arbeitsspeicher Quelle: (Basmadjian et al. 2011, 6) wobei P RAM_idle der Stromverbrauch des Arbeitsspeichers im Ruhezustand ist und γ [0,1] gilt. Der Wert von γ wird wie folgt ermittelt. Wenn sich die CPU im Ruhezustand befindet, entspricht γ gleich 0. Ansonsten gilt: je höher der verbrauchte Speicher des Arbeitsspeichers ist, desto größer ist die Wahrscheinlichkeit, dass ein Zugriff auf den Arbeitsspeicher erfolgt (γ = Arbeitsspeicherauslastung / 100). Der Stromverbrauch eines Arbeitsspeichers im Ruhezustand lässt sich wie folgt ermitteln: n RAM idle i s i f i c i, Formel 13: Stromverbrauch von Arbeitsspeicher im Ruhezustand Quelle: (Basmadjian et al. 2012, 5) wobei n die Anzahl an Arbeitsspeicher-Modulen, s i die Größe eines Arbeitsspeicher-Moduls i, f i die Frequenz eines Arbeitsspeicher-Moduls i, c = 0,00043 für DDR 2 Arbeitsspeicher bzw. c = 0,00013 für DDR 3 Arbeitsspeicher und die quadrierte Betriebsspannung eines Arbeitsspeicher-Moduls i sind. Wenn die CPU sich im Ruhezustand befindet, gilt γ = 0. Ansonsten beträgt der Wert von γ in etwa der Wahrscheinlichkeit, dass abhängig vom Speicherverbrauch des Arbeitsspeichers, auch ein Zugriff auf den Arbeitsspeicher erfolgt. Für einen buffered DDR 2 Arbeitsspeicher lässt sich der Stromverbrauch wie folgt ermitteln: RAM buff DDR RAM idle +,,, Formel 14: Stromverbrauch von buffered DDR2 Arbeitsspeicher Quelle: (Basmadjian et al. 2011, 6) wobei P RAM_idle und γ gemäß den entsprechenden Werten in Formel 12 zu berechnen sind. Der Stromverbrauch P RAM_unbuff_DDR3 von unbuffered DDR 3 Arbeitsspeicher wird wie folgt ermittelt: 47

57 RAM unbuff DDR RAM idle +,,, Formel 15: Stromverbrauch von unbuffered DDR 3 Arbeitsspeicher Quelle: (Basmadjian et al. 2011, 6) wobei P RAM_idle und γ gemäß den Werten in Formel 12 zu berechnen sind. Für buffered DDR 3 Arbeitsspeicher ergibt sich der Stromverbrauch P RAM_buff_DDR3 wie folgt: RAM buff DDR RAM idle +,,, Formel 16: Stromverbrauch von buffered DDR 3 Arbeitsspeicher Quelle: (Basmadjian et al. 2011, 6) wobei P RAM_idle und γ gemäß den entsprechenden Werten in Formel 12 zu berechnen sind. Der Stromverbrauch der Festplatte basiert auf den Anteilen der drei Phasen Ruhephase, Zugriffsphase und Startphase (Basmadjian et al. 2011). Wenn keine Zugriffe erfolgen, befindet sich die Festlatte in der Ruhephase. Wenn Lese- bzw. Schreiboperationen erfolgen, befindet sich die Festplatte in der Zugriffsphase. Die Festplatte befindet sich in der Startphase, wenn alle ihre mechanischen Teile aktiviert werden. Der Stromverbrauch P HDD_idle der Ruhephase lässt sich in die drei Status Ruhestatus, Wartestatus und Schlafstatus unterteilen, wobei sich der Warte- und der Schlafstatus bezüglich ihres Stromverbrauchs gleichen und ihr Stromverbrauch jeweils etwa 10% des Stromverbrauchs im Ruhezustand entspricht. Der Stromverbrauch P HDD_idle einer Festplatte im Ruhezustand ergibt sich somit wie folgt: HDD idle idle (α +, β), Formel 17: Stromverbrauch einer Festplatte im Ruhezustand Quelle: (Basmadjian et al. 2011, 7) wobei P idle der Stromverbrauch der Festplatte während des Ruhestatus ist (Herstellerangabe), α [0,1] der Wahrscheinlichkeit entspricht, dass sich die Festplatte im Ruhestatus befindet, und β [0,1] der Wahrscheinlichkeit entspricht, dass sich die Festplatte im Warte- oder im Schlafstatus befindet. Der Stromverbrauch P HDD einer Festplatte lässt sich wie folgt ermitteln: HDD a, idle + b HDD idle + c, idle, Formel 18: Stromverbrauch einer Festplatte Quelle: (Basmadjian et al. 2011, 7) wobei a, b, c [0,1] für die Wahrscheinlichkeiten stehen, dass sich die Festplatte in der Zugriffsphase bzw. der Ruhephase bzw. der Startphase befindet und P idle der Stromverbrauch der Festplatte während des Ruhestatus ist (Herstellerangabe). Auf Basis der aktuellen Lese- (reads) bzw. Schreibraten (writes) werden für die Wahrscheinlichkeiten a, b und c wie folgt ermittelt. Sind reads und writes gleich 0, befindet sich die Festplatte in der Ruhephase (b = 1, a = c = 0). Ansonsten gilt: Sind reads und writes größer als 0, dann ist a gleich dem Quotient aus der Summe von reads und writes und der Summe von der maximal möglichen Lese- ( maxreads ) und der Schreibrate ( maxwrites ) der Festplatte, sind writes gleich 0, dann ist a gleich dem Quotient aus reads und maxreads, 48

58 sind reads gleich 0, dann ist a gleich dem Quotient aus writes und maxwrites. Weiterhin gilt b = 0,9 * (1 - a) und c = 0,1 * (1 - a). Für α bzw. β gilt: 0 < b, α,, β,. 0,3 < b, α β,5. 0,6 < b α,, β,. Das Mainboard ist die zentrale Einheit eines Servers, in der viele bedeutsame Hardwarekomponenten eines Servers verbunden sind (Basmadjian et al. 2011). Der Stromverbrauch P Mainboard des Mainboards ergibt sich wie folgt: l Mainboard C U Formel 19: Stromverbrauch eines Mainboards Quelle: (Basmadjian et al. 2012, 7) m i + RAM + j C + k HDD + c, wobei P CPU (vgl. Formel 8) der Stromverbrauch einer CPU bei l CPUs im Server, P RAM (vgl. Formel 12, Formel 14 - Formel 16) der Stromverbrauch des Arbeitsspeichers, P NIC der Stromverbrauch einer Netzwerkkarte bei m Netzwerkkarten im Server, P HDD (vgl. Formel 18) der Stromverbrauch einer Festplatte bei n Festplatten im Server sind und c = 40 für Tower- und Rack-Servern bzw. c = 55 für Blade-Servern gilt. Der Stromverbrauch eines Lüfters hängt von seinem Durchmesser d, seiner Tiefe t und seiner Umdrehungszahl a ab (Basmadjian et al. 2011). Der Stromverbrauch P Fan eines Lüfters ergibt sich wie folgt: P Fan = 8,33068 * * a 4 + 8,51757 * d 4 2,9569 * t 4 1,10138 * * a ,6855 * d 3 76,4897 * t 3 + 4,85429 * 10-7 * a ,847 * d ,02 * t 2 6,06127 * 10-5 * a + 32,6862 * d + 67,3012 * t 5,478. Formel 20: Stromverbrauch eines Lüfters Quelle: (Basmadjian et al. 2011, 7) Der Stromverbrauch eines Netzteils basiert auf seiner Energieeffizienz e (Basmadjian et al. 2011). Der Stromverbrauch P PSU eines Netzteils PSU ergibt sich wie folgt: n SU Formel 21: Stromverbrauch eines Netzteils Quelle: (Basmadjian et al. 2011, 8) measured ( - e), wobei P measured für den durch das Netzteil gemessenen Stromverbrauch steht. Der gesamte Stromverbrauch eines Servers richtet sich nach seiner Bauweise. Für Blade- Server ergibt sich der Stromverbrauch P Server wie folgt: 49

59 l Server i Mainboard, Formel 22: Stromverbrauch eines Blade-Servers Quelle: (Basmadjian et al. 2011, 8) wobei P Mainboard (vgl. Formel 19) für den Stromverbrauch eines Mainboards bei l Mainboards des Servers steht. Für Tower- und Rack-Server ergibt sich der Stromverbrauch P Server wie folgt: l Server Mainboard m n k, i + j Fan + SU Formel 23: Stromverbrauch eines Tower- bzw. Rack-Servers Quelle: (Basmadjian et al. 2011, 8) wobei P Mainboard (vgl. Formel 19) für den Stromverbrauch eines Mainboards bei l Mainboards des Servers, P Fan (vgl. Formel 20) für den Stromverbrauch eines Lüfters bei m Lüftern des Servers und P PSU (vgl. Formel 21) für den Stromverbrauch eines Netzteils bei n Netzteilen des Servers stehen. Basmadjian et al. (2011) untersuchen die entwickelten Energiemodelle auf jeweils einem Blade- und einem Tower-Server. Für den Blade-Server ergeben sich eine Fehlerrate von 2% bei einer CPU-Auslastung von 90% und eine Fehlerrate von 9% bei einer CPU-Auslastung von weniger als 60%. Für den Tower-Server ergeben sich Fehlerraten von 6% bei einer CPU- Auslastung von mehr als 60% und eine Fehlerrate von 8% für eine CPU-Auslastung von weniger als 60%. Somit gelten die Energiemodelle als genau. Energiemodell für virtuelle Maschinen Yanfei et al. (2012) haben ein Energiemodell für virtuelle Maschinen entwickelt. Auf Basis der Auslastung von IT-Ressourcen wird mittels des Energiemodells der Stromverbrauch eines Servers anhand der Ermittlung der Stromverbräuche aller auf dem Server laufenden virtuellen Maschinen ermittelt. Der Stromverbrauch P Server eines Servers wird wie folgt ermittelt: n Server idle + i M (i), Formel 24: Stromverbrauch eines Servers auf Basis virtueller Maschinen Quelle: (Yanfei et al. 2012, 176) wobei P idle der Stromverbrauch des Servers im Ruhezustand, n die Anzahl an laufenden virtuellen Maschinen und P VM (i) der Stromverbrauch einer virtuellen Maschine i sind. Der Stromverbrauch P VM einer virtuellen Maschine wird wie folgt ermittelt: M α U C U + β U MEM + U O + e, Formel 25: Stromverbrauch einer virtuellen Maschine Quelle: (Yanfei et al. 2012, 176) wobei U CPU die CPU-Auslastung, U MEM die Arbeitsspeicher-Auslastung, U IO die Festplatten- Auslastung einer virtuellen Maschine sind und die Konfigurationsparameter α, β, γ und e mittels linearer Regression ermittelt werden können. 50

60 Das Energiemodell ist für eine online (Anwendung im laufenden Betrieb) Ermittlung des Stromverbrauchs konzipiert. Da der Stromverbrauch des Servers nicht proportional zur Anzahl der laufenden virtuellen Maschinen ist (Yanfei et al. 2012), wird das Energiemodell (vgl. Formel 24) für jede neu hinzugefügte virtuelle Maschine angepasst und ein individuelles Energiemodell (vgl. Formel 25) für jede virtuelle Maschine angelegt. Yanfei et al. (2012) untersuchten ihr Energiemodell auf einem leistungsstarken Testserver. Der Mehraufwand betrug weniger als 1% (kosteneffektiv) und die Fehlerrate maximal 10% (genau). Diese Eigenschaften und die Tatsache gegeben, dass benötigte Performanzmetriken über das Betriebssystem ausgelesen werden können (übertragbar), ist das Energiemodell somit als ein ideales Energiemodell einzustufen. 51

61 5 Evaluation Der Beantwortung von FF3 widmet sich dieses Kapitel. In Kapitel 5.1 werden sowohl der Aufbau des Experiments als auch die Durchführung der Messungen beschrieben. Anschließend werden in Kapitel 5.2 Messergebnisse dargestellt und in Kapitel 5.3 die Korrelation zwischen IT-Ressourcenauslastung einer beispielhaften Unternehmensanwendung und dem Energieverbrauch einer beispielhaften Unternehmensanwendung angeführt. Anschließend werden in Kapitel 5.4 ausgewählte Forschungsergebnisse aus Kapitel 4.3 mittels experimenteller Daten evaluiert. In Kapitel 5.5 werden gewonnene Aussagen zusammengefasst. 5.1 Experimentaufbau und Messdurchführung Zur Untersuchung einer beispielhaften Unternehmensanwendung wird der SPECjEnterprise2010 Benchmark (Standard Performance Evaluation Corporation 2012b) verwendet. Der SPECjEnterprise2010 Benchmark besteht aus dem Faban Lastreiber und einer Unternehmensanwendung 11. In Abbildung 10 wird der Aufbau des Experiments schematisch dargestellt. Der für das Testsystem verwendete Applikations-Server ist ein JBoss (Red Hat GmbH o.j.) Applikations-Server. Der für die Unternehmensanwendung verwendete Datenbankserver ist eine Apache Derby (Apache Software Foundation 2013) Datenbank. Sowohl der Lasttreiber als auch das Testsystem (Unternehmensanwendung inkl. Datenbank, Applikationsserver) laufen auf dem Betriebssystem OpenSuse 12.3 (SUSE Linux Products GmbH 2013). Der Lastreiber inkl. Betriebssystem bzw. das Testsystem inkl. Betriebssystem werden jeweils in einer eigenen virtuellen Maschine durch einen VMware ESXi Hypervisor (VMware Global Inc. 2012) virtualisiert. Die zugrundeliegende Hardware besteht aus leistungsstarken IBM System X x3755 M3 (IBM Corporation o.j.) Servern. Die genannten Server sind Rack-Server. Die Last-VM (Lasttreiber inkl. Betriebssystem) wird auf einem separaten Server gehostet, während die Test-VM (Testsystem inkl. Betriebssystem) exklusiv auf einem eigenen Server ( Test-Server ) gehostet wird. Die Test-VM verfügt aus lizenzrechtlichen Gründen über vier virtuelle CPUs. In dem der Test-VM zugrundeliegenden Server sind vier AMD 6172 (Advanced Micro Devices Corporation o.j.-b) CPUs mit jeweils 12 Rechenkernen verbaut. Der Test-Server verfügt über 32 fully-buffered DDR 3 Arbeitsspeicher-Module mit jeweils 8 GB Datenkapazität und zwei 110W-Netzteilen. Im Test-Server sind keine Festplatten eingebaut, sondern es werden Dateien mittels SAN-Anschluss von bzw. zu einem SAN übertragen. Zur Messung von IT-Ressourcenauslastung und Energieverbrauch kommen unterschiedliche Technologien zum Einsatz. Der Energieverbrauch wird mittels dem Intelligent Platform Management Interface (IPMI) (Intel Corporation 2013b) direkt am Test-Server gemessen (vgl. Abbildung 10). Mit IPMI ist es möglich, einen Server zu warten und zu verwalten. Außerdem kann mittels IPMI eine automatische Fehlerbenachrichtigung eingerichtet werden, falls z.b. eine Festplatte ausgefallen oder die Temperatur der CPU zu hoch ist. IPMI ermöglicht die Messung des Stromverbrauchs des Test-Servers, denn die verwendeten IBM Server 11 Vgl. Kapitel 2.3 (Benchmark S ECjEnterprise ) 52

62 haben Strommessgeräte integriert, die mit IPMI-Schnittstellen ausgerüstet sind. Dies ermöglicht das Auslesen der Daten bezüglich des Stromverbrauchs ohne externe Messgeräte oder andere Werkzeuge, da IPMI z.b. mittels der IPMI Library for Java (Verax Systems Corporation o.j.) aus der Ferne angesteuert werden kann. Abbildung 10: Architektur des Experiments Quelle: Eigene Darstellung Die IT-Ressourcenauslastung wird mittels ESXTOP (VMware Global Inc. 2009, ) ausgelesen. ESXTOP liefert detaillierte Informationen darüber, wie ESXi Ressourcen in Echtzeit verwendet werden (vgl. Abbildung 10). ESXi Ressourcen umfassen die Hardwarekomponenten CPU, Arbeitsspeicher, Energie, Speicher und Netzwerkressourcen (VMware Global Inc. 2009). Verbraucher von ESXi Ressourcen sind virtuelle Maschinen. Anbieter von physischen ESXi Ressourcen sind Hosts und Cluster. Ein Host ist z.b. ein Server, der physische ESXi Ressourcen gemäß seiner Hardwarespezifikation dem ESXi Hypervisor zur Verfügung stellt. Ein Cluster ist eine Verbindung aus mehreren Hosts, deren ESXi Ressourcen der ESXi Hypervisor gemeinsam verwaltet. Die Hardwarekomponenten, die einer virtuellen Maschine zugeteilt werden, haben nichts mit den physischen ESXi Ressourcen gemeinsam. Z.B. sind einer virtuellen Maschine zugeteilte virtuelle CPUs nicht-physische CPUs, deren Benutzung an den ESXi Hypervisor mitgeteilt und durch diesen für die physischen CPUs übersetzt wird. Zwar werden unter allen virtuellen Maschinen die physischen CPUs gleichmäßig aufgeteilt und jeder virtuellen Maschine die gleiche Anzahl an physischen CPUs gemäß der Anzahl an virtuellen CPUs zugewiesen, jedoch werden physische CPUs mehrfach belegt und jeder virtuellen Maschine die gleiche Menge an Zeit für die Benutzung der physischen ESXi Ressourcen zugeteilt. Zudem benötigt die Virtualisierungssoftware des ESXi Hypervisors ebenfalls ESXi Ressourcen. Sind die ESXi Ressourcen belegt wenn eine virtuelle Maschine sie zur Bearbeitung benötigt, werden ihr eine hohe Auslastung ihrer virtuellen CPUs angezeigt, obwohl die tatsächliche Auslastung durch z.b. eine andere virtuelle Maschine weitaus geringer sein kann. Überdies werden virtuelle CPUs physischen Rechenkernen zugeteilt, sodass jede virtuelle CPU von einem physischen Rechenkern bedient wird. Beim Arbeitsspeicher findet ebenfalls 53

XEN Performance. Projektpraktikum Informatik. Arne Klein 2008-02-26. Arne Klein () XEN Performance 2008-02-26 1 / 25

XEN Performance. Projektpraktikum Informatik. Arne Klein 2008-02-26. Arne Klein () XEN Performance 2008-02-26 1 / 25 XEN Performance Projektpraktikum Informatik Arne Klein 2008-02-26 Arne Klein () XEN Performance 2008-02-26 1 / 25 1 Virtualisierung mit XEN 2 Performance von XEN Allgemeines Netzwerk-Performance IO-Performance

Mehr

Fragestellung: Wie viele CPU Kerne sollte eine VM unter Virtualbox zugewiesen bekommen?

Fragestellung: Wie viele CPU Kerne sollte eine VM unter Virtualbox zugewiesen bekommen? Fragestellung: Wie viele CPU Kerne sollte eine VM unter Virtualbox zugewiesen bekommen? Umgebung Getestet wurde auf einem Linux-System mit voller invis-server Installation, auf dem eine virtuelle Maschine

Mehr

Einsparung von Wartungs- und Lizenzkosten durch Konsolidierung

Einsparung von Wartungs- und Lizenzkosten durch Konsolidierung Einsparung von Wartungs- und Lizenzkosten durch Konsolidierung Peter Stalder DOAG November 2009 Basel Baden Bern Lausanne Zurich Düsseldorf Frankfurt/M. Freiburg i. Br. Hamburg Munich Stuttgart Vienna

Mehr

White Paper. Embedded Treiberframework. Einführung

White Paper. Embedded Treiberframework. Einführung Embedded Treiberframework Einführung White Paper Dieses White Paper beschreibt die Architektur einer Laufzeitumgebung für Gerätetreiber im embedded Umfeld. Dieses Treiberframework ist dabei auf jede embedded

Mehr

IT-Sicherheit mobiler Applikationen zur Unterstützung von Geschäftsprozessen. Bachelorarbeit

IT-Sicherheit mobiler Applikationen zur Unterstützung von Geschäftsprozessen. Bachelorarbeit IT-Sicherheit mobiler Applikationen zur Unterstützung von Geschäftsprozessen Bachelorarbeit zur Erlangung des akademischen Grades Bachelor of Science (B.Sc.) im Studiengang Wirtschaftswissenschaft der

Mehr

Befragung und empirische Einschätzung der Praxisrelevanz

Befragung und empirische Einschätzung der Praxisrelevanz Befragung und empirische Einschätzung der Praxisrelevanz eines Vorgehensmodells zur Auswahl von CRM-Systemen D I P L O M A R B E I T zur Erlangung des Grades eines Diplom-Ökonomen der Wirtschaftswissenschaftlichen

Mehr

Performance-Vergleich zwischen dem Open-E NAS Enterprise Server und dem Microsoft Windows Storage Server 2003

Performance-Vergleich zwischen dem Open-E NAS Enterprise Server und dem Microsoft Windows Storage Server 2003 Performance-Vergleich zwischen dem Open-E NAS Enterprise Server und dem Microsoft Windows Storage Server 2003 In diesem Whitepaper werden zwei wichtige NAS Betriebssysteme gegenübergestellt und auf ihre

Mehr

Antwortzeitverhalten von Online Storage Services im Vergleich

Antwortzeitverhalten von Online Storage Services im Vergleich EPOD Encrypted Private Online Disc Antwortzeitverhalten von Online Storage Services im Vergleich Fördergeber Förderprogramm Fördernehmer Projektleitung Projekt Metadaten Internet Foundation Austria netidee

Mehr

Messsystemanalyse (MSA)

Messsystemanalyse (MSA) Messsystemanalyse (MSA) Inhaltsverzeichnis Ursachen & Auswirkungen von Messabweichungen Qualifikations- und Fähigkeitsnachweise Vorteile einer Fähigkeitsuntersuchung Anforderungen an das Messsystem Genauigkeit

Mehr

Perzentile mit Hadoop ermitteln

Perzentile mit Hadoop ermitteln Perzentile mit Hadoop ermitteln Ausgangspunkt Ziel dieses Projektes war, einen Hadoop Job zu entwickeln, der mit Hilfe gegebener Parameter Simulationen durchführt und aus den Ergebnissen die Perzentile

Mehr

Cloud Computing. Betriebssicherheit von Cloud Umgebungen C O N N E C T I N G B U S I N E S S & T E C H N O L O G Y

Cloud Computing. Betriebssicherheit von Cloud Umgebungen C O N N E C T I N G B U S I N E S S & T E C H N O L O G Y Cloud Computing Betriebssicherheit von Cloud Umgebungen Urs Zumstein Leiter Performance Care Team Urs.Zumstein@DevoTeam.ch 079 639 42 58 Agenda Definition von Cloud Services Anforderungen an die Betriebssicherheit

Mehr

Learning Suite Talent Suite Compliance Suite. Systemvoraussetzungen

Learning Suite Talent Suite Compliance Suite. Systemvoraussetzungen Learning Suite Talent Suite Compliance Suite Systemvoraussetzungen Vorwort Dieses Dokument beschreibt, welche Anforderungen an die Installationsumgebung zu stellen sind, um die Plattform unter optimalen

Mehr

In-Memory Analytics. Marcel Poltermann. Fachhochschule Erfurt. Informationsmanagement

In-Memory Analytics. Marcel Poltermann. Fachhochschule Erfurt. Informationsmanagement Marcel Poltermann Fachhochschule Erfurt Informationsmanagement Inhaltsverzeichnis Glossar...III Abbildungsverzeichnis...III 1 Erläuterung:... 2 2 Technische Grundlagen... 2 2.1 Zugriff physische Datenträger:...

Mehr

Leistungsaufnahmemessung

Leistungsaufnahmemessung Leistungsaufnahmemessung Seminar Green IT Titus Schöbel Gliederung Motivation Messtechnik Strommessgeräte Wandel der Leistungsaufnahmemessung Leistungsaufnahmemessung PUE Gebäudeleittechnik Chancen und

Mehr

Programmiertechnik II

Programmiertechnik II Analyse von Algorithmen Algorithmenentwurf Algorithmen sind oft Teil einer größeren Anwendung operieren auf Daten der Anwendung, sollen aber unabhängig von konkreten Typen sein Darstellung der Algorithmen

Mehr

Voraussetzungen für jeden verwalteten Rechner

Voraussetzungen für jeden verwalteten Rechner Kaseya 2 (v6.1) Systemvoraussetzungen Voraussetzungen für jeden verwalteten Rechner Kaseya Agent 333 MHz CPU oder höher 128 MB RAM 30 MB freier Festplattenspeicher Netzwerkkarte oder Modem Microsoft Windows

Mehr

Universität Passau. Prof. Dr. Carola Jungwirth. Bachelorarbeit

Universität Passau. Prof. Dr. Carola Jungwirth. Bachelorarbeit Universität Passau Lehrstuhl für Betriebswirtschaftslehre mit Schwerpunkt Internationales Management Prof. Dr. Carola Jungwirth Bachelorarbeit Der Einsatz moderner Medien und Kommunikationsmöglichkeiten

Mehr

Analyse kritischer Erfolgsfaktoren für Enterprise Social Networking Anwendungen. Bachelorarbeit

Analyse kritischer Erfolgsfaktoren für Enterprise Social Networking Anwendungen. Bachelorarbeit Analyse kritischer Erfolgsfaktoren für Enterprise Social Networking Anwendungen Bachelorarbeit zur Erlangung des akademischen Grades Bachelor of Science (B.Sc.) im Studiengang Wirtschaftswissenschaften

Mehr

Inhaltsverzeichnis. BüroWARE Systemanforderungen ab Version 5.31. Generelle Anforderungen SoftENGINE BüroWARE SQL / Pervasive. 2

Inhaltsverzeichnis. BüroWARE Systemanforderungen ab Version 5.31. Generelle Anforderungen SoftENGINE BüroWARE SQL / Pervasive. 2 Inhaltsverzeichnis Generelle Anforderungen SoftENGINE BüroWARE SQL / Pervasive. 2 1. Terminal-Server-Betrieb (SQL)... 3 1.1. Server 3 1.1.1. Terminalserver... 3 1.1.2. Datenbankserver (bei einer Datenbankgröße

Mehr

IO Performance in virtualisierten Umgebungen

IO Performance in virtualisierten Umgebungen IO Performance in virtualisierten Umgebungen Bruno Harsch El. Ing. HTL/FH Managing Partner Tel +41 52 366 39 01 bruno.harsch@idh.ch www.idh.ch IDH GmbH Lauchefeld 31 CH-9548 Matzingen 2 Die Firma IDH wurde

Mehr

SmartExporter 2013 R1

SmartExporter 2013 R1 Die aktuelle Version wartet mit zahlreichen neuen Features und umfangreichen Erweiterungen auf. So können mit SmartExporter 2013 R1 nun auch archivierte Daten extrahiert und das Herunterladen der Daten

Mehr

E-logiController. Energie sparen mit System. Wirtschaftlich, nachhaltig und umweltschonend den Energieverbrauch reduzieren!

E-logiController. Energie sparen mit System. Wirtschaftlich, nachhaltig und umweltschonend den Energieverbrauch reduzieren! WENN VERBRAUCH SICHTBAR WIRD, BLEIBT KEIN VERLUST UNENTDECKT Energie sparen mit System E-logiController Wirtschaftlich, nachhaltig und umweltschonend den Energieverbrauch reduzieren! 2 E-logiController

Mehr

TECHNISCHE PRODUKTINFORMATION CARUSO

TECHNISCHE PRODUKTINFORMATION CARUSO 1111 TECHNISCHE PRODUKTINFORMATION CARUSO TECHNISCHE PRODUKTINFORMATION Seite 0/7 Inhalt 1 Systemdefinition............2 2 Technische Details für den Betrieb von CARUSO......2 2.1 Webserver... 2 2.2 Java

Mehr

BESCHAFFUNG UND LIZENZIERUNG MIT DEM VEREINFACHTEN ORACLE LIZENZMODELL

BESCHAFFUNG UND LIZENZIERUNG MIT DEM VEREINFACHTEN ORACLE LIZENZMODELL BESCHAFFUNG UND LIZENZIERUNG MIT DEM VEREINFACHTEN ORACLE LIZENZMODELL DIESER LEITFADEN IST FÜR FOLGENDE ORACLE SOFTWARE PROGRAMME GÜLTIG Oracle Database 11g Standard Edition One Die passende Datenbank-Lösung

Mehr

2 Virtualisierung mit Hyper-V

2 Virtualisierung mit Hyper-V Virtualisierung mit Hyper-V 2 Virtualisierung mit Hyper-V 2.1 Übersicht: Virtualisierungstechnologien von Microsoft Virtualisierung bezieht sich nicht nur auf Hardware-Virtualisierung, wie folgende Darstellung

Mehr

Performance Zertifizierung

Performance Zertifizierung Performance Zertifizierung Alois Schmid alois.schmid@itf-edv.de www.itf-edv.de Copyright 2012 ITF-EDV Fröschl GmbH Inhalt Firma.... Kapitel 1 Gründe für die Zertifizierung der Massendatentauglichkeit.....

Mehr

Hardware- und Software-Anforderungen IBeeS.ERP

Hardware- und Software-Anforderungen IBeeS.ERP Hardware- und Software-Anforderungen IBeeS.ERP IBeeS GmbH Stand 08.2015 www.ibees.de Seite 1 von 8 Inhalt 1 Hardware-Anforderungen für eine IBeeS.ERP - Applikation... 3 1.1 Server... 3 1.1.1 Allgemeines

Mehr

White Paper Energieverbrauch ESPRIMO P920 0-Watt

White Paper Energieverbrauch ESPRIMO P920 0-Watt White Paper Energieverbrauch ESPRIMO P920 0-Watt Mit dem Ziel, die Führungsrolle bei der Implementierung der europäischen Umweltschutzvorschriften auszubauen, stellt Fujitsu Technology Solutions alle wichtigen

Mehr

Die clevere Server- und Storage- Lösung mit voll integrierter Servervirtualisierung.

Die clevere Server- und Storage- Lösung mit voll integrierter Servervirtualisierung. Die clevere Server- und Storage- Lösung mit voll integrierter Servervirtualisierung. Entscheidende Vorteile. Schaffen Sie sich jetzt preiswert Ihre Virtualisierungslösung an. Und gewinnen Sie gleichzeitig

Mehr

Hardware Virtualisierungs Support für PikeOS

Hardware Virtualisierungs Support für PikeOS Virtualisierungs Support für PikeOS Design eines Virtual Machine Monitors auf Basis eines Mikrokernels Tobias Stumpf SYSGO AG, Am Pfaenstein 14, 55270 Klein-Winternheim HS Furtwangen, Fakultät Computer

Mehr

Performance Analyse in einem komplexen Softwaresystem. 18.09.2013 Gebhard Ebeling

Performance Analyse in einem komplexen Softwaresystem. 18.09.2013 Gebhard Ebeling Performance Analyse in einem komplexen Softwaresystem 18.09.2013 Gebhard Ebeling Problemstellung Systemkomplexität Bei der Performance Analyse komplexer Softwaresystemen gibt es viele Einflussfaktoren,

Mehr

Cloud-Computing Seminar - Vergleichende Technologien: Grid-Computing Hochschule Mannheim

Cloud-Computing Seminar - Vergleichende Technologien: Grid-Computing Hochschule Mannheim Sven Hartlieb Cloud-Computing Seminar Hochschule Mannheim WS0910 1/23 Cloud-Computing Seminar - Vergleichende Technologien: Grid-Computing Hochschule Mannheim Sven Hartlieb Fakultät für Informatik Hochschule

Mehr

Energieeffizienz und Informationstechnologie

Energieeffizienz und Informationstechnologie Energieeffizienz und Informationstechnologie Andreas Schmitt, System Engineer TIP Dialog Forum Frankfurt am Main 14.10.2008 Energieeffizienz / Lösungswege Felder Potenziale entdecken, bewerten und heben!

Mehr

Betriebssysteme Kap A: Grundlagen

Betriebssysteme Kap A: Grundlagen Betriebssysteme Kap A: Grundlagen 1 Betriebssystem Definition DIN 44300 Die Programme eines digitalen Rechensystems, die zusammen mit den Eigenschaften dieser Rechenanlage die Basis der möglichen Betriebsarten

Mehr

Systeme 1. Kapitel 10. Virtualisierung

Systeme 1. Kapitel 10. Virtualisierung Systeme 1 Kapitel 10 Virtualisierung Virtualisierung Virtualisierung: Definition: Der Begriff Virtualisierung beschreibt eine Abstraktion von Computerhardware hin zu einer virtuellen Maschine. Tatsächlich

Mehr

Hochschule Darmstadt - Fachbereich Informatik - Fachschaft des Fachbereiches

Hochschule Darmstadt - Fachbereich Informatik - Fachschaft des Fachbereiches Hochschule Darmstadt - Fachbereich Informatik - Fachschaft des Fachbereiches Verwendung der bereitgestellten Virtuellen Maschinen»Einrichten einer Virtuellen Maschine mittels VirtualBox sowie Zugriff auf

Mehr

Uberlegungen Einsatzgebiete Virtualisierungslosungen Fazit Hardwarevirtualisierung. Virtualisierung. Christian Voshage. 11.

Uberlegungen Einsatzgebiete Virtualisierungslosungen Fazit Hardwarevirtualisierung. Virtualisierung. Christian Voshage. 11. slosungen 11. Mai 2009 Inhaltsverzeichnis Uberlegungen slosungen 1 Uberlegungen Grunduberlegungen Vorteile Hardware-Emulation Nachteile 2 Servervirtualisierung Clientvirtualisierung 3 slosungen 4 5 Uberlegungen

Mehr

Performance Monitoring Warum macht es Sinn?

Performance Monitoring Warum macht es Sinn? Performance Monitoring Warum macht es Sinn? achermann consulting ag Nicola Lardieri Network Engineer Luzern, 25.5.2011 Inhalt Definition Monitoring Warum Performance Monitoring? Performance Monitoring

Mehr

Optimierung der Code-Generierung virtualisierender Ausführungsumgebungen zur Erzielung deterministischer Ausführungszeiten

Optimierung der Code-Generierung virtualisierender Ausführungsumgebungen zur Erzielung deterministischer Ausführungszeiten Optimierung der Code-Generierung virtualisierender Ausführungsumgebungen zur Erzielung deterministischer Ausführungszeiten Martin Däumler Matthias Werner Lehrstuhl Betriebssysteme Fakultät für Informatik

Mehr

Energiemanagementsystem nach DIN EN 16001 am Beispiel eines metallverarbeitenden Betriebs

Energiemanagementsystem nach DIN EN 16001 am Beispiel eines metallverarbeitenden Betriebs Energiemanagementsystem nach DIN EN 16001 am Beispiel eines metallverarbeitenden Betriebs 1. Teil: Ziele und Inhalte der DIN EN 16001 - Energiemanagementsysteme 2. Teil: Einführung der DIN EN 16001 in

Mehr

Virtualisierung im IT-Betrieb der BA

Virtualisierung im IT-Betrieb der BA Virtualisierung, essenzielles Werkzeug in der IT-Fabrik Martin Deeg, Anwendungsszenarien Cloud Computing, 31. August 2010 Virtualisierung im IT-Betrieb der BA Virtualisierung im IT-Betrieb der BA Effizienzsteigerung

Mehr

PARAGON SYSTEM UPGRADE UTILITIES

PARAGON SYSTEM UPGRADE UTILITIES PARAGON SYSTEM UPGRADE UTILITIES VIRTUALISIERUNG EINES SYSTEMS AUS ZUVOR ERSTELLTER SICHERUNG 1. Virtualisierung eines Systems aus zuvor erstellter Sicherung... 2 2. Sicherung in eine virtuelle Festplatte

Mehr

Entwicklung eines Scheduling-Verfahrens zur Optimierung der Reihenfolge von Prototypentests. Masterarbeit

Entwicklung eines Scheduling-Verfahrens zur Optimierung der Reihenfolge von Prototypentests. Masterarbeit Entwicklung eines Scheduling-Verfahrens zur Optimierung der Reihenfolge von Prototypentests Masterarbeit zur Erlangung des akademischen Grades Master of Science (M.Sc.) im Masterstudiengang Wirtschaftswissenschaft

Mehr

Energy-Efficient Cluster Computing

Energy-Efficient Cluster Computing Energy-Efficient Cluster Computing http://www.eeclust.de April 2009 März 2012 Timo Minartz Universität Hamburg Arbeitsbereich Wissenschaftliches Rechnen Konsortium Universität Hamburg (Koordinator) Thomas

Mehr

Approximationsalgorithmen

Approximationsalgorithmen Ausarbeitung zum Thema Approximationsalgorithmen im Rahmen des Fachseminars 24. Juli 2009 Robert Bahmann robert.bahmann@gmail.com FH Wiesbaden Erstellt von: Robert Bahmann Zuletzt berarbeitet von: Robert

Mehr

Systemvoraussetzungen und Installation

Systemvoraussetzungen und Installation Systemvoraussetzungen und Installation Inhaltsverzeichnis Inhaltsverzeichnis... 2 1. Einleitung... 2 2. Einzelarbeitsplatzinstallation... 3 3. Referenz: Client/Server-Installation... 5 3.1. Variante A:

Mehr

Proseminar Technische Informatik A survey of virtualization technologies

Proseminar Technische Informatik A survey of virtualization technologies Proseminar Technische Informatik A survey of virtualization technologies Referent: Martin Weigelt Proseminar Technische Informatik - A survey of virtualization technologies 1 Übersicht 1. Definition 2.

Mehr

»Selbst denkende«management-werkzeuge für die virtuelle Welt

»Selbst denkende«management-werkzeuge für die virtuelle Welt »Selbst denkende«management-werkzeuge für die virtuelle Welt André M. Braun Team Lead Sales Germany EMC IONIX 2 Dinge werden komplexer! Junkers G38 grösstes Land Verkehrsflugzeug seiner Zeit 3 Dinge werden

Mehr

Effizientes Änderungsmanagement in Outsourcing- Projekten

Effizientes Änderungsmanagement in Outsourcing- Projekten Effizientes Änderungsmanagement in Outsourcing- Projekten Dr. Henning Sternkicker Rational Software IBM Deutschland GmbH Sittarder Straße 31 52078 Aachen henning.sternkicker@de.ibm.com Abstract: Es werden

Mehr

Oracle 10g und SQL Server 2005 ein Vergleich. Thomas Wächtler 39221

Oracle 10g und SQL Server 2005 ein Vergleich. Thomas Wächtler 39221 Oracle 10g und SQL Server 2005 ein Vergleich Thomas Wächtler 39221 Inhalt 1. Einführung 2. Architektur SQL Server 2005 1. SQLOS 2. Relational Engine 3. Protocol Layer 3. Services 1. Replication 2. Reporting

Mehr

Aufbau einer Testumgebung mit VMware Server

Aufbau einer Testumgebung mit VMware Server Aufbau einer Testumgebung mit VMware Server 1. Download des kostenlosen VMware Servers / Registrierung... 2 2. Installation der Software... 2 2.1 VMware Server Windows client package... 3 3. Einrichten

Mehr

DISKUSSIONSBEITRÄGE DER FAKULTÄT FÜR BETRIEBSWIRTSCHAFTSLEHRE MERCATOR SCHOOL OF MANAGEMENT UNIVERSITÄT DUISBURG-ESSEN. Nr. 374

DISKUSSIONSBEITRÄGE DER FAKULTÄT FÜR BETRIEBSWIRTSCHAFTSLEHRE MERCATOR SCHOOL OF MANAGEMENT UNIVERSITÄT DUISBURG-ESSEN. Nr. 374 DISKUSSIONSBEITRÄGE DER FAKULTÄT FÜR BETRIEBSWIRTSCHAFTSLEHRE MERCATOR SCHOOL OF MANAGEMENT UNIVERSITÄT DUISBURG-ESSEN Nr. 374 Eignung von Verfahren der Mustererkennung im Process Mining Sabrina Kohne

Mehr

Calogero Fontana Fachseminar WS09/10. calogero.b.fontana@student.hs-rm.de. Virtualisierung

Calogero Fontana Fachseminar WS09/10. calogero.b.fontana@student.hs-rm.de. Virtualisierung Calogero Fontana Fachseminar WS09/10 calogero.b.fontana@student.hs-rm.de Virtualisierung Was ist Virtualisierung? Definition Virtualisierung ist das zur Verfügung stellen von Hardware-Ressourcen für ein

Mehr

Internationale Norm ISO/IEC 30134 Information Technology Data Centres Key Performance Indicators. Dr. Ludger Ackermann dc-ce RZ-Beratung

Internationale Norm ISO/IEC 30134 Information Technology Data Centres Key Performance Indicators. Dr. Ludger Ackermann dc-ce RZ-Beratung 1 Internationale Norm ISO/IEC 30134 Information Technology Data Centres Key Performance Indicators Dr. Ludger Ackermann dc-ce RZ-Beratung 2 Agenda Kurzvorstellung dc-ce rz beratung Übersicht Normungslandschaft

Mehr

Messdaten auswerten und visualisieren 5 Tipps, die passende Darstellungstechnik für ein Messsystem zu finden

Messdaten auswerten und visualisieren 5 Tipps, die passende Darstellungstechnik für ein Messsystem zu finden Messdaten auswerten und visualisieren 5 Tipps, die passende Darstellungstechnik für ein Messsystem zu finden 27.05.13 Autor / Redakteur: Nach Unterlagen von National Instruments / Hendrik Härter Messdaten

Mehr

Architektur einer GDI: Service-oriented Architecture (SOA)

Architektur einer GDI: Service-oriented Architecture (SOA) Modul 6: Voraussetzungen einer GDI Vertiefende Dokumente I Stand: 24.01.2012 Architektur einer GDI: Service-oriented Architecture (SOA) Zu den Hauptargumenten für eine Geodateninfrastruktur zählen unter

Mehr

1. Einleitung. 1.1. Ausgangssituation

1. Einleitung. 1.1. Ausgangssituation 1. Einleitung In der vorliegenden Arbeit wird untersucht, welche Faktoren den erfolgreichen Ausgang eines Supply-Chain-Projektes zwischen zwei Projektpartnern beeinflussen. Dazu werden zum einen mögliche

Mehr

Hyper-V Grundlagen der Virtualisierung

Hyper-V Grundlagen der Virtualisierung Grundlagen der Virtualisierung Was ist Virtualisierung? Eine Software-Technik, die mehrere Betriebssysteme gleichzeitig auf dem Rechner unabhängig voneinander betreibt. Eine Software-Technik, die Software

Mehr

Projekt:

Projekt: <Hier den Namen des Projektes eingeben!> <Adresse> <Telefon / Fax> <Ansprechpartner> Pflichtenheft Die Aufgabe des Pflichtenheftes ist es zu beschreiben, was die zu entwickelnde Software für den Anwender leisten soll. Diese Vorlage basiert auf der aus TSE I bekannten Vorlage. Projekt:

Mehr

VIRTUALISIERUNG AM BEISPIEL EINER KUNDENINFRASTRUKTUR. Christian Ellger Dell GmbH

VIRTUALISIERUNG AM BEISPIEL EINER KUNDENINFRASTRUKTUR. Christian Ellger Dell GmbH VIRTUALISIERUNG AM BEISPIEL EINER KUNDENINFRASTRUKTUR Christian Ellger Dell GmbH DIE ZUKUNFT IST VIRTUELL APP so APP so PHYSIKALISCHE SERVER/STORAGE Vol Vol APP so Vol APP APP Vol so so Vol APP so Vol

Mehr

PERFORMANCE TESTS AVALON ODS-SERVER 28.11.12 DR. REINHARD HALLERMAYER, BMW GROUP

PERFORMANCE TESTS AVALON ODS-SERVER 28.11.12 DR. REINHARD HALLERMAYER, BMW GROUP PERFORMANCE TESTS AVALON ODS-SERVER 28.11.12 DR. REINHARD HALLERMAYER, BMW GROUP Freude am Fahren Inhalt. Ziele Testumgebung und Testwerkzeug Tests und Testergebnisse Ausblick Beteiligte: Fa. Science +

Mehr

Desktopvirtualisierung 2009 ACP Gruppe

Desktopvirtualisierung 2009 ACP Gruppe Konsolidieren Optimieren Automatisieren Desktopvirtualisierung Was beschäftigt Sie Nachts? Wie kann ich das Desktop- Management aufrechterhalten oder verbessern, wenn ich mit weniger mehr erreichen soll?

Mehr

Performance und Bandbreitenmanagement Tests Version 10.01.2005. MuSeGa

Performance und Bandbreitenmanagement Tests Version 10.01.2005. MuSeGa Berner Fachhochschule Hochschule für Technik und Informatik HTI Performance und Bandbreitenmanagement Tests Version 10.01.2005 Diplomarbeit I00 (2004) MuSeGa Mobile User Secure Gateway Experte: Andreas

Mehr

CPU (Prozessor), Festplatte, Grafikkarte, Soundkarte, diverse Schnittstelle (USB, COM, SERIELL), Arbeitsspeicher (RAM), ROM, CD/DVD-Laufwerk

CPU (Prozessor), Festplatte, Grafikkarte, Soundkarte, diverse Schnittstelle (USB, COM, SERIELL), Arbeitsspeicher (RAM), ROM, CD/DVD-Laufwerk FRAGEKATALOG Informatik BAKIP HARDWARE Frage 01: Im inneren eines Computergehäuses befindet sich unter anderem das Mainboard. Welche Komponenten sind an diesem Mutterbrett angeschlossen bzw. verbaut? Nenne

Mehr

Echtzeitverhalten durch die Verwendung von CPU Stubs: Eine Erweiterung von Dynamic Performance Stubs. Echtzeit 2009

Echtzeitverhalten durch die Verwendung von CPU Stubs: Eine Erweiterung von Dynamic Performance Stubs. Echtzeit 2009 Echtzeitverhalten durch die Verwendung von CPU Stubs: Eine Erweiterung von Dynamic Performance Stubs Echtzeit 2009 Peter Trapp, 20.11.2009 Übersicht 1 Einleitung 2 (Übersicht) 3 (Framework) 4 Methodik

Mehr

Virtuelle Maschinen. von Markus Köbele

Virtuelle Maschinen. von Markus Köbele Virtuelle Maschinen von Markus Köbele Was sind virtuelle Maschinen? Rechner, dessen Hardwarekomponenten vollständig durch Software emuliert und virtualisiert werden Anweisungen der virtuellen Maschine

Mehr

Shibboleth Clustering und Loadbalancing

Shibboleth Clustering und Loadbalancing Shibboleth Clustering und Loadbalancing STEINBUCH CENTRE FOR COMPUTING - SCC KIT Universität des Landes Baden-Württemberg und nationales Forschungszentrum in der Helmholtz-Gemeinschaft www.kit.edu Computercluster

Mehr

Untersuchung des Zusammenhangs zwischen Energiebedarf, Dienstgüte & Performanz bei der Ressourcensubstitution in Software-Systemen

Untersuchung des Zusammenhangs zwischen Energiebedarf, Dienstgüte & Performanz bei der Ressourcensubstitution in Software-Systemen Untersuchung des Zusammenhangs zwischen Energiebedarf, Dienstgüte & Performanz bei der Ressourcensubstitution in Software-Systemen Christian Bunse Fachhochschule Stralsund Hagen Höpfner Bauhaus-Universität

Mehr

Projektphasen und Technische Vorbereitung eines NX Refiles mit dem PLMJobManager

Projektphasen und Technische Vorbereitung eines NX Refiles mit dem PLMJobManager Projektphasen und Technische Vorbereitung eines NX Refiles mit dem PLMJobManager Dieses Dokument dient zur Information über die Organisation der Projektphasen und der technischen Vorbereitung eines Refile

Mehr

Dynamische Skalierbarkeit

Dynamische Skalierbarkeit Alexander Eichhorn Verteilte Systeme und Betriebssysteme Technische Universität Ilmenau Frühjahrstreffen der GI Fachgruppe Betriebssysteme 30. Juni 2005 Koblenz Vortragsüberblick Teil 1 Teil 2 Teil 3 Begriffsbestimmungen

Mehr

Effizienzsteigerung im Rechenzentrum durch DCIM finden Sie den Einstieg!

Effizienzsteigerung im Rechenzentrum durch DCIM finden Sie den Einstieg! Effizienzsteigerung im Rechenzentrum durch DCIM finden Sie den Einstieg! 6. Februar 2013 Was ist DCIM? Data center infrastructure management (DCIM) is a new form of data center management which extends

Mehr

Redwood Cronacle und REALTECH theguard! Integration

Redwood Cronacle und REALTECH theguard! Integration Redwood Cronacle und REALTECH theguard! Integration Einleitung Redwood Software und REALTECH haben gemeinsam eine Lösung entwickelt, die die Systemverfügbarkeit von SAP und mysap Systemen signifikant erhöht.

Mehr

Aktuelle Themen der Informatik: Virtualisierung

Aktuelle Themen der Informatik: Virtualisierung Aktuelle Themen der Informatik: Virtualisierung Sebastian Siewior 15 Mai 2006 1 / 22 1 Überblick 2 Techniken 3 Paravirtualisierung 4 Ende 2 / 22 Wieso Virtualisieren Wieso mehrere Betriebsysteme auf einer

Mehr

Hochschule für Angewandte Wissenschaften München Fakultät Informatik und Mathematik

Hochschule für Angewandte Wissenschaften München Fakultät Informatik und Mathematik Hochschule für Angewandte Wissenschaften München Fakultät Informatik und Mathematik Verteilte Systeme (Masterstudiengänge) Wintersemester 2014/2015 München, September 2014 Prof. Dr. Peter Mandl Inhalt

Mehr

Herzlich willkommen! gleich geht es weiter

Herzlich willkommen! gleich geht es weiter Herzlich willkommen! gleich geht es weiter Thomas Gruß Dipl.-Inform. (FH) Gruß + Partner GmbH Inhabergeführtes IT Systemhaus Seit über 15 Jahren im Rhein-Main und Rhein- Neckargebiet tätig 10 Mitarbeiter

Mehr

Einleitung. Dr.-Ing. Volkmar Sieh. Department Informatik 4 Verteilte Systeme und Betriebssysteme Friedrich-Alexander-Universität Erlangen-Nürnberg

Einleitung. Dr.-Ing. Volkmar Sieh. Department Informatik 4 Verteilte Systeme und Betriebssysteme Friedrich-Alexander-Universität Erlangen-Nürnberg Einleitung Dr.-Ing. Volkmar Sieh Department Informatik 4 Verteilte Systeme und Betriebssysteme Friedrich-Alexander-Universität Erlangen-Nürnberg WS 2014/2015 V. Sieh Einleitung (WS14/15) 1 18 Organisatorisches

Mehr

Kosteneinsparungen bei IT-Sicherheit

Kosteneinsparungen bei IT-Sicherheit In Zahlen: So machen sich wirksamerer Endpunktschutz, höhere Leistung und geringere Systemlast bemerkbar Unter dem ständigen Druck, Produktivität und Kosteneffizienz zu steigern, wird von Unternehmen fortwährend

Mehr

Energieverbrauch und Energiekosten von Servern und Rechenzentren in Deutschland. Aktuelle Trends und Einsparpotenziale bis 2015.

Energieverbrauch und Energiekosten von Servern und Rechenzentren in Deutschland. Aktuelle Trends und Einsparpotenziale bis 2015. Energieverbrauch und Energiekosten von Servern und Rechenzentren in Deutschland Aktuelle Trends und Einsparpotenziale bis 2015 Berlin, Mai 2012 Borderstep Institut für Innovation und Nachhaltigkeit gemeinnützige

Mehr

ONET: FT-NIR-Netzwerke mit zentraler Administration & Datenspeicherung. ONET Server

ONET: FT-NIR-Netzwerke mit zentraler Administration & Datenspeicherung. ONET Server : FT-NIR-Netzwerke mit zentraler Administration & Datenspeicherung Motivation für die Vernetzung von Spektrometern Weiterhin wachsender Bedarf für schnelle Analysenmethoden wie NIR Mehr Kalibrationen werden

Mehr

Enterprise Social Networking: Ein Framework und ein Fachkonzept für ein Industrieunternehmen

Enterprise Social Networking: Ein Framework und ein Fachkonzept für ein Industrieunternehmen Enterprise Social Networking: Ein Framework und ein Fachkonzept für ein Industrieunternehmen Bachelorarbeit zur Erlangung des akademischen Grades Bachelor auf Science (B.Sc.) im Studiengang Wirtschaftswissenschaft

Mehr

Endorsed SI Anwenderbericht: Einsatz von System Platform 2012 R2 in virtualisierten Umgebungen zur Prozessvisualisierung

Endorsed SI Anwenderbericht: Einsatz von System Platform 2012 R2 in virtualisierten Umgebungen zur Prozessvisualisierung Endorsed SI Anwenderbericht: Einsatz von System Platform 2012 R2 in virtualisierten Umgebungen zur Prozessvisualisierung Fritz Günther 17.03.2014 Folie 1 Agenda Was ist Virtualisierung Server- / Clientvirtualisierung

Mehr

[DIA] Webinterface 2.4

[DIA] Webinterface 2.4 [DIA] Webinterface 2.4 2 Inhalt Inhalt... 2 1. Einleitung... 3 2. Konzept... 4 2.1 Vorteile und Anwendungen des... 4 2.2 Integration in bestehende Systeme und Strukturen... 4 2.3 Verfügbarkeit... 5 3.

Mehr

Kennziffern zum Stromverbrauch und CO 2 -Ausstoß des zentralen IT-Security Monitoring Dashboards des AMPEG Security Lighthouse

Kennziffern zum Stromverbrauch und CO 2 -Ausstoß des zentralen IT-Security Monitoring Dashboards des AMPEG Security Lighthouse Kennziffern zum Stromverbrauch und CO 2 -Ausstoß des zentralen IT-Security Monitoring Dashboards des AMPEG Security Lighthouse Veröffentlicht in Bremen im August 2013 AMPEG GmbH Alexander Luca Graf Obernstraße

Mehr

Systemanforderungen für MuseumPlus und emuseumplus

Systemanforderungen für MuseumPlus und emuseumplus Systemanforderungen für MuseumPlus und emuseumplus Systemanforderungen für MuseumPlus und emuseumplus Gültig ab: 01.03.2015 Neben den aufgeführten Systemvoraussetzungen gelten zusätzlich die Anforderungen,

Mehr

Design von skalierbaren Websystemen und Test auf ihre Leistungsbeschränkungen Basiert auf der Veröffentlichung Design and testing of scalable Web-based systems with performance constraints von Mauro Andrelini,

Mehr

enerpy collaborative webased workflows collaborative webbased groupware INDEX 1. Netzwerk Überblick 2. Windows Server 2008

enerpy collaborative webased workflows collaborative webbased groupware INDEX 1. Netzwerk Überblick 2. Windows Server 2008 INDEX 1. Netzwerk Überblick 2. Windows Server 2008 3. SQL Server 2008 (32 Bit & 64 Bit) 4. Benötigte Komponenten 5. Client Voraussetzungen 1 1. Netzwerk Überblick mobile Geräte über UMTS/Hotspots Zweigstelle

Mehr

Realistische und aussagekräftige Lasttests mit loadit

Realistische und aussagekräftige Lasttests mit loadit Realistische und aussagekräftige Lasttests mit loadit 5. Juli 2012 Jens Müller NovaTec Ingenieure für neue Informationstechnologien GmbH Leinfelden-Echterdingen, München, Frankfurt am Main, Jeddah / Saudi-Arabien

Mehr

VMware als virtuelle Plattform

VMware als virtuelle Plattform VMware als virtuelle Plattform Andreas Heinemann aheine@gkec.informatik.tu-darmstadt.de Telekooperation Fachbereich Informatik Technische Universität Darmstadt Übersicht Einführung VMware / Produkte /

Mehr

LimTec Office Cloud. 28.07.2011 LimTec www.limtec.de

LimTec Office Cloud. 28.07.2011 LimTec www.limtec.de LimTec Office Cloud 1 Überblick Ihre Ausgangssituation Ihre Risiken und Kostenfaktoren Die LimTec Office Cloud Idee Cluster und Cloud Office Cloud Komponenten Office Cloud Konfiguration Rückblick Vorteile

Mehr

7.4 Analyse anhand der SQL-Trace. 7.3.5 Vorabanalyse mit dem Code Inspector

7.4 Analyse anhand der SQL-Trace. 7.3.5 Vorabanalyse mit dem Code Inspector 7.4 Analyse anhand der SQL-Trace 337 7.3.5 Vorabanalyse mit dem Code Inspector Der Code Inspector (SCI) wurde in den vorangegangenen Kapiteln immer wieder erwähnt. Er stellt ein paar nützliche Prüfungen

Mehr

Application Performance Management. Auch eine Frage des Netzwerkes?

Application Performance Management. Auch eine Frage des Netzwerkes? Application Performance Management Auch eine Frage des Netzwerkes? Agenda Architektur von Webanwendungen Lange Applikationsantwortzeiten Application Performance Management (APM) Netzwerkbasiertes APM Serverbasiertes

Mehr

JEAF Cloud Plattform Der Workspace aus der Cloud

JEAF Cloud Plattform Der Workspace aus der Cloud JEAF Cloud Plattform Der Workspace aus der Cloud Juni 2014 : Aktuelle Situation Heutige Insellösungen bringen dem Nutzer keinen Mehrwert Nutzer sind mobil Dateien und Applikationen sind über Anbieter und

Mehr

Projekt für Systemprogrammierung WS 06/07

Projekt für Systemprogrammierung WS 06/07 Dienstag 30.01.2007 Projekt für Systemprogrammierung WS 06/07 Von: Hassan Bellamin E-Mail: h_bellamin@web.de Gliederung: 1. Geschichte und Definition 2. Was ist Virtualisierung? 3. Welche Virtualisierungssoftware

Mehr

Hardware-basierte Virtualisierung

Hardware-basierte Virtualisierung Hardware-basierte Virtualisierung Dr.-Ing. Volkmar Sieh Department Informatik 4 Verteilte Systeme und Betriebssysteme Friedrich-Alexander-Universität Erlangen-Nürnberg WS 2014/2015 V. Sieh Hardware-basierte

Mehr

VIRTUALISIERUNG IN MIKROKERN BASIERTEN SYSTEMEN

VIRTUALISIERUNG IN MIKROKERN BASIERTEN SYSTEMEN Fakultät Informatik Institut für Systemarchitektur, Professur Betriebssysteme VIRTUALISIERUNG IN MIKROKERN BASIERTEN SYSTEMEN Henning Schild Dresden, 5.2.2009 Definition Einführung von Abstraktionsschichten

Mehr

Lasttestbericht BL Bankrechner

Lasttestbericht BL Bankrechner Lasttestbericht BL Bankrechner Business-Logics GmbH Inhaltsverzeichnis 1 Testumgebung 2 1.1 Hardwareversionen........................ 2 1.2 Softwareversionen........................ 3 1.3 Datenbestand..........................

Mehr

» Das Cloud-Labor. » Effizienz auf dem Prüfstand. future thinking. Marc Wilkens www.regioit-aachen.de. Sinsheim, 29.03.2012

» Das Cloud-Labor. » Effizienz auf dem Prüfstand. future thinking. Marc Wilkens www.regioit-aachen.de. Sinsheim, 29.03.2012 » Das Cloud-Labor» Effizienz auf dem Prüfstand future thinking Marc Wilkens www.regioit-aachen.de Sinsheim, 29.03.2012 GGC-Lab: Die Projektpartner Technische Universität Berlin 2 Vorstellung GGC-Lab: Übersicht

Mehr

DISKUSSIONSBEITRÄGE DER FAKULTÄT FÜR BETRIEBSWIRTSCHAFTSLEHRE MERCATOR SCHOOL OF MANAGEMENT UNIVERSITÄT DUISBURG-ESSEN. Nr. 378

DISKUSSIONSBEITRÄGE DER FAKULTÄT FÜR BETRIEBSWIRTSCHAFTSLEHRE MERCATOR SCHOOL OF MANAGEMENT UNIVERSITÄT DUISBURG-ESSEN. Nr. 378 DISKUSSIONSBEITRÄGE DER FAKULTÄT FÜR BETRIEBSWIRTSCHAFTSLEHRE MERCATOR SCHOOL OF MANAGEMENT UNIVERSITÄT DUISBURG-ESSEN Nr. 378 Umsetzung ausgewählter Supply-Chain-Operations-Reference-Metriken durch das

Mehr