Technische Universität Kaiserslautern
Fachbereich Informatik
AG Datenbanken und Informationssysteme
Prof. Dr.-Ing. Dr. h. c. Theo Härder
Energieezienz in Datenbanken
Entwurf einer Mess- und Auswertungsumgebung
Diplomarbeit
im Studiengang Angewandte Informatik
Daniel Schall
d_schall@cs.uni-kl.de
Betreuer:
Prof. Dr.-Ing. Dr. h. c. Theo Härder
& Dipl.-Inf. Karsten Schmidt
Ausgabedatum: 1. April 2009
Abgabedatum: 30. September 2009
Erklärung
Ich versichere hiermit, dass ich die vorliegende Diplomarbeit mit dem Thema
Energieezienz in Datenbanken
Entwurf einer Mess- und Auswertungsumgebung
selbstständig verfasst und keine anderen als die angegebenen Hilfsmittel benutzt habe.
Die Stellen, die anderen Werken dem Wortlaut oder dem Sinn nach entnommen wurden,
habe ich durch die Angabe der Quelle, auch der benutzten Sekundärliteratur, als Entlehnung kenntlich gemacht.
Daniel Schall
Kaiserslautern, den 30. September 2009
Dieses Dokument entspricht nicht der benoteten Arbeit, es wurden Rechtschreibfehler
korrigiert und der Satz wurde für die Bildschirmanzeige aufbereitet.
Inhaltsverzeichnis
1 Einleitung
1
2 Motivation
2.1
2.2
3
Begrisdenition
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4
2.1.1
Performance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4
2.1.2
Energieverbrauch . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4
2.1.3
Energieezienz . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
5
2.1.4
Energieoptimierung . . . . . . . . . . . . . . . . . . . . . . . . . . .
5
Stand der Technik und verwandte Arbeiten
. . . . . . . . . . . . . . . . .
5
2.2.1
Hardware
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
5
2.2.2
Software . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
8
3 Aufbau des Testsystems
13
3.1
Hardwareausstattung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
13
3.2
Softwareausstattung
13
3.2.1
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
XML Transaction Coordinator
3.3
Systemgrenzen
3.4
Schnittstellen
. . . . . . . . . . . . . . . . . . . .
13
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
14
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
15
3.4.1
Remote Method Invocation
. . . . . . . . . . . . . . . . . . . . . .
15
3.4.2
Java Management Extensions . . . . . . . . . . . . . . . . . . . . .
15
3.4.3
Monitoring Framework . . . . . . . . . . . . . . . . . . . . . . . . .
16
4 Entwurf der Messumgebung
19
4.1
Aufbau der Messumgebung
. . . . . . . . . . . . . . . . . . . . . . . . . .
19
4.2
Elektrotechnische Grundlagen . . . . . . . . . . . . . . . . . . . . . . . . .
20
4.3
Entwurf des Messwandlers . . . . . . . . . . . . . . . . . . . . . . . . . . .
22
Aufbau der Module . . . . . . . . . . . . . . . . . . . . . . . . . . .
24
4.4
A/D-Wandler . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
25
4.5
Auswertungssoftware . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
26
4.5.1
Aufbau der Software . . . . . . . . . . . . . . . . . . . . . . . . . .
26
4.5.2
Implementierung
. . . . . . . . . . . . . . . . . . . . . . . . . . . .
27
4.5.3
Integration in Benchmark-Suite . . . . . . . . . . . . . . . . . . . .
34
4.3.1
5 Testmessungen
5.1
37
Test der Auswertungssoftware . . . . . . . . . . . . . . . . . . . . . . . . .
37
5.1.1
Testaufbau
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
37
5.1.2
Testablauf . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
38
v
Inhaltsverzeichnis
5.2
5.3
5.4
5.1.3
Testergebnisse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
5.1.4
Auswertung der Ergebnisse
Test des A/D-Wandlers
. . . . . . . . . . . . . . . . . . . . . .
41
. . . . . . . . . . . . . . . . . . . . . . . . . . . .
41
5.2.1
Testaufbau
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
42
5.2.2
Testablauf . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
42
5.2.3
Testergebnisse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
43
5.2.4
Auswertung der Ergebnisse
. . . . . . . . . . . . . . . . . . . . . .
43
Test des Messwandlers . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
44
5.3.1
Testaufbau
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
44
5.3.2
Testablauf . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
45
5.3.3
Testergebnisse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
46
5.3.4
Auswertung der Ergebnisse
. . . . . . . . . . . . . . . . . . . . . .
47
. . . . . . . . . . . . . . . . . . . . . . . . .
47
5.4.1
Herleitung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
48
5.4.2
Implikationen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
49
Analyse der Messabweichung
6 Ausblick
6.1
6.2
6.3
6.4
39
51
Erweiterung der Messhardware
. . . . . . . . . . . . . . . . . . . . . . . .
Genauere Untersuchung der Messabweichung
6.1.2
Einbeziehung der Kühlenergie . . . . . . . . . . . . . . . . . . . . .
51
6.1.3
Hinzufügen weiterer Messpunkte
. . . . . . . . . . . . . . . . . . .
52
6.1.4
Einbeziehung des Stromverbrauchs des Netzteils . . . . . . . . . . .
52
Erweiterung der Software
. . . . . . . . . . . .
51
6.1.1
51
. . . . . . . . . . . . . . . . . . . . . . . . . . .
52
6.2.1
Entkopplung der Messwerte . . . . . . . . . . . . . . . . . . . . . .
52
6.2.2
Integration in ein grasches Front-End . . . . . . . . . . . . . . . .
53
6.2.3
Konguration über XML-Dateien . . . . . . . . . . . . . . . . . . .
53
6.2.4
Entwicklung eines Linux-Treibers . . . . . . . . . . . . . . . . . . .
54
6.2.5
Integration in Benchmark-Suite . . . . . . . . . . . . . . . . . . . .
54
6.2.6
Einbeziehung der Kühlenergie II
6.2.7
Instrumentierung eines weiteren DBMS
Energiemessungen
. . . . . . . . . . . . . . . . . . .
54
. . . . . . . . . . . . . . .
54
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
55
6.3.1
Vergleich der Energieezienz von Algorithmen
. . . . . . . . . . .
55
6.3.2
Energieezienz von Flash-Laufwerken
. . . . . . . . . . . . . . . .
55
6.3.3
Evaluation von Pueralgorithmen . . . . . . . . . . . . . . . . . . .
56
Berechnung von Leistungsparametern . . . . . . . . . . . . . . . . . . . . .
56
6.4.1
Leistungskurven
56
6.4.2
Energiebasierte Anfrageoptimierer
. . . . . . . . . . . . . . . . . .
57
6.4.3
Energiebasierte Benchmarks . . . . . . . . . . . . . . . . . . . . . .
58
. . . . . . . . . . . . . . . . . . . . . . . . . . . .
7 Zusammenfassung
59
8 Literaturverzeichnis
61
vi
Inhaltsverzeichnis
Anhang
65
Abbildungsverzeichnis
67
Tabellenverzeichnis
69
vii
1 Einleitung
Die USA wenden 1.2 % des gesamten Stromverbrauchs allein für den Betrieb und die
Kühlung von Rechenzentren auf. Die Anzahl und Gröÿe der Rechenzentren wächst kontinuierlich an, doch mit deren Gröÿe wächst auch deren Energieverbrauch. Auch bei
Datenbanken zeichnet sich seit langem ein ähnlicher Trend ab. Groÿe Unternehmen wie
Google und Microsoft bauen Rechenzentren an Standorten mit günstiger Energieversorgung, um die Stromkosten niedrig zu halten. Trotzdem verteuern sich die Stompreise,
Prognosen rechnen zukünftig mit einem stärkeren Anstieg als bisher. Dabei wird ein
Groÿteil des Stroms bei geringer Serverauslastung verbraucht, während Volllastsituationen kaum vorkommen. Angesichts dieser Entwicklungen stellt sich die Frage, ob die
Minimierung der Stromkosten bei ungebremstem Wachstum wirklich die Lösung ist. Können Server energieezienter arbeiten, indem Hard- und Software angepasst werden? Wie
skaliert der Energieverbrauch eines Datenbanksystems unter Last?
Zur Beantwortung dieser Fragen wurden bereits einige Forschungsarbeiten vorgestellt,
doch gerade für letztere Frage existiert noch keine umfassende Messumgebung. Gleichzeitig rückt die
Green-IT
aus wirtschaftlichen und ökologischen Gründen immer mehr
ins Blickfeld der Öentlichkeit und etabliert sich neben der Performancewertung eines
Systems als wichtiges Kriterium. Daher wird in dieser Arbeit eine Mess- und Auswertungsumgebgung zur Ermittlung des Energieverbrauchs eines Datenbanksystems vorgestellt. Mit dieser ist es möglich, den Energieverbrauch eines Systems unter Last zu messen
und Aussagen über die Energieezienz der Komponenten zu treen. Zunächst wird in
Kapitel 2 die derzeitige Situation beschrieben und der Bedarf an energieezienteren Lösungen erläutert. Darauf aufbauen werden bestehende Arbeiten zur Energiemessung und
-optimierung an Computerhardware und Datenbanksoftware vorgestellt. Die Ergebnisse
der Arbeiten werden analysiert und es wird gezeigt, dass bei der Messung des Energieverbrauchs noch Verbesserungsbedarf besteht. In Kapitel 3 wird das System vorgestellt,
dessen Energieverbrauch gemessen werden soll. Die Hardwareausstattung wird vorgestellt
und das verwendete Datenbanksystem beschrieben. Aufbauend darauf wird in Kapitel
4 der Entwurf einer Messumgebung beschrieben, die den Stromverbrauch des Systems
messen kann. Die elektrotechnischen Grundlagen zur Energiemessung, sowie der Entwurf
und der Aufbau der Messstrecke werden beschrieben. Neben dem Hardwareaufbau werden
auch die Auswertungssoftware und die Interaktionskomponente für das Datenbanksystem
vorgestellt. Nachdem die Messumgebung vorgestellt wurde, wird der Ablauf anhand einiger Test- und Kalibrationsmessungen in Kapitel 5 erläutert. Auÿerdem wird die Messabweichung analysiert. Abschlieÿend werden in Kapitel 6 einige Verwendungsmöglichkeiten
der neuen Messumgebung vorgestellt und die zukünftige Forschungsschwerpunkte, bei
denen die hier entworfene Messumgebung eingesetzt werden soll, beschrieben.
1
2 Motivation
Derzeit werden in den USA bereits 1.2 % des gesamten Energieverbrauchs zur Stromversorgung und Kühlung von Rechenzentren aufgebracht, Prognosen erwarten eine weitere
Zunahme des Energieverbrauchs. Gleichzeitig steigen die Beschaungspreise für Strom
an der Europäischen Energiebörse (EEX) jährlich um durchschnittlich 5.9 %. Die laufenden Kosten für den Betrieb von Serverfarmen nehmen daher stetig zu. Geht man derzeit
von etwa 50 Cent Betriebskosten pro angeschaten Euro Hardware aus, sollen diese bis
2012 auf 100 % der Anschaungskosten ansteigen. Etwa die Hälfte des Stromverbrauchs
wird allein für die Kühlung der Server benötigt. Das bedeutet, für jeden angeschaten
Euro Hardware muss ebenso viel Geld für die Energieversorgung und Kühlung während
der Betriebszeit (typischerweise 3 bis 5 Jahre) ausgegeben werden. [1] [2] [3] [4]
M
Million Tons Ca
arbon Dioxide
Energy‐Related Carbon Dioxide Emissions
1990 ‐ 2007
7000 0
7000,0
6000,0
6000 0
Transportation
Industrial
Commercial
Residential
5000,0
4000,0
3000,0
2000,0
1000,0
0,0
1990
1991
1992
1993
1994
1995
1996
1997
1998
1999
2000
2001
2002
2003
2004
2005
2006
2007
Abbildung 2.1: Energiebezogene C O2 -Emissionen je Sektor, Daten aus [5]
Auch unter ökologischen Gesichtspunkten ist die Reduzierung des Energieverbrauchs
von Servern eine sinnvolle Maÿnahme. Zwar fällt der C O2 -Ausstoÿ pro verbrauchter kW h
Strom durch den Einsatz erneuerbarer Energien kontinuierlich, da gleichzeitig die Anzahl
der Server stetig ansteigt, verringert sich der Gesamtausstoÿ allerdings nicht. Geht man
3
2 Motivation
von einem C O2 -Ausstoÿ von 612 g pro kW h Strom aus, würde eine Einsparung von 10
Watt bei einem im Dauerbetrieb laufenden Server gut 53 kg C O2 pro Jahr einsparen.
Auf ein Rechenzentrum mit 1000 Servern hochgerechnet würden durch diese Einsparung
also jedes Jahr rund 53 Tonnen Kohlendioxidemissionen weniger anfallen. Das entspräche einem Würfel mit ca. 30 Metern Seitenlänge, bestehend aus reinem Kohlendioxid
(gasförmig). [6] Geht man weiterhin von einer Eigenerzeugung des Stroms zum Betrieb
des Rechenzentrums aus, sind (in der europäischen Union) Emissionszertikate notwendig, um diese Menge an Treibhausgasen erzeugen zu dürfen. Allein der Preis für die 53
benötigten Zertikate zum Ausgleich der C O2 -Emissionen beträgt rund 750 EUR, bei
einem Preis von 14 EUR pro Zertikat. Nicht eingerechnet sind die Kosten für zusätzliche
Emissionszertikate für andere klimaschädliche Gase, die ebenfalls bei der Stromerzeugung anfallen können.
Dieses ktive Beispiel zeigt, dass sowohl ökologische als auch ökonomische Interessen
die Steigerung der Energieezienz von Servern fordern. Allerdings ist die
Green-IT,
die
Verbesserungen beim Umwelt- und Ressourcenschutz anstrebt, ein bisher wenig beachtetes Feld. Im Folgenden werden bisherige Überlegungen zu diesem Thema dargestellt und
es wird verdeutlicht, dass dem Interesse an energieezienteren Lösungen im IT-Bereich
bisher keine umfassenden Konzepte gegenüberstehen. Insbesondere wird die Frage erhoben, ob allein die Performance eines Systems entscheidend ist, oder ob der Fokus
zunehmend auf energieeziente Systeme gelegt werden sollte, auch wenn diese weniger
performant sind. Um die gerade eingeführten Begrie wie
zienz
Performance
und
Energiee-
zu erklären, sollen die nun folgenden Denitionen dienen.
2.1 Begrisdenition
Zunächst müssen einige grundlegende Begrie erklärt werden. Durch die Denition wird
deutlich, dass Performance und Energieezienz grundlegend unterschiedliche Begrie
sind und nicht im direkten Zusammenhang stehen. Eine detaillierte Denition der elektrotechnischen Fachbegrie Arbeit und Leistung erfolgt in Abschnitt 4.2.
2.1.1 Performance
Die Performance eines Systems beschreibt dessen Leistung, also die verrichtete Arbeit
pro Zeiteinheit.
P erf ormance
=
W ork
T ime
Die Performance kann in unterschiedlichen Einheiten gemessen werden, etwa in Transaktionen (
TPS ), Rechenoperationen (MIPS ) oder auch Datendurchsatz (MB/s ) pro Se-
kunde. Die Leistung wird unabhängig von der verbrauchten Energie betrachtet.
2.1.2 Energieverbrauch
Der Energieverbrauch eines Systems ist die Menge an elektrischer Arbeit, die vom System in Rechenleistung und Wärme umgesetzt wird. Da die Abwärme des Systems in
4
2.2 Stand der Technik und verwandte Arbeiten
Rechenzentren eine Kühlung voraussetzt, empehlt die
SPEC, den Energieverbrauch zur
Kühlung mit einzurechnen (siehe 2.2.2). Da es sich in dieser Arbeit beim betrachteten
System um einen einzelnen Server handelt, wird entgegen dieser Empfehlung nur die
unmittelbar genutzte elektrische Energie durch das System betrachtet.
2.1.3 Energieezienz
Die Energieezienz sei deniert als der Quotient aus geleisteter Arbeit und Energieverbrauch:
E nergy E f f iciency
=
W ork
E nergy C onsumption
Je mehr Arbeit bei gleichem Energieverbrauch geleistet werden kann, desto energieezienter arbeite ein System. Um die Energieezienz verschiedene Systeme miteinander zu
vergleichen, müssen diese äquivalente Arbeitslasten aufweisen, da andernfalls die Energieezienz nicht direkt miteinander verglichen werden kann. Bei der Betrachtung der
Energieezienz ist die Zeit unerheblich, die das System zur Verrichtung der Arbeit benötigt. [7]
2.1.4 Energieoptimierung
Veränderungen am System, die zu einer Steigerung der Energieezienz führen, sollen
Energieoptimierungen genannt werden. Eine Verringerung des Energieverbrauchs muss
dabei nicht notwendig eine Optimierung bedeuten, wenn durch die Veränderung proportional weniger Arbeit geleistet wird. Daher muss das gesamte System betrachtet werden,
an dem Veränderungen vorgenommen werden. Beispiele für solche Veränderungen sind
der Austausch von Hardwarekomponenten oder Änderungen an Algorithmen.
2.2 Stand der Technik und verwandte Arbeiten
Zunächst werden der derzeitige Stand der Technik, wie er bereits in Systemen eingesetzt
wird, sowie weitere Forschungstrends vorgestellt. Aufbauend auf hardwareseitigen Entwicklungen zur Energieoptimierung werden softwareseitige Mechanismen, unterteilt in
Betriebssysteme und Datenbanksysteme, vorgestellt.
2.2.1 Hardware
Hersteller haben sich bereits mit dem Problem des groÿen Energiebedarfs von Rechnern
befasst und es wurden einige Maÿnahmen entwickelt, um dieser Probleme Herr zu werden.
Abbildung 2.2 zeigt anhand einer Messung von Google aus dem Jahr 2008, dass der
Energieverbrauch bestehender Serverhardware keineswegs lastproportional ist. Die Grak zeigt den Energieverbrauch diverser Hardwarekomponenten eines Servers unter verschiedenen Lastzuständen. Einige Komponenten skalieren zwar den Energieverbrauch
5
2 Motivation
Abbildung 2.2: Anteiliger Energieverbrauch von Serverkomponenten, aus [8]
mit der Auslastung, beispielsweise die CPU, der Groÿteil des Energieverbrauchs ist jedoch konstant. Es ist also ersichtlich, dass noch erheblicher Verbesserungsbedarf besteht.
Im Folgenden sollen einige der Technologien vorgestellt werden, die in handelsüblichen
Komponenten zur Steigerung der Energieezienz eingesetzt werden.
Hardwarekomponenten
Die bisherige Erfahrung, nach der sich die Komplexität und
die Leistung der Komponenten etwa alle zwei Jahre verdoppelt (bekannt als
Law ),
Moore's
musste in jüngster Zeit angepasst werden, da etwa die Taktfrequenz von Mikro-
prozessoren nicht nach Belieben erhöht werden kann. Die derzeitige Grenze von etwa 5
Ghz kann nur bei unverhältnismäÿig starkem Anstieg des Energieverbrauchs angehoben
werden. Dieser Anstieg ist bedingt durch sogenannte Leckströme, die Leistung verbrauchen und die Integrität der Schaltung gefährden. [9] Um das Mooresche Gesetz doch zu
Core )
erfüllen, kann die Anzahl der Kerne (
pro Prozessorchip (
Die )
angehoben werden.
Allerdings steigt auch hier die Verlustleistung an, bei Verdopplung der Kernanzahl verdoppelt sich der Verbrauch der CPU im Leerlauf (in etwa). Um dem entgegenzuwirken
wurden intelligente Stromsparmechanismen implementiert, die es erlauben, Kerne oder
Funktionseinheiten bei Nichtbenutzung in einen Schlafzustand zu versetzen. Der Schlafzustand kann hier eine Reduzierung der Taktfrequenz sein, verbunden mit dem Absenken
der Versorgungsspannung, oder auch ein komplettes Abschalten der Einheit. Die hier
exemplarisch gezeigten Techniken wurden auch für andere Hardwarekomponenten entwickelt, etwa für USB-Geräte, die automatisch deaktiviert werden können, Grakchips,
die zwischen 2D- und 3D-Modus umschalten, oder Festplatten, deren Plattenteller bei
Nichtbenutzung angehalten werden.
Als vielversprechende, neue Technologie zur Energieoptimierung haben sich FlashSpeicher gezeigt. Diese bieten ebenso wie konventionelle Festplatten persistenten Speicherplatz, im Gegensatz zu diesen benötigen sie zum Datenzugri allerdings keine mechanischen Komponenten. Dadurch haben Flash-Speicher ein anderes Zugrisverhalten,
da auf alle Datenblöcke ohne Wartezeiten zugegrien werden kann. Durch die fehlende
6
2.2 Stand der Technik und verwandte Arbeiten
Mechanik haben Flash-Speicher auch andere Energiecharakteristika als Festplatten: Der
Leerlaufverbrauch ist vernachlässigbar klein und auch der Energieverbrauch beim Lesen
und Schreiben ist geringer als bei vergleichbaren Magnetplatten. Den Vorteilen dieser
neuen Technologie stehen allerdings eine verlangsamte In-Place-Schreibgeschwindigkeit
Mean Time Between Failures 1 ) entgegen. Aufgrund der neuen
und eine geringere MTBF (
Eigenschaften sollten diese Geräte nicht wie herkömmliche Festplatten behandelt werden,
sondern durch eine spezielle auf die Charakteristika der Flash-Laufwerke abgestimmten
Datenbank-Schnittstelle angesprochen werden. Allerdings sind die Hardwarehersteller bestrebt, die negativen Eigenschaften der Flash-Laufwerke durch laufwerksinterne Algorithmen zu verbergen, daher ist dieses Arbeitsfeld derzeit noch im ständigen Wandel und
Aussagen über das Verhalten von Flash-Laufwerken können mit der nächsten Hardwaregeneration bereits komplett überholt sein.
Server
mens
Komponentenübergreifend wurde eine Technik zum Energiemanagement na-
Advanced Conguration and Power Interface
2
Betriebssystem in Zusammenarbeit mit dem BIOS
(ACPI) entwickelt, mit der es dem
ermöglicht wird, energierelevante Ei-
genschaften der Komponenten auszulesen und diese in vordenierte Energiesparzustände
zu versetzen [10]. Diese Technik erlaubt bereits ein grundlegendes Energiemanagement
und reduziert den Stromverbrauch eines durchschnittlichen Computers deutlich. Allerdings verringern die Techniken die Gesamtperformance des Rechners, da beispielsweise
das Aufwachen aus Stromsparzuständen ebenfalls Zeit kostet, in der nicht gearbeitet werden kann. Für Consumer-PCs mag es sich hier um vernachlässigbar kleine Verzögerungen
handeln, die aufgrund der Vorteile wie der geringeren Wärmeentwicklung und längeren Akkulaufzeiten gerne in Kauf genommen werden, für Server, deren Stromversorgung
ohnehin meist unterbrechungsfrei ausgelegt ist, sind schnelle Reaktionszeiten bei AdHoc-Anfragen und durchgehende Verfügbarkeit allerdings ein gewichtigeres Kriterium.
Auch ist die Auslastung bei Servermaschinen im Durchschnitt höher als bei ArbeitsplatzRechnern (wenn eingeschaltet). Da sich Servermaschinen kaum im kompletten Leerlauf
benden, können ACPI-Stromsparmechanismen nicht eingreifen.
Server sind oftmals auf einen bestimmten Betriebszweck ausgelegt, etwa als Webserver, E-Mail-Server oder als Backup-System und die zur Verfügung stehende Hardware ist
daher meist dem Zweck angepasst. Da diese Server für den normalen Betrieb häug überdimensioniert ausgestattet sind, um Reserven für kurzzeitige Lastspitzen bereitzuhalten,
bewegt sich die durchschnittliche Auslastung meist im unteren zweistelligen Prozentbereich [11]. Barroso et. al. zeigen beispielsweise, dass die Prozessoren der Google-Server
einen Groÿteil der Zeit nur zwischen 20 und 50 % ausgelastet sind. Jedoch beanspruchen
sie unter dieser Auslastung bereits ca. 70 % des gesamten Stromverbrauchs [12].
Rechenzentren
Bezogen auf ein Rechenzentrum bedeutet das, dass ein Groÿteil der
Hardware nur gering ausgelastet ist und sich oftmals zusätzliche Serversysteme als
Over
1
2
Fail-
im Leerlauf benden. Abgesehen von der elektrischen Energie, die zur Versorgung
MTBF: Die durchschnittliche Zeit, die vergeht, bis ein Gerätefehler auftritt
BIOS = Basic Input Output System
7
2 Motivation
der Server benötigt wird, muss Kühlleistung bereitgestellt werden, um die Abwärme
der Rechner abzutransportieren. Derzeit wird diese Abwärme meist noch als Abfall
betrachtet und durch Kühlanlagen ins Freie transportiert. Ein neuer Ansatz ist die Nutzbarmachung dieser Wärme um beispielsweise Büroräumen zu beheizen [13].
Ein neuer Trend ist die Virtualisierung und Konsolidierung mehrerer Rechner auf einer
Servermaschine. Dabei werden mehrere Server durch einen leistungsfähigeren, moderneren Server ersetzt und als virtuelle Maschinen auf dem neuen Server eingerichtet.
Server1
vServer1
Server2
vServer2
Server3
vServer3
Server
Abbildung 2.3: Virtualisierung von Servern
Einsparungen sind durch diese Technik möglich, da der neue Server energieezienter
arbeiten kann als die ersetzten Server. Auch ist die durchschnittliche Auslastung des
physischen Servers höher, da sich die Auslastungen der virtualisierten Systeme addieren.
Die Virtualisierung von Servern erlaubt es auÿerdem, eine aktive Lastverteilung durchzuführen und bei Bedarf weitere virtuelle Server zu einer Aufgabe hinzuzufügen. Dadurch
ist es möglich, auf unterschiedliche Lastspitzen zu reagieren und für die jeweilige Aufgabe dedizierte Server zur Verfügung zu stellen [14]. Eine Erweiterung der Virtualisierung
stellen sogenannte Rechner-Clouds dar, die nach dem Prinzip des Grid-Computing Rechenleistung auf Abruf zur Verfügung stellen. Die in Anspruch genommenen Ressourcen,
wie etwa Rechenzeit, Speicherverbrauch oder Menge der übertragenen Daten, werden
dem Verursacher dann in Rechnung gestellt. Durch das Aufgehen mehrere Server in der
Cloud ist die gezielte Ausrichtung auf energetische Parameter möglich [2].
2.2.2 Software
Nicht nur hardwareseitig wurden Techniken eingeführt, um den steigenden Energieverbrauch zu kontrollieren, auch softwareseitig wird nach geeigneten Methoden gesucht.
Insbesondere muss das Betriebssystem die von der Hardware angebotenen Features nutzen können. Datenbankseitig wurden ebenfalls einige interessante Ideen hervorgebracht,
um die Energieezienz zu steigern. Einige ausgewählte Arbeiten werden hier vorgestellt.
Betriebssysteme
Alle gängigen Betriebssysteme bieten ACPI-Unterstützung, oftmals
werden dessen Möglichkeiten jedoch nicht ausgeschöpft. Die standardmäÿig aktivierte
Energiesparrichtlinie von Windows XP senkt beispielsweise den Prozessortakt bei Akkubetrieb im Leerlauf ab, nicht jedoch bei konstanter Stromversorgung. In neueren Versionen des Betriebssystems (Windows Vista) ist es allerdings möglich, Energiesparrichtlinien
über das Firmennetzwerk zu verteilen und zentral zu verwalten. Dadurch können verbesserte Richtlinien verteilt und der Energieverbrauch des gesamten Rechnerparks gesenkt
8
2.2 Stand der Technik und verwandte Arbeiten
werden. Das Betriebssystem kann auch zu einer Steigerung der Energieezienz beitragen,
Abbildung 2.4: Umordnung zeitgesteuerter Ereignisse in Windows 7, aus [15]
indem die Ausführung von Programmen beeinusst wird, beispielsweise können zeitgesteuerte Ereignisse zusammengefasst werden, um Unterbrechungen in Leerlaufzeiten zu
minimieren. Abbildung 2.4 zeigt das Umordnen, wie es in Windows 7 vorgenommen
wird. [15] Die meisten Linux-Distributionen verzichteten bisher auf das Aktivieren der
Stromsparmechanismen, da sich die ACPI-Implementierung als sehr instabil und fehleranfällig erwies. [16] Allerdings ist die korrekte Implementierung der Mechanismen durch
die zunehmende Verbreitung von Linux auf tragbaren Computern stark vorangeschritten.
Deutlich wird, dass auch Betriebssystemhersteller von der alleinigen Ausrichtung auf
Performancewerte abkehren und sich zunehmend auch an energierelevanten Kennwerten
orientieren. Die zunehmende Verbreitung von tragbaren Computern und immer kleineren
Systemen (sogenannten
Netbooks )
sorgt für gestiegenen Bedarf an aktivem Energiema-
nagement, um möglichst lange mobil zu sein.
Datenbanksysteme
Datenbanksysteme wurden bisher stets nach Performance beur-
teilt, bestehende Benchmarks messen daher Werte wie Transaktionen pro Sekunde(
TPS/$ )
Transaktionen pro Dollar (
TPS ),
und andere Maÿe, die den Durchsatz und die Verar-
beitungsgeschwindigkeit messen. Beispiele für solche Benchmarks sind die
markreihe für relationale Datenbanken oder
XMARK
und
TPoX
TPC -Bench-
als Benchmarks für
XML-Datenbanksysteme. All diese Benchmarks testen die Datenbank, indem sie realen
Szenarien nachempfundene Anfragen an die Datenbank stellen und den Durchsatz sowie
die Antwortzeit messen. Die Benchmarks legen daher Wert auf hohen Durchsatz und
kurze Antwortzeiten, wie kurz am Benchmark
Transaction Processing over XML),
TPoX (
TPoX
erläutert wird:
entwickelt von IBM, bildet ein Online-
Börsengeschäft und dessen Geschäftsvorfälle nach. Die Speicherung der Daten erfolgt im
3
XML-Format, unter Einbeziehung des FIXML-Schemas . Der Benchmark-Ablauf ist wie
folgt:
1 bis n Anwendungsthreads werden gestartet und simulieren je einen Datenbankbenutzer.
Jeder der Threads führt eine zufällig ausgewählte Datenbankanfrage aus und wartet
auf die Antwort des DBMS. Unmittelbar danach wird die nächste Anfrage ausgeführt,
es enstehen also keine Wartezeiten zwischen den Anfragen. Der Benchmark misst die
Ausführungszeit der Transaktionen, sowie den gesamten Durchsatz an Anfragen [17].
3
FIXML (Financial Information eXchange's Message Format):
http://www.fixprotocol.org
9
2 Motivation
Es wird deutlich, dass dieser Benchmark, wie alle vorgestellten, einen rein performanceorientierten Test des Datenbanksystems durchführt. Verzögerungen oder Engpässe auf
Seiten der Benchmark-Treiber sind nicht eingeplant, ebenso werden keine Anfragen gestellt, deren Beantwortung nicht unmittelbar erwartet wird. Eine Ausnahme von dieser
performance-orientierten Sicht bildet der relativ neue Benchmark
Die
Standard Performance Evaluation Corporation
SPECpower_ssj2008.
(SPEC) hat sich hier dem Argument
angenommen, dass die Energieezienz in Benchmarks bisher nicht beachtet wurde. Sie
stellen eine Methodologie auf, um diese Benchmarks vergleichbar zu gestalten und gibt
Richtlinien, welche Parameter zu beachten sind, etwa die Umgebungstemperatur oder
der Energieverbrauch zur Kühlung des Systems. Die
SPEC
schlägt auÿerdem vor, neben
der reinen Performance-Messung auch Leerlaufzeiten zu beachten, da diese unter realen
Betriebsbedingungen einen Groÿteil der Laufzeit ausmachen. Mit
stellt die
SPEC
SPECpower_ssj2008
einen ersten Benchmark vor, der aufbauend auf der empfohlenen Metho-
dologie, die Energieezienz und Performance von Servern messen kann [18].
Entsprechend den Benchmarks wurden bei Datenbankherstellern alle Optimierungen auf
die Steigerung dieser Performancewerte hin ausgerichtet, ebenso die Auslegung der Hardware von Datenbanksystemen. Bereits Poess et. al. bemängelten fehlende Benchmarks,
um Energieezienz zu bewerten. Sie haben daher den bekannten
TPC-C -Benchmark
analysiert und um eine Schätzung des Energieverbrauchs erweitert. Zu diesem Zweck
haben sie ein Modell entworfen, das die Schätzung des Energieverbrauchs eines Systems aufgrund der Auslastung von dessen Komponenten erlaubt. Dieses Modell wurde
anschlieÿend anhand publizierter Benchmarkergebnisse auf Basis der dort eingesetzten
Hardware validiert. Diese Arbeit stützt sich allerdings nicht auf die Messung des Energieverbrauchs, es werden Schätzungen anhand von ktiven Leistungskurven (siehe Kapitel
4.2) vorgenommen, um bestehende Benchmarkergebnisse mit zusätzlichen Zahlen zur
Energieezienz ausstatten zu können [19].
Dagegen haben Höpfner et. al. echte Messungen durchgeführt, um den Energieverbrauch
einiger Sortier- und Joinalgorithmen auf eingebetteter Hardware zu vergleichen (siehe
Abbildung 2.5). Die Abbildung zeigt den Energieverbrauch verschiedener Algorithmen
auf unterschiedlichen Hardwarekomponenten. Auf der Gröÿenachse ist der relative Energieverbrauch der unterschiedlichen Kongurationen aufgetragen. Die Versuche wurden
auf verschiedenen Prozessorkarten der Firma
Atmel
durchgeführt. Anschlieÿend haben
Höpfner et. al. durch den wechselnden Einsatz von Algorithmen den Verbrauch des Gesamtsystems optimiert. [20] Die Grak zeigt, dass der Energieverbrauch der Algorithmen
recht unterschiedlich ist. Diese ergibt sich aufgrund des unterschiedlichen Speicherverbrauchs und der Prozessorauslastung der Algorithmen. Da die Messungen auf eingebetteter Hardware durchgeführt wurden, die sich von klassischen Datenbanksystemen
deutlich unterscheiden (kleiner Arbeitsspeicher, keine dedizierte Storage-Einheit), sind
die Ergebnisse nicht direkt auf die Optimierung von Datenbanken übertragbar, geben
aber doch Einblick in die unterschiedlichen Energie-Charakteristika der Algorithmen.
Energiemessungen an einem Datenbanksystem, ausgeführt auf Serverrechnern, wurden
von Härder et. al. durchgeführt. Hier wurden die Möglichkeiten, Geschwindigkeit und
Energieezienz durch den Austausch herkömmlicher Festplatten durch Flash Disks zu
steigern, untersucht. In der Arbeit werden die Unterschiede zwischen herkömmlichen
10
2.2 Stand der Technik und verwandte Arbeiten
8
7
ATMega16
6
ATMega32
ATMega128
5
4
3
2
1
0
Abbildung 2.5: Energieverbrauch von Sortieralgorithmen, aus [20]
Festplatten und Flash Disks untersucht und das Verhalten des Datenbanksystems unter
Verwendung der neuen Technologie evaluiert. Es stellte sich heraus, dass durch deren
Einsatz Energieeinsparungen direkt möglich sind, allerdings durch weitere Anpassungen
der Datenbank an die neue Technologie weiteres Potential besteht. [21] Diese Aussagen
stützen sich allerdings auf die Messung des gesamten Stromverbrauchs des Datenbanksystems, eine komponentengenaue Messung des Energieverbrauchs wurde hier nicht vorgenommen.
Auch Rivoire et. al. nehmen Optimierungen vor, um ein bestehendes Datenbanksystem möglichst energieezient arbeiten zu lassen. Ausgehend von einer vordenierten
Aufgabe, beispielsweise dem Sortieren von 10 GB Daten, variieren sie die verwendete
Hardware, um eine energiesparende Konguration zu erhalten. So wird die Anzahl der
verwendeten Platten und Speicherchips variiert, ebenso die CPU-Frequenz. Auch die
zur Sortierung verwendeten Algorithmen und zugrundeliegenden Dateisysteme werden
ausgetauscht. Diese Versuche werden für verschiedene Systeme, von Consumer-PC bis
zum Blade-Server, durchgeführt. Die Gruppe bestimmt den gesamten Verbrauch des ver-
11
2 Motivation
wendeten Systems zur Erledigung der Aufgabe, ebenso wird der Energieverbrauch zur
Kühlung des Systems berücksichtigt [22]. Ihre Arbeit zeigt, dass Datenbanken nicht nur
auf Performance, sondern auch auf Energieezienz optimiert werden können, indem die
verwendeten Hardware-Komponenten nach energieoptimalen Kriterien ausgesucht werden. Allerdings ist diese Art der Optimierung nicht zur Laufzeit möglich und insgesamt
zu grobkörnig. Auch stützt sich die Gruppe auf Schätzungen des Energieverbrauchs, anstatt auf echte Messungen.
Neben der Möglichkeit, die Hardwareausstattung zu optimieren, haben Lang et. al. softwaregestützte Verfahren vorgestellt, um den Energieverbrauch von Datenbanken bewerten und beeinussen zu können. Durch den Einsatz von Zeitverzögerungen bei der Anfra-
Improved Query Energy-eciency by Introducing Explicit Delays,
geverarbeitung (
QED), konnten sie die Energieezienz des Testsystems um 20 bis 49 % steigern.
kurz:
QED
verzögert die Ausführung von Datenbankanfragen, um möglicherweise ähnliche Anfragen
zu sammeln und gleichzeitig zu starten. Durch die parallele Ausführung können Puereekte ausgenutzt und insgesamt eine Senkung des Energieverbrauchs erzielt werden, da
Daten von Externspeichern seltener gelesen werden müssen. Durch den Einsatz dieser
Technik steigt die mittlere Antwortzeit der Anfragen aufgrund der Verzögerung um 3 bis
6 %. Eine weitere vorgeschlagene Technik zur Steigerung der Energieezienz ist
Voltage/Frequency Control,
Processor
kurz: PVC), die eine Absenkung der Prozessorfrequenz und
-spannung bei geringer Last vorsieht. Wie in 2.2.1 erwähnt, verwenden moderne Prozessoren diese Technik bereits, um bei Leerlauf den Stromverbrauch und die Hitzeentwicklung
zu senken. Durch
PVC
wird es dem DBMS ermöglicht, selbst aktiv in diesen Regelkreis
einzugreifen, um die Prozessorleistung nach eigenen Regeln anzupassen. Damit kann eine Energieeinsparung von ca. 54 % erreicht werden, allerdings steigt die Antwortzeit
um 43 % an. [23] Diese groÿe Verzögerung wird möglicherweise durch die suboptimale
Anpassung der Prozessorfrequenz an die Anforderungen des DBMS verursacht.
Der Bedarf an energieezienten Datenbanken ist also nicht zuletzt ein Softwareproblem, doch energieezientere Algorithmen oder energiebasierte Anfrageoptimierer sind
bisher nur Teil von Forschungsarbeiten und nicht in kommerziellen Datenbanksystemen
enthalten. Die bestehenden Arbeiten zeigen, dass der Energieoptimierung von Datenbanken ein groÿes Potential beigemessen wird, allerdings oenbart sich weiterer Forschungsbedarf. Die erwähnten Arbeiten messen den Energieverbrauch beispielsweise nur
für das Gesamtsystem (Härder, Lang), schätzen den Energieverbrauch der Komponenten (Poess), oder nehmen Messungen an exemplarischer Hardware vor (Höpfner). Eine
Energiemessung der Einzelkomponenten eines Datenbanksystems unter realistischer Last
wurde bisher nicht durchgeführt. Da diese Messungen jedoch den Grundstein für Optimierung bilden, wird in dieser Arbeit ein Aufbau vorgestellt, der es erlaubt, den Energieverbrauch der einzelnen Komponenten eines handelsüblichen PCs während des Betriebs
zu ermitteln. Um die ermittelten Werte mit den internen Vorgängen der Datenbank in
einen kausalen Zusammenhang zu setzen, wird auÿerdem ein Monitoring Framework für
eine Datenbank vorgestellt, das anhand des XML-Datenbankmanagementsystems
XTC
erläutert wird. Dadurch wird es möglich sein, Energiedaten und Datenbankvorgänge in
Korrelation zu setzen.
12
3 Aufbau des Testsystems
Im Folgenden wird der Aufbau des Systems beschrieben, dessen Energieezienz gemessen
und bewerten werden soll. Die verwendete Hard- und Software wird vorgestellt und die
Systemgrenzen werden deniert.
3.1 Hardwareausstattung
1
Das Datenbanksystem besteht aus einem Mini-ITX-Mainboard , einer 64-Bit CPU mit
zwei Kernen und 2 GB Arbeitsspeicher. Als Externspeicher sind eine IDE-Festplatte und
ein SATA-Flash-Laufwerk angeschlossen.
Da die Messumgebung für ein beliebiges ATX-Mainboard entworfen wurde, können die
verwendeten Komponenten ausgetauscht werden. Soweit nicht anders angegeben, werden
alle Messungen in dieser Arbeit mit der hier vorgestellten Hardware vorgenommen.
3.2 Softwareausstattung
Als Betriebssystem wird die 32-Bit Serverversion von Ubuntu Linux 8.04.1, Kernelversion
2.6.24-19-server, verwendet. Um die Messungen vor Störeinüssen zu sichern, wurden alle
nicht benötigten Hintergrunddienste abgeschaltet. Das verwendete Datenbanksystem ist
XML Transaction Coordinator ), welches im Folgenden kurz vorgestellt wird.
XTC (
3.2.1 XML Transaction Coordinator
Dieses Datenbanksystem wurden an der Technischen Universität Kaiserslautern von Theo
Datenbanken und Informationssysteme entwickelt und stellt ein
natives XML-Datenbanksystem (XDBMS ) dar. Es ist zum gröÿten Teil in Java geschrie-
Härders Arbeitsgruppe
ben und erlaubt durch seine Modularität und strenge Trennung der Datenbankschichten
die Erweiterung und den Austausch von Komponenten. Da es recht einfach ist, Veränderungen am System vorzunehmen und Messonden zu installieren, ist
XTC
gut geeignet,
die internen Vorgänge im Datenbanksystem zu erfassen. Eine umfangreiche Instrumentierung der Komponenten (Ausstatten mit Messsonden) wurde bereits 2008 durchgeführt,
siehe 3.4.3. Damit ist es möglich, interne Performancewerte aus der Datenbank über
JMX
abzufragen und auszuwerten.
1
Mini-ITX ist ein Gröÿenmaÿ für ATX-Mainboards
13
3 Aufbau des Testsystems
Tabelle 3.1: Komponenten des Testsystems
Component
Manufacturer, Item Name
Specications
Mainboard
MSI Fuzzy GM965
Chipset: GM965+ICH8M
CPU
Intel Core2Duo T8300
2,4 GHz,
2 Cores
Memory
Kingston KVR667D2N5/2G
2048 MB,
DDR2-667,
CL2
Hard Disk
Maxtor DiamondMax Plus9
80 GB,
ATA133
Flash Disk
SuperTalent FSD32GC35M
32 GB,
SATA
3.3 Systemgrenzen
Die Systemgrenzen beschreiben den Umfang des zu messenden Systems. Das Datenbanksystem stellt dabei eine Black Box dar; Der Energieverbrauch des Systems ist also die
Menge an Energie, die in das System hineingeführt wird. Da das Netzteil einen Teil der
System Boundary
RMI
JMX
Abbildung 3.1: Systemgrenzen und Schnittstellen
Energie als sogenannte Blindleistung nicht an die Komponenten weitergibt, wird diese
Komponenten auÿerhalb der Systemgrenze positioniert. Ebenso steht der CPU-Lüfter
auÿerhalb dieser Grenzen, da dessen Energieverbrauch nicht unmittelbar mit den Vorgängen im System zusammenhängt und ohnehin nicht optimiert werden kann. Entgegen
den Empfehlungen der
SPEC
(siehe Abschnitt 2.2.2), ist in dieser Arbeit der Energiever-
brauch zur Kühlung des Systems nicht miteinbezogen worden. Weder der unmittelbare
Verbrauch (durch Lüfter), noch die Wärmeabgabe an die Umgebung werden zu diesem
Stand in die Messung mit einbezogen, können aber zu einem späteren Zeitpunkt integriert
werden (siehe Kapitel 6).
14
3.4 Schnittstellen
3.4 Schnittstellen
Um über die Systemgrenzen hinweg mit dem DBMS zu kommunizieren, werden Schnittstellen benötigt, die den Zugri auf die Datenbank zulassen. Einerseits müssen Anfragen
an die Datenbank gesendet und Ergebnisse angefragt werden, andererseits müssen die
internen Performancewerte der Datenbank ermittelt werden. Anfragen an die Datenbank
werden über eine RMI-Verbindung gesendet. Das Monitoring Framework verwendet JMX
Beans, um den internen Zustand der Datenbank zu ermitteln. Bevor das Framework vorgestellt wird, wird die Funktionsweise von
RMI
und
JMX
kurz erläutert.
3.4.1 Remote Method Invocation
RMI )2
Die Remote Method Invocation (
ermöglicht das Publizieren von Java-Objekten
über das Netzwerk. Dadurch können andere Prozesse (auf anderen Computern) auf das
Objekt zugreifen und Methoden aufrufen. Dies geschieht für beide Prozesse transparent,
sodass nicht festgestellt werden kann, ob der Aufruf lokal oder remote erfolgt.
3.4.2 Java Management Extensions
Manager
Manager
Client(s)
RMI
RMI
Registry
Server
Agent
Instrumentation
Instrumentation
Ressource
Ressource
Abbildung 3.2: Java Management Extensions
Die Java Management Extensions (
JMX )3
stellen, aufbauend auf
RMI, Schnittstellen
bereit, die das Überwachen und Steuern von beliebigen Java-Anwendungen ermöglichen.
Auf Anwendungen, die JMX unterstützen, kann lokal oder über ein Netzwerk zugegriffen werden, Leistungsdaten können abgefragt und Operationen gestartet werden. Jede
Ressource, die verwaltet werden soll, muss ihre Parameter und Operationen über eine
Schnittstelle (Instrumentation) denieren. Diese Schnittstelle muss dann implementiert
2
3
Remote Method Invocation:
jsp
Java
Management
javamanagement/
http://java.sun.com/javase/technologies/core/basic/rmi/index.
Extensions:
http://java.sun.com/javase/technologies/core/mntr-mgmt/
15
3 Aufbau des Testsystems
und in einem Agenten in derselben virtuellen Maschine registriert werden. Erst dann
können Manager über den Agenten auf die Schnittstellen zugreifen. Wahlweise kann die
Verbindung zum Agenten direkt hergestellt werden (siehe linke Seite in Abbildung 3.2)
oder über eine Registry eine Objektreferenz auf den Agenten gesucht werden (rechte Seite). Der Manager muss nicht über die Schnittstellendenition verfügen, um Operationen
auf Ressourcen ausführen zu können. Es besteht die Möglichkeit, Referenzen auf generische Objekte zu verwenden und die im Objekt denierten Methoden und Parameter
ermitteln zu lassen. Allerdings bietet JMX auch die Möglichkeit, typisierte Referenzen
zu erhalten. Hier muss dem Manager die Denition der Schnittstelle zwar vorab bekannt
sein, das Arbeiten mit den JMX-Objekten vereinfacht sich aber, da die Namen und Parameter der Funktionen bekannt sind. [24]
3.4.3 Monitoring Framework
Die vorgestellte
JMX -Technologie
wurde verwendet, um das bestehende XDBMS mit
Schnittstellen zur Performance-Messung zu erweitern. Basierend auf den bestehenden
Monitoring-Erweiterungen wurden weitere hinzugefügt, um einen detaillierteren Einblick
in das System zu erhalten.
Abbildung 3.3: XTC System Activity Monitor, aus [25]
Ausgehend von der bereits bestehenden Instrumentierung (dargestellt in 3.3), durchgeführt 2008 von Ou [25], wurden Erweiterungen vorgenommen, um weitere Werte der
Datenbank auslesen zu können. So können beispielsweise Informationen über die Anzahl
der Lese- und Schreibzugrie oder die Auslastung des Puerpools ermittelt werden. Neu
hinzugekommen sind auch Sonden zur Messung der CPU- und Speicherauslastung sowie
erweiterte Messungen der Puer- und I/O-Operationen. Auÿerdem wurden alle Messwerte zusätzlich in einer Schnittstelle gebündelt, um den Verwaltungsaufwand beim Abfragen
der Werte zu verringern. Da das Abfragen der Performance-Werte das Datenbanksystem
zusätzlich auslastet und für das Versenden der JMX-Nachrichten ein KommunikationsOverhead anfällt, muss die Anzahl der Anfragen minimiert werden. Zu diesem Zweck
16
3.4 Schnittstellen
wurde eine sogenannte Superbean erzeugt, die alle verfügbaren Messwerte bündelt und
nur einmal je Anfrage übertragen werden muss. Dadurch sinkt die Anzahl der ausgetauschten Nachrichten je Anfrage auf konstant zwei.
Mit den hier vorgestellten Schnittstellen ist es nun also möglich, das Verhalten der
Datenbank in Echtzeit zu beobachten. In Verbindung mit der gleichzeitigen Messung des
Energieverbrauchs können dann Rückschlüsse auf die Ursachen und Optimierungspotentiale gezogen werden.
17
4 Entwurf der Messumgebung
Neben den internen Vorgängen in der Datenbank soll auch der Energieverbrauch des
Systems ermittelt werden. Hier ist der Detailverbrauch einzelner Hardwarekomponenten
von Interesse, um genaue Aussagen über das Verhalten der Komponenten unter Last
ableiten zu können. Da ATX-Mainboards keine integrierten Messpunkte besitzen, die
das Auslesen des Energieverbrauchs ermöglichen, muss für diese Aufgabe eine dedizierte
Messstrecke entworfen werden.
4.1 Aufbau der Messumgebung
Measurement Device
(Internal Development)
Database
(XTC)
A/D-Converter
(Labjack UE9)
Measurement
Software
Abbildung 4.1: Aufbau der Messstrecke
In Abbildung 4.1 ist der Aufbau der Messumgebung dargestellt. Die Datenbank ist
hardwareseitig mit einem Messwandler (
Measurement Device ) verbunden, der den Strom-
verbrauch der Komponenten misst. Die Messwerte werden an einen Analog-Digital-Wandler (
A/D-Converter )
weitergegeben, der die Werte digitalisiert und das Abfragen über
eine USB-Schnittstelle ermöglicht. Ein angeschlossener PC wertet die Daten aus. Die
Auswertung kann auch auf dem gleichen Rechner erfolgen, der auch das Datenbanksystem bereitstellt. Durch den zusätzlichen Rechenaufwand würde die Messung allerdings
beeinusst werden, daher ist die Auswertung über einen separaten PC sinnvoll. Der
Auswertungs-PC frägt zusätzlich die Performancewerte der Datenbank ab und setzt die
Werte in Korrelation zu den Energiedaten.
Bevor die einzelnen Komponenten beschrieben werden, wird ein Überblick über die
Grundlagen und Verfahren zur Energiemessung gegeben und der Aufbau der Messstrecke
erläutert.
19
4 Entwurf der Messumgebung
4.2 Elektrotechnische Grundlagen
Der Stromverbrauch eines elektrischen Geräts, auch elektrische Arbeit oder elektrische
Energie genannt, ist eine Funktion in Abhängigkeit von der elektrischen Leistung und der
Benutzungsdauer. Das Formelzeichen lautet W (Work), die Einheit ist J oule, deniert als
1 =1
Wattsekunde ( J
W s). Die elektrische Arbeit ist deniert als die elektrische Leistung
(Power P ) in einer denierten Zeit t:
W
= P
t
Da diese Formel nur bei konstanter Leistung gilt, ist bei schwankender Leistungskurve
die Bildung eines Integrals notwendig:
W
=
Z
P
t dt
Die elektrische Leistung wiederum ist das Produkt aus Stromstärke I und -spannung
(kurz: Spannung U ).
P
= U
I
Der Energieverbrauch eines Geräts kann also aus der Kenntnis der Stromstärke, -spannung und der Zeit ermittelt werden. Diese Herangehensweise setzt folglich die Messung
dieser drei Gröÿen voraus, während das System unter Last arbeitet.
Alternativ kann der Stromverbrauch ermittelt werden, indem die theoretische Leistungskurve L und die gemessene Auslastung einer Komponente u (engl.:
Schätzung herangezogen werden:
P
Usage )
zur
= ()
L u
Abbildung 4.2: Leistungskurve einer embedded-CPU
1
Diese Leistungskurve, wie beispielhaft in Abbildung 4.2 dargestellt, muss zuvor ermittelt werden. Sie gibt den Energieverbrauch einer Komponente bei einer vorgegebenen
1
http://mobiledevices.kom.aau.dk/research/energy\_measurements\_on\_mobile\_phones/
results/1/cpu\_usage/
20
4.2 Elektrotechnische Grundlagen
Auslastung an. Der vorgestellte Benchmark Energy-TPCC von Poess et. al. (siehe 2.2.2)
verwendet solche Leistungskurven zur Ermittlung des Energieverbrauchs. Diese wurden
auf Basis der technischen Spezikationen der Komponentenhersteller geschätzt. Zwar
bietet dieser Ansatz den Vorteil, auf die elektrischen Messungen verzichten zu können,
allerdings setzt er die Existenz detaillierter Leistungsfunktionen voraus, die für die meisten PC-Komponenten nicht existieren. Diese müssten im Vorfeld der eigentlichen Messung ermittelt werden, daher bietet dieser Ansatz zum derzeitigen Stand keinen Vorteil
gegenüber der direkten Messung.
Daher wird auf die Energiemessung, basierend auf Leistungskurven, hier nicht näher
eingegangen, der Stromverbrauch wird anhand gemessener Werte berechnet. Die Stromspannung wird dabei parallel, die Stromstärke in Reihe zum Gerät gemessen, wie in
Abbildung 4.3 verdeutlicht.
A
Load
Current
(lowresistance)
V
Voltage
(highresistance)
Abbildung 4.3: Messung der Stromstärke und -spannung
Das Beispiel zeigt, dass sich die gleichzeitige Messung der Spannung und der Stromstärke gegenseitig verfälschen, da sie im gleichen Leiter stattnden. Daher müssen die
Messgeräte eine möglichst geringe Beeinussung des Stromlaufs bieten. Für Spannungsmessungen bedeutet dies, dass die Innenwiderstände des Messgeräts entsprechend hoch
gewählt sein müssen, um möglichst wenig Strom passieren zu lassen. Durch die Wahl
groÿer Widerstände verringert sich die Stromspannung an der Last kaum. Analog muss
die Messung der Stromstärke einen möglichst geringen Widerstand bieten, um den Spannungsabfall am Gerät klein zu halten. Da die Messungen einen Einuss auf die Stromspannung an der Last haben, steigt das Risiko von Fehlfunktionen der zu messenden
Komponente mit steigendem Einuss der Messgeräte. [26] PC-Komponenten reagieren
empndlich auf Schwankungen der Stromspannung, der ATX-Standard setzt daher enge Toleranzgrenzen: Die Abweichung von der vorgeschriebenen Spannung darf bei den
meisten Versorgungsschienen 5 % nicht überschreiten. [27]
21
4 Entwurf der Messumgebung
4.3 Entwurf des Messwandlers
Um die erforderlichen Messungen durchzuführen und die Werte der Spannung und Stromstärke in ein einheitliches Format umzuwandeln, wird ein Gerät benötigt, das zwischen
das Netzteil des zu messenden PCs und der restlichen Komponenten geschaltet wird. So
können Spannung und Stromstärke im Leiter gemessen werden. Abbildung 4.4 zeigt die
Messpunkte, die erfasst werden. Damit ist es möglich, den Stromverbrauch der Festplatten sowie den Gesamtverbrauch des Mainboards zu ermitteln. Eine genauere Messung
des Einzelverbrauchs von CPU und Arbeitsspeicher kann hier noch nicht erfolgen.
Abbildung 4.4: Sitz der Messpunkte
Jeder der hier dargestellten Messpunkte besteht aus mehreren Leitern, daher sind mehrere Strom- und Spannungsmessungen erforderlich. Für die Messung des Stromverbrauchs
einer Festplatte mit MOLEX-Anschluss, der 5 V und 12 V bereitstellt, werden beispielsweise vier Messungen benötigt, je zwei für Stromstärke und zwei für die Stromspannung.
Insgesamt werden für die Messung des Stromverbrauchs daher 20 Messungen benötigt.
Tabelle 4.1 zeigt im Detail, welche Leiter berücksichtig werden müssen. Da manche Spannungen auf mehrere Leiter verteilt sind, können diese in einer Messung zusammengefasst
werden.
Measurement Device’s Power Supply
Measurement Device
Module
ATX
SATA
Molex
Measurement Lines
Abbildung 4.5: Anschlussplan des Messwandlers
In Zusammenarbeit mit der Zentralen Elektronikabteilung der Universität wurde ein
Messwandler entwickelt, der aus mehreren Messmodulen zusammengesetzt ist. Jedes Mo-
22
4.3 Entwurf des Messwandlers
Tabelle 4.1: Liste der Messpunkte
Pin
U
1
3.3 V
2
3.3 V
3
GND
4
5.0 V
5
GND
6
5.0 V
ATX
Imax
# Pin
19 A
1
15 A
2
15 A
2
U
3.3 V
19 A
1
14
-12 V
0.3 A
5
15
GND
16
PWR_ON
17
GND
18
GND
GND
19
GND
8
PWR
20
-5.0 V
9
3.3 V
2.5 A
4
21
5.0 V
10
12.0 V
20 A
3
22
5.0 V
11
12.0 V
23
5.0 V
12
3.3 V
19 A
1
24
GND
Molex
Imax
# Pin
U
Pin
U
1
12.0 V
3
GND
2
GND
4
5.0 V
Pin
U
SATA
Imax
# Pin
U
1
3.3 V
10
GND
2
3.3 V
11
SIGNAL
3
3.3 V
12
GND
4
GND
13
12.0 V
5
GND
14
12.0 V
6
GND
15
12.0 V
7
5.0 V
8
5.0 V
9
5.0 V
2 A
2 A
6
8
#
13
7
2 A
max
I
ATX v1
15 A
2
max
#
2 A
7
max
#
I
I
LED
2 A
10
9
23
4 Entwurf der Messumgebung
dul misst die Strom- und Spannungswerte eine Stromschiene und gibt Spannungswerte
aus, die vom angeschlossenen A/D-Wandler gelesen werden können. Durch den modularen Aufbau ist es möglich, Module bei Defekt oder zur Überarbeitung auszutauschen,
es können auch individuelle Messungen durchgeführt werden, indem für den benötigten Zweck entworfene Module installiert werden. Denkbar wären Module zur Messung
anderer Leiter oder zur Messung der Umgebungstemperatur, um Aussagen über die Wärmeentwicklung des Rechners treen zu können. Um den Energieverbrauch des PCs zu
ermitteln, werden 10 der Messmodule mit einer gemeinsamen Stromversorgung ausgestattet und in ein 19"-Servergehäuse verbaut. In das Gehäuse werden Ein- und Ausgänge für
den ATX-Mainboardstecker sowie die beiden Festplattenanschlüsse eingelassen, an die
ein PC-Netzteil angeschlossen wird. Die Stromleitungen werden innerhalb des Gehäuses dann an die Messmodule verteilt und nach der Messung wieder zusammengeführt,
wie in Abbildung 4.5 exemplarisch dargestellt. Abbildung 4.6 zeigt den Aufbau eines
Messmoduls, der im Folgenden erläutert wird.
4.3.1 Aufbau der Module
Amp
AC
AV
E
C
V
Abbildung 4.6: Modul zur Strom- und Spannungsmessung
Die derzeit verwendeten Module bestehen aus Schaltungen zur Strom- und Spannungsmessung eines Leiters. Im Bereich E des Schaltplans (Abb. 4.6) sind die Stromeingänge
des Leiters zu sehen. Von dort verzweigen Leiterbahnen zur Spannungsmessung (V ) und
zur Strommessung C . Im rechten Teil des Plans sind die Mess-Ausgänge, gekennzeichnet
als A
V
C
und A , sichtbar. Diese werden auf einer separaten Platine zusammengefasst und
über eine Steckverbindung an den A/D-Wandler weitergegeben.
24
4.4 A/D-Wandler
Messung der Spannung
Die Spannungsmessung an einem Leiter erfolgt im Schaltplan an der Stelle (V ) mit Hilfe
sogenannter linearer Spannungsteiler, die die Eingangsspannung E des zu messenden
Stroms auf die Ausgangsspannung A
V
des Messgeräts umrechnen und verstärken.
Messung der Stromstärke
Die Strommessung erfolgt berührungslos durch sogenannte Stromwandler (C ), die um den
zu messenden Leiter gelegt werden und die Stromstärke induktiv messen, ohne selbst
einen Einuss auf die zu messenden Ströme auszuüben. Abbildung 4.7(a) zeigt einen
der eingesetzten Stromwandler der Firma
1
LEM.
Der zu messende Leiter wird durch die
Önung ( ) gelegt. Proportional zur Stromstärke, die den Leiter durchieÿt, ändert sich
2
die Spannung am Ausgang ( ). Diese wird anschlieÿend in der Schaltung Amp verstärkt
und an den A/D-Wandler als Spannungswert A
C
weitergegeben.
1
2
(a) Stromwandler
(b) Lab jack UE9
Abbildung 4.7: Bauteile der Messstrecke
4.4 A/D-Wandler
Um die Werte des Messwandlers am PC auslesen zu können, ist die Umwandlung der
analogen Signale des Wandlers in digitale Werte erforderlich. Diese Aufgabe wird von
einem A/D-Wandler übernommen, derzeit von einem
LabJack UE9 2 ,
siehe Abbildung
4.7(b). Das Gerät misst bis zu 112 analoge Spannungen im Bereich von 0 bis 5 Volt und
erlaubt das Abfragen der Werte mit 16 Bit Genauigkeit über die USB-Schnittstelle. Es
ist also theoretisch eine Messgenauigkeit von 0.08 mV möglich. Eine genauere Analyse
der Messabweichung erfolgt in Kapitel 5. Für das Gerät werden derzeit nur Treiber für
Microsoft Windows angeboten, eine Portierung auf Linux wird noch entwickelt.
2
http://labjack.com/ue9/specs
25
4 Entwurf der Messumgebung
4.5 Auswertungssoftware
Die Messwerte des A/D-Wandlers können mit dem vorgestellten Aufbau über
USB
gelesen werden, ebenso können die datenbankinternen Messwerte über
abgefragt
JMX
aus-
werden. Eine Software, die beide Kanäle miteinander vereint und aufbereitet, wird nun
benötigt. Diese Entwicklung und Implementierung der Software wird im Folgenden vorgestellt.
4.5.1 Aufbau der Software
Output
Monitoring
Remote
<<events >>
XtcDriver
XTC
Configuration
LabjackDriver
Labjack
Abbildung 4.8: Implementierung der Auswertungssoftware
Abbildung 4.8 skizziert den Aufbau der Auswertungssoftware. In der Abbildung sind
im unteren Bereich die Datenbank sowie der A/D-Wandler zu sehen. Die Messdaten der
XtcDriver
beiden Quellen werden durch Treiber (
LabjackDriver ) in ein einheitliches
Monitoring ) ereignisbasiert übermit-
und
Format überführt und der Auswertungssoftware (
telt. Der Prozess kann über eine
Remote -Schnittstelle gesteuert und kontrolliert werden,
dadurch ist die Integration in eine Benchmark-Suite möglich. Die Ausgabe der Messdaten erfolgt auf mehrere Ausgabeziele, beispielsweise in eine Datei oder Datenbank oder
auf den Bildschirm zur direkten Ansicht. Durch die verschiedenen Ausgabeziele wird die
Anzeige der Messdaten in Echtzeit, als auch die persistente Speicherung für die spätere
Auswertung, ermöglicht. Um die Auswertungssoftware den verschiedensten Testszenarien anzupassen und die Zusammenstellung der Messpunkte und Ausgabeziele individuell
gestalten zu können, wird eine Kongurationsdatei verwendet. Im Folgenden werden die
einzelnen Teile der Software beschrieben und deren Interaktion erklärt.
26
4.5 Auswertungssoftware
4.5.2 Implementierung
Die Software wurde in Java geschrieben und bei der Entwicklung in mehrere Pakete
unterteilt, die aufeinander aufbauen und Funktionen ergänzen. Durch die Unterteilung
in Pakete wird einerseits die Übersichtlichkeit gewahrt, andererseits ist die Funktionalität der einzelnen Pakete klar getrennt, entsprechend dem Entwurfsmuster
Concerns.
Separation of
Dadurch werden Abhängigkeitskonikte vermieden und die einzelnen Pakete
können einfach erweitert, ausgetauscht oder in andere Programme integriert werden. Der
Aufbau der Pakete ist in Abbildung 4.9 dargestellt.
Remote
Output
Configuration
Monitoring
LabjackSensors
LabjackDriver
XtcSensors
Sensors
XtcDriver
BasicPackage
Abbildung 4.9: Pakete der Auswertungssoftware
Um die benötigten Funktionalitäten bereitzustellen, wurde von den unterschiedlichen
Datenformaten des A/D-Wandlers und der Datenbank abstrahiert und über eine Zwi-
Sensors ). Auÿerdem wurden Treiber
(LabjackDriver und XtcDriver ), um
schenschicht in ein einheitliches Format überführt (
für die Ansteuerung der beiden Geräte entwickelt
ein einfaches Arbeiten mit dem A/D-Wandler und der Monitoring-Schnittstelle der Datenbank zu ermöglichen. Zusätzliche Pakete erweitern den Umfang der Software um eine
Remote ) und die Unterstützung von Kongurationsdateien (Conguration ). Im Folgenden werden die einzelnen Pakete beschrieben und deren Funktionen
Remote-Schnittstelle (
erläutert.
BasicPackage
Dieses Paket stellt grundlegende Objekte zur Verfügung, die von vielen anderen Paketen verwendet werden. Die Ereignis-Schnittstellen werden hier deniert, ebenso die
Schnittstellen, über die aufbauende Pakete kommunizieren. Allgemeine Routinen zur
Fehlerbehandlung und -ausgabe werden in diesem Paket zur Verfügung gestellt. Diese
Fehlerbehandlungsroutinen sehen vor, bei (lokalen) Fehlern, etwa der Unterbrechung der
Datenbankbankverbindung oder dem Neustart des A/D-Wandlers, eine Warnmeldung
an die aufrufenden Pakete zu senden und automatisch einen Neustart der fehlgeschlagenen Komponente zu veranlassen. Dadurch können kleinere Fehler abgefangen und für
27
4 Entwurf der Messumgebung
die anderen Pakete unsichtbar, behoben werden, ohne den gesamten Testlauf zu behindern. Nicht automatisch zu behebende Fehler werden protokolliert und an andere Pakete
gemeldet.
Sensors
In diesem Paket wird das grundlegende Sensor-Interface deniert, über das Werte eines
bestimmten Messaufnehmers abgefragt werden. Dadurch werden die Datentypen der unterschiedlichen Messfühler gekapselt und können von aufbauenden Paketen einheitlich
verwendet werden.
Sensor-Interface
Sensor <Interface>
Jeder Sensor gibt den Wert ei-
nes Fühlers als Dezimalzahlen mit beliebiger Genauigkeit (Java-Typ:
Genauigkeit
der
BigDecimal )
Messwerte
bei
zurück, um die
Umrechnungen
nicht durch Rundungsfehler zu verfälschen. Dieser
Datentyp garantiert auÿerdem die Konvertierbar-
+getValue()
: BigDecimal
+getMinValue() : BigDecimal
+getMaxValue() : BigDecimal
keit aller Zahlenwerte in dieses Format. Dadurch
ist es möglich, Messwerte, die in beliebigen Zahlenformaten vorliegen, in die Messumgebung zu integrieren.
Abbildung 4.10: Sensor-Interface
Hilfs-Sensoren
Es existieren auch Sensoren, um
mehrere Werte zu aggregieren. Diese sogenannten
Hilfs-Sensoren können einfache arithmetische Operationen auf Sensordaten durchführen, wie beispielsweise das Summieren einer Liste von
SumSensor oder das Dividieren zweier Sensorwerte durch den DivisionSensor. Durch das Verschachteln mehrerer Hilfs-Sensoren können auch kompliziertere
Sensoren durch den
Operationen durchgeführt werden. Eine Auistung aller Sensoren ist in Tabelle 4.2 zu
nden.
28
4.5 Auswertungssoftware
Basic Sensors
Tabelle 4.2: Liste der Sensoren
Sensor Name
Parameters
Description
ConstantSensor
c : constant value
Returns a constant value c.
SumSensor
List of Sensors
Returns the sum of all sensors.
ProductSensor
List of Sensors
Returns the product of all sensors.
DierenceSensor
a, b : Sensor
Returns the dierence of the two sensors.
QuotientSensor
a, b : Sensor
Returns the quotient of the two sensors.
DeltaSensor
a : Sensor
Returns the dierence to the last sensor value.
SmoothingSensor
a : Sensor
Performs exponential smoothing of the sen-
alpha : 0 .. 1
sor values with a given alpha and returns the
smoothed value.
PercentageSensor
a, b : Sensor
Returns the percentual ratio of two sensors,
therefore the return value ranges from 0 to
100.
HistoricalSensor
a : Sensor
Saves n sensor values in an internal buer
n : history size
and returns the oldest one.
Sensor Name
Parameters
Description
BytesToKBytes
a : Sensor
Returns the value divided by 1 K (
BytesToMBytes
a : Sensor
Returns the value divided by 1 M
BytesToGBytes
a : Sensor
Returns the value divided by 1 G (
Conversion Sensors
Labjack Sensors
1024)
1024 1024)
1024)
(1024 1024 Sensor Name
Parameters
Description
CurrentSensor
s : Source
Converts the voltage of the source s to the
o : Range
output range o.
s : Source
Converts the voltage of the source s to the
o : Range
output range o.
v :
Returns the product of the two sensors.
VoltageSensor
PowerSensor
WorkSensor
Xtc Sensors
VoltageSensor
c : CurrentSensor
v : VoltageSensor
c : CurrentSensor
Returns the integral of the product of the
two sensors over time.
Sensor Name
Description
SystemCpuLoadSensor
Returns the cpu load caused by system processes.
UserCpuLoadSensor
Returns the cpu load caused by user processes.
29
4 Entwurf der Messumgebung
TotalCpuLoadSensor
Returns the total cpu load.
FreeMemorySensor
Returns free memory (in bytes).
UsedMemorySensor
Returns used memory (in bytes).
TotalMemorySensor
Returns total memory (in bytes).
TotalBlockCountSensor
Returns the number of total blocks.
UsedBlockCountSensor
Returns
the
number
of
allocated
(used)
blocks.
FreeBlockCountSensor
Returns the number of released (free) blocks.
BlockReadCountSensor
Returns the number of block read operations.
BlockWriteCountSensor
Returns the number of block write operations.
BlockAllocatedCountSensor
Returns the number of block allocate operations.
BlockReleaseCountSensor
Returns the number of block release operations.
ContainerExtentCountSensor
Returns the number of container extension
operations.
TotalPageCountSensor
Returns the number of total pages in the buffer.
UsedPageCountSensor
Returns the number of used pages in the buffer.
FreePageCountSensor
Returns the number of free pages in the buffer.
FixCountSensor
Returns the number of x operations in the
buer.
UnxCountSensor
Returns the number of unx operations in
the buer.
AccessCountSensor
Returns the number of buer accesses (hit +
miss).
HitCountSensor
Returns the number of buer hits.
MissCountSensor
Returns the number of buer misses.
LabjackDriver
Dieses Paket stellt die Verbindung zum A/D-Wandler her. Obwohl der Hersteller des
A/D-Wandlers einen Treiber zur Verfügung stellt, war die Entwicklung dieser Zwischenschicht notwendig, um die Handhabung des Geräts zu vereinfachen und den Treiber auf
LabjackDriver erlaubt
USB und Ethernet, sowie
die anwendungsspezischen Schnittstellen abzubilden. Das Paket
das Aunden von A/D-Wandlern der Marke
Labjack
über
das Önen einer Verbindung zum Gerät. Ebenso können Anfragen an das Gerät gestellt
und über eine ereignisbasierte Schnittstelle neue Messwerte angezeigt werden. Das Paket
30
4.5 Auswertungssoftware
erlaubt es, die USB-Verbindung zum A/D-Wandler bei Bedarf oder im Fehlerfall automatisch wiederherzustellen. Es bildet auÿerdem die Messwerte des A/D-Wandler aus
0 .. 20 Ampere
0 .. 12 Volt
...
0 .. 20 Ampere
0 .. 12 Volt
...
0 .. 5 Volt
Analogue Values
PC
Digital Values
Measurement Device
A/D-Converter
Measurement Software
Abbildung 4.11: Analog/Digital-Wandlung und Spannungskonvertierung
dem Bereich von 0 bis 5 Volt linear auf den Wertebereich der gemessenen Ströme ab.
Abbildung 4.11 zeigt die Konvertierung der Messwerte in einheitliche 0 - 5 Volt durch den
Messwandler und die nachfolgende Rückrechnung der digitalisierten Werte durch dieses
Paket. Dadurch wird die Umformung durch den Messwandler (siehe 4.3) zurückgerechnet,
um die Werte der tatsächlichen Ströme und Spannungen zu erhalten. Durch die modulare Kapselung der A/D-Wandler-Funktionen ist des Weiteren ein einfacher Austausch der
verwendeten Hardware möglich.
LabjackSensors
Die Messwerte des
LabjackDriver
werden hier in das Sensor-Format überführt. Zusätzlich
zu den Strom- und Spannungssensoren werden Hilfs-Sensoren zur Ermittlung der Leistung (S trom
S pannung ) und des Energieverbrauchs (Leistung
Diese Sensoren sind bereits in Tabelle 4.2 unter
Labjack Sensors
Z eit) bereitgestellt.
zu nden.
XtcDriver
Dieses Paket stellt eine Verbindung über
JMX
zur Monitoring-Komponente der XTC-
Datenbank her. Da das XDBMS je nach Konguration andere Messwerte bereitstellt,
ermittelt dieses Paket die verfügbaren Messwerte und stellt Methoden bereit, um diese event-basiert auslesen zu können. Einige Sensoren, wie beispielsweise der CPU-Auslastungssensor, sind permanent vorhanden, während andere von der Konguration des
Datenbanksystems abhängig sind, zum Beispiel von der Anzahl der Datenbank-Puer,
die sich je nach Anzahl der verfügbaren Datenbankcontainer ändert. Daher ist dieses
Paket in der Lage, sich dynamisch an die vorhandenen Sensoren anzupassen und diese
zur Verfügung zu stellen. Das Paket stellt ebenfalls Fehlerbehandlungs- und Wiederherstellungsroutinen zur Verfügung, falls die Verbindung zur Datenbank unterbrochen wird
oder temporäre Fehler bei der Anfrage auftreten.
XtcSensors
Das Paket wandelt die Messwerte, die von
XtcDriver
geliefert werden, in das einheit-
liche Sensor-Format um und stellt sie zur Verfügung. Auÿerdem werden, basierend auf
31
4 Entwurf der Messumgebung
den Sensoren des Pakets
XtcDriver,
einige abgeleitete Sensoren zur Verfügung gestellt,
beispielsweise die Anzeige der prozentualen Puerauslastung, die sich aus der gesamten
Gröÿe des Puerpools und der Anzahl der verwendeten Seiten ableitet.
Monitoring
Dieses Paket stellt den Programmeinstiegspunkt bereit. Es bündelt die Messwerte aus
den Quellen
LabjackSensors
und
XtcSensors,
koordiniert den Ablauf der Messung und
leitet die Messwerte an einen oder mehrere Ausgabeziele weiter. In diesem Teil der Software läuft der Anwendungsthread ab, der den Zustand der anderen Threads, die für die
Messungen, Ausgabe oder Remote-Steuerung zuständig sind, überwacht und Statusänderungen weiterreicht. Beispielsweise werden Fehler aus den Messungen hierhergeleitet
und protokolliert. Abbildung 4.12 zeigt die internen Abläufe des Pakets. Die Ereignis-
Monitoring
Remote
Status
Events
XtcSensors
State Change
Handling
Log File
Log Events
Output to file
Start / Stop Events
Sensor Data Events
LabjackSensors
Output to ...
Abbildung 4.12: Interne Abläufe des Paktes
datenströme (
Sensor Data Events )
Monitoring
der verschiedenen Quellen werden an die Ausgabe-
adapter weitergeleitet, zu sehen im unteren Bereich der Abbildung. Statusänderungen,
wie Warnungen und Fehler, werden intern verarbeitet (
State Change Handling )
und in
einer Protokolldatei vermerkt. Je nach Ereignis wird die Messung angehalten oder fortgesetzt. Die Remote-Schnittstelle (siehe 4.5.2) kann ebenfalls Statusänderungen melden
und damit den Ablauf der Messung beeinussen.
Output
Die Messwerte können in Echtzeit auf dem Bildschirm ausgegeben werden, um einen direkten Einblick in die aktuelle Messung zu erhalten, auÿerdem erlaubt dieses Paket die
persistente Speicherung der Werte für spätere Analysen. Um Messwerte auf beliebigen
Zielen ausgeben zu können, wurde eine Schnittstelle deniert, die für unterschiedliche
Ausgabezwecke implementiert werden kann. Je nach Ausgabeziel können die Schnitstellen
ConsoleAdapter
(für Ausgaben auf der Konsole),
Benutzeroberäche) und
FileAdapter
GuiAdapter
(für Ausgaben in eine
(für die Ausgabe in eine Datei), implementiert wer-
den, wie Abbildung 4.13 zeigt. Für jede der Schnittstellen wurde eine Referenzimplementierung erzeugt, die Ausgaben auf dem entsprechenden Gerät koordiniert. Beispielsweise
steht für die Ausgabe in eine Datei die Klasse
CvsOutput
zur Verfügung, die alle Mess-
werte in eine kommaseparierte Datei speichert. Für die Ausgabe auf der Konsole stehen
Klassen zur Verfügung, um die Messwerte tabellenartig auszugeben, Ausgaben in einer
32
4.5 Auswertungssoftware
OutputAdapter
+update()
+startOutput()
+stopOutput()
ConsoleAdapter
GuiAdapter
+add(ConsoleControl)
+add(GuiControl)
FileAdapter
+add(Sensor)
Abbildung 4.13: Ausgabe-Schnittstellen
GUI können entweder als Grak (siehe Abbildung 4.14) oder als Textwerte ausgegeben
werden. Für die Ausgabe als Grak wird die quelloene Java-Bibliothek
JFreeChart 3
eingebunden, die alle Funktionen zum Zeichnen von Graken bereitstellt. Um die Bibliothek thread-sicher zu gestalten, mussten alle verwendeten Funktionsaufrufe durch
Wrapper-Klassen abgefangen und synchronisiert werden.
Abbildung 4.14: GUI-Ausgabe als Grak
Conguration
Die Zusammenstellung der Sensoren, sowie die Umrechnungsfunktion des A/D-Wandlers
müssen kongurierbar sein, um die Software an individuelle Messungen anpassen zu können. Ebenso muss die Darstellung der Ausgabe und die verwendeten Quellen (XTC, Labjack, andere Quellen) dynamisch kongurierbar sein. Dadurch wird die Verwendbarkeit
der Software für mehrere Messszenarien, als auch für mehrere Benutzer gewährleistet.
Das Paket
Conguration
ist in der Lage, eine Kongurationsdatei einzulesen und die
anderen Pakete entsprechend zu kongurieren. Diese Klasse initialisiert die benötigten
Verbindungen zur Datenbank und zum A/D-Wandler, stellt die Sensoren zusammen und
3
JFreeChart:
http://www.jfree.org/jfreechart/
33
4 Entwurf der Messumgebung
konguriert die Ausgabeziele.
Der Kongurationsablauf ist wie folgt:
1. Herstellung der Verbindung zum A/D-Wandler
2. Laden und Kongurieren der elektrischen Sensoren
3. Herstellung der Verbindung zur Datenbank
4. Laden und Kongurieren der Datenbank-Sensoren
5. Initialisieren der Ausgabeziele
6. Abbilden der Sensoren (aus 2. und 4.) auf Ausgabeziele
7. Aktivierung der Remotesteuerung
Nachdem diese Schritte durchlaufen wurden, ist die Auswertungssoftware bereit und
Messläufe können gestartet werden.
Aufgrund der Komplexität der Software und der während der Entwicklung ständig
wechselnden Schemata wurde die Kongurationsdatei nicht, wie ursprünglich geplant,
als XML-Datei entworfen, sondern als vorkompilierte Java-Klasse. Die Verwendung einer
Java-Klasse zum Einlesen der Konguration bringt einige Nachteile mit sich. So ist die
Konguration nach dem Kompilieren nur noch maschinenlesbar und statisch. In zukünftigen Versionen der Software ist eine dynamische, zur Laufzeit veränderbare Sensor- und
Ausgabekonguration geplant, siehe auch 6.2.3.
Remote
Um die Software in andere Projekte, wie etwa Benchmarking-Anwendungen, integrieren zu können, wurde die Software mit einer Schnittstelle zur Remote-Steuerung ausgestattet. Damit können grundlegende Aktionen, wie etwa das Starten und Stoppen einer
Messung, durchgeführt werden. Zur Remote-Steuerung verfügt das Programm über eine RMI-Schnittstelle. Über diese Schnittstelle kann die Messung gestartet und beendet
und der derzeitige Status abgefragt werden. Zusätzlich kann ein sogenannter
Checkpoint
gesetzt werden. Dieser wird in der Ausgabe vermerkt und ermöglicht so das Setzen von
Marken während der Messung. Dadurch wird die Auswertung der Daten erleichtert. Der
Wert des Checkpoint kann über einen Sensor abgefragt werden, er fügt sich damit in die
wohlbekannte Schnittstelle.
4.5.3 Integration in Benchmark-Suite
Die Remote-Schnittstelle der Auswertungssoftware erlaubt die Ansteuerung durch die
ebenfalls am Lehrstuhl entwickelte Benchmark-Suite. Diese kann vordenierte Anfragen
an die Datenbank ausführen und die Laufzeiten der Aufrufe messen. Zur Konguration
wird eine XML-Kongurationsdatei verwendet.
Der Aufbau der Benchmark-Suite ist wie folgt: Ein Koordinator liest die XML-Konguration und verteilt die Benchmarkaufgaben an auf mehrere Rechner verteilte Agenten.
Diese Agenten wiederum verteilen die Aufgaben an mehrere lokale Klienten. Die Klienten stellen eine Verbindung zur Datenbank her und führen die Aufgaben aus. Dabei
34
4.5 Auswertungssoftware
Coordinator
Agent
Client
Agent
Client
…
…
XTC
Abbildung 4.15: Aufbau der Benchmark-Suite
messen sie die Ausführungszeit und senden diese über den Agenten an den Koordinator
zurück. Der Koordinator selbst kann ebenfalls auf die Datenbank zugreifen, etwa um
Datenbankinstanzen zu starten oder die Datenbank vor den Messläufen wiederherzustellen. Abbildung 4.15 zeigt den Aufbau der Suite. Dieser Aufbau ermöglicht die verteilte
und parallele Ausführung von Anfragen und damit die Simulation realistischer Szenarien. Um die Benchmark-Suite mit der Auswertungssoftware zu koppeln, mussten neue
Operationen deniert werden, die, anstatt mit der Datenbank, mit der Software interagieren. Dadurch können Benchmarks nun auch in Bezug auf die Energieezienz ausgewertet
werden. Da die Auswertungssoftware und die Benchmark-Suite separate Protokolldateien
schreiben, muss eine kombinierte Auswertung manuell erfolgen, allerdings können bereits
bestehende Benchmark-Denitionen für die zusätzliche Messung des Energieverbrauchs
einfach erweitert werden.
35
5 Testmessungen
Mit der vorgestellten Hard- und Software ist es prinzipiell möglich, den Energieverbrauch
eines Rechners komponentengenau zu bestimmen. Bevor die Messstrecke für den praktischen Einsatz freigegeben wird, muss die korrekte Funktion der einzelnen Geräte überprüft und die gesamte Messabweichung ermittelt werden. Gleichzeitig wird anhand der
einzelnen Testaufbauten das prinzipielle Vorgehen zur Messung des Energieverbrauchs
erläutert.
5.1 Test der Auswertungssoftware
Die Auswertungssoftware liest die Werte des A/D-Wandlers und der Datenbank ein und
gibt diese gemeinsam auf mehrere Ausgabemedien aus. In diesem Test wird überprüft,
ob die Software korrekt arbeitet und die Korrelation der Werte wie gefordert vornimmt.
Eventuelle Verzögerungen der beiden Eingabekanäle (XTC-Datenbank & A/D-Wandler)
werden durch diesen Test aufgedeckt.
5.1.1 Testaufbau
Auf der in Kapitel 4 vorgestellten Hardware wird das XTC-Datenbanksystem in seiner
aktuellsten Entwicklungsversion gestartet. Diese Version besitzt noch keine Optimierungen für Flash Disks oder energieoptimierte Algorithmen. Da dieser Testlauf dazu dient,
die Software auf korrekte Funktion zu testen, wird der A/D-Wandler nicht verwendet,
um die elektrischen Daten zu liefern. Stattdessen wird das Paket
einen
Mock-up
LabjackDriver
durch
ausgetauscht, der als Messwert für die Spannung konstante Werte liefert
und die Stromstärke proportional zur DBMS-Auslastung variiert.
Mock-up
Da der Messwandler und der A/D-Wandler eine potentielle Fehlerquelle sind, die vor
der Verwendung ebenfalls getestet werden müssen, wird auf diese Komponenten im ersten Testlauf verzichtet. Um die Funktionalität dieser Komponenten nachzubilden, wurde
ein sogenannter Mock-up entwickelt. Dieser kann von der Auswertungssoftware über die
Schnittstellen des
LabjackDriver
abgefragt werden, liefert allerdings keine echten Mess-
werte. Stattdessen werden die Datenbankparameter über
JMX
abgefragt und entspre-
chend der Auslastung des Systems ktive Messwerte erzeugt. Die Stromspannung wird
als konstanten Wert zurückgegeben, die Stromstärke nach folgender Formel variiert:
C urrent
=
Baseload
+
variantP art
usage
%
37
5 Testmessungen
MeasurementDevice
(InternalDevelopment)
Database
(XTC)
Mockup
A/DConverter
(LabjackUE9)
Measurement
Software
Abbildung 5.1: Mock-up für den Test der Auswertungssoftware
Component
Tabelle 5.1: Simulationsparameter des Mock-up
Baseload
variantPart
component-specic usage
Mainboard
3.0 A
2.0 A
CPU Load (0 - 100 %)
Hard Disk
1.0 A
0.2 A
Access to Container 0?
Yes
Flash Disk
0.0 A
0.2 A
! 100 %, No ! 0 %
Access to Container 1?
Yes
! 100 %, No ! 0 %
C urrent bezeichnet die Stromstärke, die als Messwert zurückgegeben wird. Sie setzt sich
zusammen aus der Grundlast der Komponente, die auch bei Leerlauf verbraucht wird
(Baseload) und der nutzungsabhängigen Last (variantP art). Die Auslastung (usage)
wird komponentenspezisch ermittelt. Für die Stromstärke des Mainboard wurde die
CPU-Nutzung als Auslastungsmaÿ herangezogen, für die Festplatte und Flash Disk wurden Lese- und Schreibzugrie auf die Datenbankcontainer betrachtet. Ein Containerzugri führt zu einer kurzfristigen, hundertprozentigen Auslastung der betreenden Kom-
Container 0 ) asso-
ponente. Die Festplatte wurde dabei mit der ersten Datenbankdatei (
Container 1 ).
ziiert, die Flash Disk mit der zweiten (
Die Stromstärke wurde nur an den 5-Volt-Leitungen der Komponenten variiert, dadurch ergibt sich für das Mainboard eine elektrische Leistung zwischen 15 und 25 Watt.
Die Festplatte hat einen Leerlaufverbrauch von 5 Watt, maximal verbraucht sie 6 Watt.
Das Flash-Laufwerk hat in dieser Simulation im Leerlauf keinen Stromverbrauch, bei
Zugrien maximal 1 Watt.
Die Auswertungssoftware wird so konguriert, dass sie die internen Datenbankparameter CPU-Auslastung, Container-Zugrie und den Checkpoint-Sensor abfragt. Auÿerdem
ermittelt die Software die elektrischen Werte für das Mainboard und die beiden Platten.
Alle Werte werden als Graphen angezeigt und in eine Protokolldatei geschrieben.
5.1.2 Testablauf
Der Ablauf des Tests ist in Abbildung 5.2 skizziert. Die Datenbanksoftware wird im
Installationsmodus gestartet und erstellt die Containerdateien neu, die Datenbank ist
38
5.1 Test der Auswertungssoftware
XTC
MonitoringSoftware
connect
BenchmarkSuite
<<events>>
SetCheckpoint
PUTDOCUMENT
return
SetCheckpoint
Abbildung 5.2: Ablauf der Testmessung
also leer. Anschlieÿend wird XTC erneut gestartet und wartet auf Anfragen. Nun wird
die Auswertungssoftware gestartet und nimmt eine Verbindung zur Datenbank auf. Die
Messung bendet sich nun im Standby-Modus und wartet auf das Start-Signal. Es wird
ein Testlauf der
Benchmark-Suite
gestartet. Dieser Testlauf startet die Auswertung, und
wartet einige Sekunden, um den Leerlaufzustand durch die Software protokollieren zu
Container
0 der Datenbank eingefügt. Nach Ende der Einfügeoperation setzt die Benchmark-Suite
einen weiteren Checkpoint. Anschlieÿend wird das gleiche Dokument in den Container 1
lassen. Anschlieÿend wird ein
Checkpoint
gesetzt und ein Dokument in den
eingefügt.
5.1.3 Testergebnisse
Die Ergebnisse der Messung sind in Abbildung 5.3(a) und 5.3(b) zu sehen. Diese Grak
wurde aus den protokollierten Rohdaten der Auswertungssoftware erzeugt. Zur Veranschaulichung sind die einzelnen Phasen der Messung farbig hinterlegt und kommentiert
worden. Die Werte für den Stromverbrauch während der Einfügeoperationen stammen
ebenfalls aus der Protokolldatei.
Die Schwankungen der Leistung, gut sichtbar bei der Kurve SSD Total Power, sind
Messungenauigkeiten des A/D-Wandlers. Dieser war zusätzlich zum Mock-up mit der
Auswertungsumgebung verbunden, um die Spannungswerte für die restlichen Komponenten zu ermitteln. Sie bewegen sich im Bereich um 0.001 Watt und sind ohne Bedeutung für die Ermittlung der Verbrauchswerte. In der Grak ist zuerst einige Sekunden
39
5 Testmessungen
100
Watts
50
45
10
40
Database Idle
ATX Total Power
35
HDD Total Power
1
SSD Total Power
Store document on HDD
HDD:
29 Joule
30
Checkpoint #
0,1
25
Store document on SSD
SSD:
4 Joule
20
0,01
15
10
0,001
5
0,0001
5:52:52
5:52:50
5:52:48
5:52:46
5:52:44
5:52:42
5:52:40
5:52:38
5:52:36
5:52:34
5:52:32
5:52:30
5:52:28
5:52:26
5:52:24
5:52:22
5:52:20
5:52:18
5:52:16
5:52:14
5:52:12
5:52:10
5:52:08
5:52:06
5:52:04
5:52:02
5:52:00
5:51:58
5:51:56
5:51:54
5:51:52
5:51:50
5:51:48
5:51:46
5:51:44
0
(a) Daten des Mock-up
100
% CPU
1000
# of
Accesses
80
900
60
800
Database Idle
XTC - CPU Usage - Total
40
700
XTC - C 0 - IO - Access
20
600
XTC - C 1 - IO - Access
Store document on HDD
0
500
Store document on SSD
-20
400
-40
300
-60
200
-80
100
-100
5:52:52
5:52:50
5:52:48
5:52:46
5:52:44
5:52:42
5:52:40
5:52:38
5:52:36
5:52:34
5:52:32
5:52:30
5:52:28
5:52:26
5:52:24
5:52:22
5:52:20
5:52:18
5:52:16
5:52:14
5:52:12
5:52:10
5:52:08
5:52:06
5:52:04
5:52:02
5:52:00
5:51:58
5:51:56
5:51:54
5:51:52
5:51:50
5:51:48
5:51:46
5:51:44
0
(b) XTC-Datenbank
Abbildung 5.3: Test der Auswertungssoftware: Ergebnisse
lang keine Datenbankaktivität erkennbar, hier bendet sich XTC im Leerlauf. Ab dem
Zeitpunkt
40
05:52:15
wurde ein Dokument in die Datenbank eingefügt. Zu sehen ist der An-
5.2 Test des A/D-Wandlers
stieg der
Checkpoint-Kurve
und der unmittelbar darauf ansteigende Stromverbrauch des
Mainboards (ATX Total Power). Kurz vor Ende der Einfügeoperation steigt der Energieverbrauch der Festplatte (HDD Total Power) kurz an, bevor ein weiterer Checkpoint
das Ende der Operation anzeigt. Nach einer kurzen Leerlaufperiode startet die zweite
Einfügeoperation. Sichtbar ist der erneute Anstieg des Mainboard-Stromverbrauchs, sowie der Stromverbrauch der SATA-Flash Disk (SSD Total Power).
Parallel dazu ist in der unteren Grak (Abbildung 5.3(b)) das Verhalten der XTCDatenbank zu sehen. Beim Einfügen eines Dokuments steigt die Prozessorauslastung
(XTC - CPU Usage - Total) an, auÿerdem wird auf Datenbankseiten des Externspeichers zugegrien ("XTC - C0/1 - IO Access).
5.1.4 Auswertung der Ergebnisse
Der Testlauf zeigt, dass die Auswertungssoftware korrekt arbeitet und die Messwerte zuverlässig protokolliert. Da eine deutliche Korrelation der datenbankinternen und elektrischen Messwerte zu sehen ist, zeigt das, dass die Software die Messwerte der unterschiedlichen Quellen zeitnah zusammenführt und so die parallele Auswertung der Messdaten
ermöglicht. In Abbildung 5.3(a) fällt auf, dass der Stromverbrauch der Festplatte erst
spät ansteigt, während er bei der Flash Disk breiter verteilt ist. Ursache hierfür ist die
unterschiedliche Gröÿe des Datenbankpuers für die Container. Während der Puer für
Container 0
(Festplatte) groÿ genug war, um das einzufügende Dokument im Hauptspei-
cher zwischenzuspeichern, war der Puer für
Container 1
(Flash Disk) deutlich kleiner.
Daher musste im ersten Fall erst bei Ende der Transaktion auf die Festplatte zugegriffen werden, um alle Daten persistent zu speichern, im zweiten Fall mussten permanent
Puerseiten herausgeschrieben werden. In der Summe war der Schreibaufwand jedoch
identisch. Da diese Messung ohnehin nicht repräsentativ ist, verfälscht die unterschiedliche Puergröÿe das Ergebnis nicht.
Neben der korrekten Funktion des A/D-Wandlers wird durch diesen Test deutlich,
dass die Remote-Schnittstelle funktioniert und die Auswertungssoftware erfolgreich mit
der Benchmark-Suite zusammenarbeitet.
5.2 Test des A/D-Wandlers
Nachdem die korrekte Funktion der Auswertungssoftware geprüft wurde, wird im nächsten Schritt getestet, ob der A/D-Wandler korrekte Spannungswerte misst und an die
Software weitergibt. Auch wird ausgewertet, ob sich die Messabweichung in einem akzeptablen Bereich bendet. Je nach Anwendungsfall sind Messabweichungen von 5 %
oder weniger vertretbar. Da der A/D-Wandler nach Herstellerangaben eine weitaus genauere Messung erlaubt, sollte die Messabweichung maximal 0.2 Volt oder 0.1 % vom
Referenzwert betragen.
41
5 Testmessungen
Database
(XTC)
Calibrator
(FLUKE702)
Measurement
Software
A/DConverter
(LabjackUE9)
Abbildung 5.4: Test des A/D-Wandlers
5.2.1 Testaufbau
Um den A/D-Wandler zu testen, wird die Verbindung zum Messwandler getrennt und
stattdessen ein Spannungsgenerator, ein sogenannter Kalibrator, eingesetzt. Dieser stellt
kalibrierte Spannungen mit einer Abweichung von weniger als 10
-4
Volt zur Verfügung,
die dann vom A/D-Wandler gemessen werden können. Abbildung 5.4 zeigt den Testaufbau. Die XTC-Datenbank wird für diese Messungen nicht benötigt, der Messaufbau
besteht daher nur aus den genannten drei Komponenten. Die Auswertungssoftware wird
so konguriert, dass sie nur die Spannungswerte des A/D-Wandlers ermittelt und in der
Protokolldatei speichert. Da eine Integration des Spannungsgenerators in die BenchmarkSuite nicht möglich ist, müssen die Messungen manuell durchgeführt werden.
5.2.2 Testablauf
Der Kalibrator wird mit einem Messeingang des A/D-Wandler verbunden und es werden
Spannungen angelegt. Die Auswertungssoftware wird manuell gestartet und protokolliert
alle gemessen Werte in eine Datei. Um den A/D-Wandler im gesamten Messbereich auf
korrekte Funktion zu testen, wird folgender Algorithmus (manuell) durchlaufen:
Algorithm 5.1 Test des A/D-Wandlers: Pseudo-Algorithmus
V oltage
(0
V
()
M easurement:S tart
while V oltage < 5 do
V oltage
Ensure:
(
V oltage
+1
V
V oltage is stable
()
M easurement:S etC heckpoint
Wait 3 - 5 seconds
()
M easurement:S etC heckpoint
end while
()
M easurement:S top
Durch den in 5.1 dargestellten Algorithmus wird der gesamte Messbereich in 1-VoltSchritten durchlaufen und in der Messung protokolliert. Um die gegenseitige Beeinus-
42
5.2 Test des A/D-Wandlers
sung der verschiedenen Spannungseingänge zu testen, wird der oben vorgestellte Algorithmus mehrfach durchlaufen, mit unterschiedlichen Spannungen an anderen Messeingängen
des A/D-Wandlers.
5.2.3 Testergebnisse
Die Ergebnisse der Messung sind in Abbildung 5.5 dargestellt. Der erste analoge Mess-
Analog Input 1 ) war
Analog Input 2 ) wurde nach der
eingang (in der Abbildung:
mit dem Kalibrator verbunden, der
zweite Eingang (
Hälfte der Messung mit einer unge-
eichten 5-Volt Spannungsquelle verbunden. Die dritte Kurve zeigt die Messabweichung
des A/D-Wandlers auf der Sekundärachse an. Deutlich sichtbar sind Wechsel in der ge6
Volts
0,14
Volts
5
AnalogInput1
4
AnalogInput2
0,12
0,1
MeasurementError
(secondaryaxis)
3
0,08
2
0 06
0,06
1
0,04
0
1
12:33:57
0,02
0
12:34:07
12:34:17
12:34:27
12:34:37
12:34:47
12:34:57
12:35:07
12:35:17
12:35:27
Abbildung 5.5: Test des A/D-Wandlers: Ergebnisse
messenen Spannung sowie die konstanten Plateaus zwischen den Wechseln. Auch ist die
Spannungsänderung am zweiten Messeingang zu erkennen. Diese Spannung stammt von
einer ungeeichten Quelle, daher werden nicht 5.0 Volt zur Verfügung gestellt, sondern
ca. 5.2 Volt. Die absolute Messabweichung (Measurement Error), dargestellt auf der
Sekundärachse, schwankt zwischen 0 und 0.015 Volt.
5.2.4 Auswertung der Ergebnisse
Die Ergebnisse zeigen, dass der A/D-Wandler die Spannungen des Kalibrators korrekt
misst und an die Auswertungssoftware weiterreicht. Die Messabweichung von maximal
0.015 Volt ist während der Messung annähernd konstant und im Toleranzbereich. Ausgehend von einer durschnittlichen Spannung von 2.5 Volt beträgt die maximale Abweichung
43
5 Testmessungen
also 0.6 %. Die durchschnittliche Abweichung des A/D-Wandlers beträgt, wie vom Hersteller angegeben, 0.1 %. Es wird deutlich, dass auch durch das Anlegen einer weiteren
Spannung am A/D-Wandler keine zusätzlichen Messfehler auftreten. Damit ist gezeigt,
dass der A/D-Wandler eine hinreichende Genauigkeit bietet, um den Stromverbrauch
des Systems zu messen. Durch diese geringe Abweichung kann die Gesamtabweichung
der Messstrecke, die sich aus den Abweichungen der Komponenten zusammensetzt, insgesamt klein gehalten werden.
5.3 Test des Messwandlers
Der Messwandler wurde bereits vor der Auslieferung von der Elektronikwerkstatt auf
korrekte Funktion getestet. Dennoch wird eine Vergleichsmessung durchgeführt, um die
gesamte Messstrecke zu testen und um den Messfehler zu bestimmen. Da die Strom- und
Spannungsmessungen von unterschiedlichen Komponenten vorgenommen werden, ist ein
getrennter Test beider Schaltungen notwendig.
5.3.1 Testaufbau
to A/D-Converter
Power Supply
Measurement
Device
12
R1
GND
5V
R2
Reference Point
Measurement
Abbildung 5.6: Test des Messwandlers
Um das Messgerät zu testen, wird ein PC-Netzteil ohne angeschlossene Verbraucher
(Festplatte etc.) verwendet. Da solch ein Netzteil im Standby-Betrieb keine Spannungen
liefert, wird Pin 16 des ATX-Anschlusses mit Masse kurzgeschlossen. Dadurch startet
das Netzteil und stellt alle zu messenden Spannungen bereit. Die 12-Volt- und 5-VoltSchienen des Festplattenanschlusses (Molex) werden mit vordenierten Widerständen
verbunden, wie in Abbildung 5.6 dargestellt. Dadurch ist eine vordenierte Last am
Netzteil vorhanden, deren errechneter Stromverbrauch mit dem gemessenen Wert des
Messwandlers verglichen werden kann.
44
5.3 Test des Messwandlers
Messung der Stromstärke
Der Strom I , der durch die Widerstände ieÿt, kann anhand deren Widerstand R (engl.:
Resistance ) und der anliegenden Spannung U
I
Bei einem Widerstand von 1
W(1
=
errechnet werden:
U
R
Ohm) und 12 Volt ieÿen also 12 Ampere. Da die
elektrische Leistung aus dem Produkt von Spannung und Stromstärke berechnet wird
(vgl. Elektrotechnische Grundlagen, 4.2), kann die Leistung des Widerstands durch
folgende Formel errechnet werden, indem die Stromstärke I durch obige Formel ersetzt
wird. Es ergibt sich für die Leistung:
P
= I
U
I = UR
! =
Wird, wie im Beispiel, ein Widerstand von 1
P
U
2
R
verwendet, muss der Widerstand ei-
ner Leistung von 144 Watt standhalten. Typische Widerstände sind allerdings nur für
Lasten unter 5 W ausgelegt, höhere Stärken werden durch gröÿere Ungenauigkeit eingetauscht. Für die 5-Volt-Schiene wird daher ein 5.6
Widerstand verwendet (
R2 ), es
ieÿen also ca. 0.9 Ampere bei einer Leistung von 4.5 Watt. Die 12-Volt-Schiene wird entsprechend mit einem 33
Widerstand kurzgeschlossen (
R1 ), hier ieÿen rein rechnerisch
0.36 Ampere bei 4.36 Watt. Da die verwendeten Widerstände mit einer Fertigungstole-
Reference Point Measurement )
ranz von 10 % geliefert werden, ist eine Referenzmessung (
notwendig, um deren Widerstand und den resultierenden Stromuss genauer zu bestimmen. Zur Referenzmessung wird ein Zangenstrommessgerät verwendet, das, ebenso wie
der Messwandler, die Stromstärke eines Leiters induktiv messen kann. Dadurch kann der
Messwandler gegen die rechnerisch ermittelten Werte und die Referenzmessung verglichen
werden. Die vom Messwandler ausgegebenen Spannungen werden von einem kalibrierten
Voltmeter aufgenommen und angezeigt.
Messung der Spannung
Der für die Stromspannungsmessung zuständige Teil des Messwandlers wird ebenfalls
durch eine Referenzmessung überprüft. Diese Referenzmessung wird von einem Multimeter vorgenommen, das die Spannung an der 5- und 12-Volt-Schiene des Festplattenanschluss misst. Die Werte werden dann mit der gleichzeitig durchgeführten Spannungsmessung des Messwandlers verglichen.
5.3.2 Testablauf
Vor dem Einbau der Widerstände werden diese mit einem Multimeter vermessen, um deren exakten Innenwiderstand zu ermitteln. Nun werden die Widerstände mit dem Festplattenanschluss verbunden und das Zangenstrommessgerät mit dem Multimeter verbunden. Der Messwandler wird mit dem Netzteil verbunden und das Voltmeter an den
45
5 Testmessungen
Tabelle 5.2: Test des Messwandlers: Ergebnisse
(a) Spannungsmessung
Reference
ATX
HDD
SATA
Device
Error
3.3 V
3.40 V
3.36 V
-0.04 V
-1.15 %
5 V
5.02 V
4.98 V
-0.04 V
-0.81 %
12 V
12.23 V
12.12 V
-0.11 V
-0.94 %
5 V
5.04 V
4.99 V
-0.05 V
-0.95 %
12 V
12.25 V
12.12 V
-0.13 V
-1.04 %
3.3 V
3.41 V
3.37 V
-0.04 V
-1.10 %
5 V
5.04 V
4.99 V
-0.05 V
-0.96 %
12 V
12.26 V
12.15 V
-0.11 V
-0.91 %
Mean Error 0.07 V 0.98 %
(b) Strommessung
Resistor
indicated
5.0 V
5.6
12.0 V
33.0
W
W
Current
actual
6.0
32.8
W
W
stated
Reference
Device
0.833 A
0.838 A
0.840 A
0.366 A
0.362 A
0.370 A
(c) Abweichung der Strommessung
$
Reference
stated
Error
Device
$
Refe-
Device
$ stated
rence
5.0 V
0.56 %
0.24 %
0.80 %
12.0 V
-1.05 %
2.21 %
1.13 %
Mean Error
0.81 %
1.22 %
0.97 %
Messausgang des Messwandlers angeschlossen. Die beiden Multimeter zur Referenzmessung werden mit der 5-Volt-Schiene verbunden und deren Anzeigen protokolliert. Ebenso
werden die Ausgangsspannungen des Messwandlers protokolliert. Da sich die Messwerte
während dem Testlauf nicht verändern, ist eine 5-sekündliche Messung ausreichend. Anschlieÿend wird die gleiche Messung für die 12-Volt-Schiene vorgenommen und ebenfalls
5 Sekunden lang gemessen. Nachdem beide Messungen durchgeführt wurden, können alle
Geräte wieder entfernt werden.
5.3.3 Testergebnisse
Die Ergebnisse der Messungen sind in Tabelle 5.2 zusammengefasst. In der ersten Tabelle
5.2(a) sind die Ergebnisse der Spannungsmessung dargestellt. Die Spannung der Leiter
46
5.4 Analyse der Messabweichung
wurde einmal mit Hilfe eines Mulitmeters als Referenzmessung (
ÿend durch den Messwandler (
ist in der Spalte
Error
Reference ) und anschlie-
Device ) gemessen. Die Abweichung der beiden Messungen
als absolute und relative Abweichung abzulesen. Die gemittelte,
absolute Abweichung der Messungen ist ebenfalls aufgeführt.
Die zweite Tabelle 5.2(b) zeigt die Ergebnisse der Strommessung. Aufgrund der Fertigungstoleranzen wurden die verwendeten Widerstände vermessen und deren Widerstand
in der Tabelle vermerkt. Zu sehen ist eine Abweichung der Werte von der Herstellerangabe um bis zu 7 % (
Resistor indicated
im Vergleich zu
Resistor actual ).
Da diese
Abweichungen fertigungsbedingt und fortan konstant sind, können die gemessenen Widerstandswerte zur Berechnung verwendet werden. Die rechnerisch zu erwartende Strom-
Current stated ) ist in der Tabelle aufgeführt, ebenso die Ergebnisse der Referenzmessung durch das Zangenstrommessgerät (Reference ) und des Messwandlers (Device ).
stärke (
Tabelle 5.2(c) zeigt die prozentuale Abweichungen der Strommessungen voneinander und
vom rechnerisch zu erwartenden Wert. Die durchschnittliche, absolute Abweichung jedes
Vergleichs ist in der Spalte
Mean Error
zu sehen.
5.3.4 Auswertung der Ergebnisse
Die Abweichungen des Messwandlers sind insgesamt sehr gering. Eine Messabweichung
von ca. 1 % bei der Spannungsmessung ist akzeptabel, insbesondere da die Referenzmessung mit einer ähnlichen Ungenauigkeit durchgeführt wurde. Auällig ist, dass der
Messwandlers alle Spannungen um 0.04 Volt zu niedrig angibt.
1
Möglicherweise handelt
es sich hier um einen systematischen Messfehler, bedingt durch Ungenauigkeiten der
Referenzmessung oder interne Verluste des Messwandlers. Eine weitergehende Analyse
dieser Abweichung ist daher sinnvoll, siehe 6.1.1.
Die Messabweichung der Strommessung ist mit durchschnittlich 1 % ebenfalls sehr gering. Da die Referenzmessung eine ähnliche Abweichung aufweist, kann davon ausgegangen werden, dass der Messwandler korrekt arbeitet. Hier ist allerdings keine systematische
Abweichung erkennbar, daher scheint diese nur die Spannungsmessung zu betreen.
Bevor der praktische Einsatz der Messumgebung erfolgt, wird abschlieÿend eine Analyse der Messabweichung vorgenommen, um den gesamten Messfehler der Messstrecke zu
bestimmen und die Auswirkungen auf künftige Messungen zu erläutern.
5.4 Analyse der Messabweichung
Ausgehend vom Tests des A/D-Wandlers in Abschnitt 5.2 und dem Test des Messwandlers in Abschnitt 5.3 kann die Messabweichung der gesamten Messstrecke bestimmt werden. Nur mit Kenntnis der Abweichung einer Messstrecke können zuverlässige Interpretationen der gemessenen Werte erfolgen, da Schwankungen die unter der Messabweichung
liegen, nicht mehr zuverlässig von Messungenauigkeiten unterschieden werden können.
1
Die 12-Volt Spannungen wurden mit dem Faktor 3 umgerechnet.
47
5 Testmessungen
Um die Messabweichung für zuküngte Messungen zu bestimmen, wird die Gesamtabweichung anhand der Abweichung der einzelnen Komponenten hergeleitet und deren
Auswirkungen analysiert.
5.4.1 Herleitung
Die Abweichung einer einzelnen Messung setzt sich zusammen aus der Messabweichung
der an der Messung beteiligten Komponenten, also des Messwandlers, des A/D-Wandlers
und der Auswertungssoftware. Da die Software keine Messungen durchführt, sondern nur
rechnerische Transformationen der Werte vornimmt, ist die Abweichung dieser Komponenten bis auf Rundungsfehler nicht vorhanden. Diese Rundungsfehler sind aufgrund
des verwendeten Datentyps
BigInteger
allerdings vernachlässigbar klein. Die Abweichung
wird also anhand der Abweichung des Messwandlers und des A/D-Wandlers ermittelt.
measurement zwischen reellem Wert xr und in der Auswera wird als Prozentwert angegeben:
jxa xr j 100%
fmeasurement =
xr
Die relative Messabweichung f
tungssoftware angezeigtem Wert x
Die Anzeige der Auswertungssoftware weicht vom reellen Wert um die Abweichung
des Messwandlers (f1 ) und des A/D-Wandlers (f2 ) ab. Da die beiden Geräte in Reihe
geschaltet sind und der A/D-Wandler die (verfälschten) Messwerte des Messwandlers
measurement )
erneut verfälscht, setzt sich die Gesamtabweichung einer Messung (f
aus
beiden Abweichungen zusammen:
measurement = (1 + f1 ) (1 + f2 ) 100%
f
Die elektrische Leistung, die über einen Leiter ieÿt, wird anhand des Produkts von zwei
Messungen (Stromspannung und -stärke) berechnet, daher ergibt sich die Messabwei-
rail
chung des Leiters f
aus dem Produkt beider Messabweichungen. Da die Abweichung
measurement als relativer
für Strom- und Spannungsmessung identisch sind, wird für beide f
Fehler festgelegt:
rail = fmeasurement
2
f
component ,
Die relative Messabweichung einer Hardwarekomponente f
die aus der Summe
mehrerer Leiter zusammengesetzt ist, ändert sich nicht:
component = frail = fmeasurement
2
f
total , also der Summe der Verbräu-
Ebenso ändert sich die gesamte relative Abweichung f
che der Komponenten, nicht:
total
f
2
= component = rail = measurement
= ((1 + 1 ) (1 + 2 ))2
f
f
f
f
f
(5.1)
(5.2)
Setzt man die gemessenen Abweichungen ein, erhält man für die Gesamtabweichung:
f1
)
48
f2
total
f
= 1 0%
= 0 1%
2 2%
:
(5.3)
:
(5.4)
:
(5.5)
5.4 Analyse der Messabweichung
5.4.2 Implikationen
Die durchschnittliche Messabweichung in Höhe von 2.2 % ist ein sollte keine praxisrelevanten Auswirkungen haben. Da die Abweichungen des Messwandlers mit relativ ungenaue
Referenzmessungen verglichen wurden, kann der tatsächliche Fehler geringer sein.
Für die Messung des Energieverbrauchs sind diese Abweichungen ohne Bedeutung, da im
weiteren Forschungsverlauf wesentlich einussreichere Verbesserungen bei der Energieefzienz zu erwarten sind, die die Messungenauigkeit um mehr als den Faktor 5 übertreen.
Selbst das einfache Heruntertakten des Prozessors bei Leerlauf oder das Abschalten der
Festplatte haben bereits einen deutlich gröÿeren Einuss auf die elektrisch Momentanleistung, als durch die Messungenauigkeiten verloren geht. Daher ist gegen eine uneingeschränkte Verwertung der Messergebnisse nichts einzuwenden. Dennoch sollte bei
Ergebnissen, die auf diesen Messungen aufbauen, aus Gründen der Nachvollziehbarkeit
die Messabweichung mit angegeben werden. Insbesondere muss darauf geachtet werden,
dass bei zukünftigen Messungen diese Abweichung beachtet wird und keine Aussagen
über Veränderungen kleiner als die Messabweichung gemacht werden können.
49
6 Ausblick
Mit der hier vorgestellten Mess- und Auswertungsumgebung können nun Energiemessungen durchgeführt werden. Im Folgenden werden einige der geplanten Projekte beschrieben, die von dieser Messstrecke protieren können. Da die Messumgebung zwar das
Ermitteln des Energieverbrauchs erlaubt, allerdings noch einige Verbesserungen möglich
sind, werden auÿerdem einige der geplanten Erweiterungen vorgestellt.
6.1 Erweiterung der Messhardware
Die Hardware selbst ist durch ihren modularen Aufbau einfach zu erweitern. Die bereits
möglichen Energiemessungen können so durch zusätzliche Informationen ergänzt werden.
Im Folgenden werden die bisher geplanten Hardwareerweiterungen vorgestellt.
6.1.1 Genauere Untersuchung der Messabweichung
Da die Spannungsmessungen des Messwandlers, wie in 5.3 erwähnt, um einen konstanten
Wert verfälscht sind, liegt die Vermutung nahe, dass es sich hier um einen systematischen
Messfehler handelt. Für diese Abweichungen kann eine falsch kalibrierte Referenzmessung
ebenso verantwortlich sein wie der Messwandler selbst. Sollte der Messwandler die Ursache für diese Ungenauigkeiten sein, kann die Abweichung durch die Software entsprechend
korrigiert werden. Eine Möglichkeit, die Schaltungen des Messwandlers zu überprüfen,
ist das Verwenden eines Kalibrators, wie in Kapitel 5.2, um vordenierte Spannungen an
die Eingänge des Messwandlers anzulegen. Die Spannungswerte am Messausgang könnten dann mit den kalibrierten Spannungen verglichen werden, um festzustellen, ob die
Abweichungen durch den Messwandler hervorgerufen werden. Falls sich diese Vermutung bestätigt, würde die korrigierte Abweichung der Spannungsmessung nur ca. 0.01
% betragen. Die Gesamtabweichung der Messstrecke würde sich dadurch auf ca. 1.2 %
reduzieren.
6.1.2 Einbeziehung der Kühlenergie
Die Einbeziehung der Kühlenergie, die für den Serverbetrieb benötigt wird, muss noch
in die Messumgebung eingearbeitet werden, da die Beseitigung der Abwärme, die durch
den Betrieb entsteht, einen groÿen Teil des Stromverbrauchs in Anspruch nimmt. Um
die benötigte Menge an Kühlenergie zu ermitteln, kann die Temperaturveränderung der
Serverhardware als Maÿ herangezogen werden. Dazu ist es notwendig, die Messung mit
Temperatursonden zu erweitern.
51
6 Ausblick
6.1.3 Hinzufügen weiterer Messpunkte
Die Messumgebung zeigt bisher nur den Stromverbrauch für das gesamte Mainboard an.
Eine Aufschlüsselung des Energieverbrauchs in Prozessor- und Hauptspeicheranteil würde
den Vergleich von prozessorlastigen mit hauptspeicherlastigen Algorithmen ermöglichen.
Auÿerdem könnte der Gesamtverbrauch der anderen Chips auf dem Mainboard (Northund Southbridge, Netzwerkcontroller, etc.) bestimmt werden. Um die Verbrauchsdaten
der einzelnen Mainboard-Komponenten zu ermitteln, müssen weitere Messpunkte hinzugefügt werden. Da aktuelle Mainboards keine integrierten Messpunkte bieten, um diese
Werte zu ermitteln, müssen die Stromleitungen, die zur CPU und zum Hauptspeicher führen, aufgetrennt und auf ein Messmodul umgeleitet werden. Diese Vorgehensweise bringt
einige Probleme mit sich, da CPU und Hauptspeicher sehr empndlich auf Spannungsschwankungen reagieren. Daher ist diese Erweiterung unter Verwendung der bestehenden
Hardware möglicherweise schwer umsetzbar. Eine Alternative wäre die Verwendung von
Hardware, die bereits die erforderlichen Messpunkte besitzt, wie beispielsweise einige
IBM-Server. [28]
6.1.4 Einbeziehung des Stromverbrauchs des Netzteils
Netzteile sind bei der Betrachtung der Energieezienz erst kürzlich ins Blickfeld der
Industrie gerückt. Viele Standardnetzteile haben gerade bei geringer Auslastung eine
hohe Verlustleistung von 20 % und mehr. [29] Bei Anstieg der Last wird ein Teil des
Stromverbrauchs durch den Rückgang der Verlustleistung abgefangen. Es wäre daher
interessant, den realen Stromverbrauch des Netzteils in die Messung mit aufzunehmen.
Hierzu muss die Messumgebung um ein Modul erweitert werden, das die hohe Spannung
des Netzteils und die relativ geringe Stromstärke messen kann.
6.2 Erweiterung der Software
Die vorgestellte Auswertungssoftware ist, wie gezeigt, in der Lage, die korrekte Korrelation und Ausgabe der Messwerte vorzunehmen, allerdings sind noch zahlreiche Verbesserungen und Erweiterungen der Software denkbar. Einige der angedachten, zukünftigen
Arbeitsfelder werden im Folgenden vorgestellt.
6.2.1 Entkopplung der Messwerte
Die Auswertungssoftware sammelt Ereignisse aus allen Messquellen (Datenbank, A/DWandler), bis zu jeder Quelle ein Ereignis vorliegt. Dann werden alle Werte aus beiden
Quellen zur Ausgabe weitergereicht. Abbildung 6.1 illustriert diesen Vorgang. Kommen
aus einer Quelle mehrere Ereignisse, wird nur das aktuellste Ereignis behalten. Dadurch
ist eine enge Kopplung der Messwerte aus verschiedenen Quellen gewährleistet, allerdings
verringern langsame Ereignisquellen die Genauigkeit der Messdaten aus schnelleren Quellen. Beispielsweise sendet der A/D-Wandler bis zu 100 Ereignisse pro Sekunde, während
52
6.2 Erweiterung der Software
time
A/D-Converter Event
combined Event
XTC Monitoring Event
discarded Event
Abbildung 6.1: Ereignislterung in der Auswertungssoftware
die JMX-Verbindung zur Datenbank in der gleichen Zeit nur ca. 5 Ereignisse sendet.
Dadurch werden die Messwerte des A/D-Wandlers ebenfalls auf 5 pro Sekunde begrenzt.
Die Aufhebung dieser Kopplung würde die Datenmenge und die Aussagekraft der Messungen steigern, da auch kurze Stromspitzen vom A/D-Wandler angezeigt werden könnten, die andernfalls verworfen werden. Da in Abschnitt 5.1 bereits gezeigt wurde, dass die
Software die Korrelation der Daten korrekt vornimmt, würde die Hinzunahme der bisher verworfenen Messwerte keine Probleme bereiten. Die Schnittstellendenitionen der
Ausgabe sehen derzeit allerdings nur die Meldung von gesammelten Ereignissen vor, daher müssen an dieser Stelle Änderungen vorgenommen werden, um einzelne Ereignisse
melden zu können.
6.2.2 Integration in ein grasches Front-End
Um die Messung und Auswertung weiter zu vereinfachen, ist die Integration der Software in das grasche Front-End, ebenfalls am Lehrstuhl entwickelt, eine Aufgabe. Da das
1
Front-End auf der Entwicklungsumgebung Eclipse
basiert, steht im Zuge der Integrati-
on der Austausch der Grakbibliothek JFreeChart gegen eine SWT-basierte Variante an.
Dadurch ist auch eine Performance-Steigerung zu erwarten, da die derzeit verwendete
Grakbibliothek auf das eher langsame
Swing 2
aufbaut. Durch diese Integration können
beispielsweise Anfragepläne, Benchmarks und schlieÿlich auch Messdaten zur Energieefzienz gleichzeitig dargestellt und ausgewertet werden.
6.2.3 Konguration über XML-Dateien
Die Konguration erfolgt derzeit über vorkompilierte Java-Klassen, wie in 4.5.2 erwähnt.
Die damit verbundenen Nachteile können durch den Austausch des Pakets
Conguration
gegen ein XML-basiertes behoben werden. Allerdings erfordert dieser Austausch den
1
2
http://www.eclipse.org/
http://java.sun.com/products/jfc/tsc/articles/architecture/
53
6 Ausblick
Entwurf eines XML-Schemas zur Darstellung der Kongurationsparameter und einer
Schnittstelle zum Laden und Speichern der Parameter.
6.2.4 Entwicklung eines Linux-Treibers
Das Programm kann derzeit nur unter Windows verwendet werden, der Hersteller des
A/D-Wandlers nur für diese Plattform einen Java-Treiber anbietet. Um die Auswertungssoftware plattformunabhängig betreiben zu können, ist die Portierung des Treibers auf
andere Betriebssysteme, in erster Linie Linux, erforderlich. Auÿerdem wird Java bisher
nur als 32-Bit Version unterstützt. Eine Portierung auf 64-Bit ist derzeit allerdings nicht
angedacht, da diese keine erkennbaren Vorteile bietet.
6.2.5 Integration in Benchmark-Suite
Wie in 4.5.2 beschrieben, kann die Auswertungssoftware durch externe Programme, wie
etwa die Benchmark-Suite, gesteuert werden. Das Abfragen der Messwerte über die
Remote-Schnittstelle ist bisher nicht möglich. Zur Auswertung eines Benchmark-Testlaufs
müssen daher die Protokolle der beiden Programme ausgewertet werden. Eine Integration der Messwerte in die Protokolldatei der Benchmark-Suite würde die Auswertung
vereinfachen, da nur noch ein Protokoll auszuwerten wäre. Die Erweiterung der RemoteSchnittstelle, um Messwerte ereignisbasiert an andere Programme zu versenden, wird
benötigt und soll im Zuge der Erweiterung der Software vorgenommen werden.
6.2.6 Einbeziehung der Kühlenergie II
Um die für den Betrieb des Rechners benötigte Kühlenergie zu berechnen, kann, alternativ zum Einsatz von Temperatursensoren, ein Rechenmodell herangezogen werden, um
aus dem Stromverbrauch die Temperaturentwicklung abzuleiten. Da 100 % der verbrauchten Energie in Wärme umgesetzt werden, gestaltet sich die Berechnung der Kühlenergie
einfach. [14] Eine softwarebasierte Herleitung der benötigten Kühlenergie erfordert die
Einbeziehung des Modells, etwa als zusätzliches Paket, das aus den Stromverbrauchswerten der Komponenten deren zusätzlichen Kühlungsbedarf errechnet.
6.2.7 Instrumentierung eines weiteren DBMS
Die Instrumentierung ist bisher nur für das lehrstuhleigene Datenbanksystem entwickelt
worden. Um Energiemessungen anhand eines alternativen Datenbanksystems durchführen zu können, muss ein kommerziell erhältliches, relationales DBMS ebenfalls mit den
erforderlichen Messsonden ausgestattet werden. Viele kommerzielle DMBS, wie beispielsweise IBMs
DB2, verfügen bereits über eine Instrumentierungen, die weit über die benö-
tigten Funktionen hinausgeht. Es würde daher ausreichen, ein neues Paket zur Auswertungssoftware hinzuzufügen, das die systemspezischen Schnittstellen des DBMS kapselt
und im bekannten Sensor-Format zur Verfügung stellt. Dadurch können Messungen auf
unterschiedlichen Systemen verglichen werden und Ergebnisse, die anhand von
mittelt wurden, können anhand der zweiten Plattform veriziert werden.
54
XTC
er-
6.3 Energiemessungen
6.3 Energiemessungen
Das eigentliche Ziel, der Entwurf einer Messstrecke, ist auch ohne die noch anstehenden Erweiterungen der Soft- und Hardware, erfüllt und Messungen können durchgeführt
werden. Einige Aufgaben, bei denen die Messstrecke eingesetzt werden wird, werden nun
vorgestellt.
6.3.1 Vergleich der Energieezienz von Algorithmen
Um grundlegende Erkenntnisse über die Energieezienz verschiedener Algorithmen zu
treen, wird die Software zur Vergleichsmessung eingesetzt. Dabei werden identische Eingabewerte durch verschiedene, alternative Algorithmen bearbeitet und das Verhalten mit
der Messstrecke aufgezeichnet. Im Gegensatz zu herkömmlichen Untersuchungen, die die
Geschwindigkeit oder den Speicherverbrauch des Algorithmus bewerten, wird die Energieezienz der verschiedenen Algorithmen betrachtet (vgl. hierzu die Arbeiten von Höpfner
et. al. 2.2.2). Durch diese Messungen ist es möglich, die Energieezienz von Algorithmen zu bestimmen. Als Klassen von Berechnungen, die in Datenbanksystemen häug
benötigt werden, bieten sich Sortier- und Join-Algorithmen an, von denen es eine Vielzahl von Entwürfen und Implementierungen gibt, die, aus performancetechnischer Sicht,
alle unterschiedliche Charakteristika aufweisen. Ein Vergleich des Energieverbrauchs wäre hilfreich, um den Gesamtverbrauch des DBMS senken zu können, möglicherweise zu
Lasten der Geschwindigkeit. Der Vergleich verschiedener Datenbankpueralgorithmen in
Bezug auf deren Energieezienz ist ebenso aussichtsreich, insbesondere unter den neuen
Eigenschaften, die Flash-Laufwerke mit sich bringen.
6.3.2 Energieezienz von Flash-Laufwerken
Persistente Flash-Speicher haben als Festplattenersatz Potential, da diese einige interessante Eigenschaften mit sich bringen. Da Flash-Laufwerke keine bewegliche Mechanik
benötigen, um auf die gespeicherten Daten zuzugreifen, besitzen diese eine wesentlich
geringere Zugrisverzögerungen als Festplatten. Wahlfreie Zugrie auf Speicheradressen
erfolgen daher in der gleichen Geschwindigkeit wie sequentielle. Dadurch sind FlashSpeicher in der Lage, wesentlich höhere Leseraten zu liefern als Festplatten. Auch haben Flash-Laufwerke einen viel geringeren Energieverbrauch als Festplatten, im Leerlauf
verbrauchen diese so gut wie keinen Strom. Die genaue Ermittlung der Energiecharakteristika von Flash-Laufwerken ist ein weiteres Einsatzgebiet der Messumgebung, um
darauf aufbauend zu evaluieren, inwiefern sich diese neue Technologie verwenden lässt,
um Festplatten zu ersetzen und welche Vorteile sich dadurch ergeben. Der Nachteil von
Flash-Laufwerken ist allerdings deren geringe Schreibrate bei wahlfreiem Schreiben. Aufgrund der elektronischen Charakteristika ist Flash hier nur noch halb so schnell wie eine
Festplatte. Aufgrund dieser Diskrepanz in der Lese- und Schreibgeschwindigkeit, müssen Flash-Laufwerke vom Datenbanksystem anders behandelt werden als Festplatten.
random write ) vermieden werden.
Insbesondere sollte wahlfreies Schreiben (
55
6 Ausblick
Es wurde bereits von Hudlet in [30] untersucht, wie die Performance von Datenbanken
durch den Einsatz von Flash-Laufwerken gesteigert werden kann. Beispielsweise wurde
das Zugrisverhalten von Flash-Laufwerken und Festplatten untersucht und die Speicherung von Daten- und Indexseiten der Datenbank auf die Eigenschaften der Laufwerke
abgestimmt. Durch die hier vorgestellte Software können zusätzlich die Energiecharakteristika der Laufwerke in den Optimierungsprozess einbezogen werden.
6.3.3 Evaluation von Pueralgorithmen
An den Nachteilen der Flash-Laufwerke knüpfen intelligente Datenbankpuer an, die
sich der Charakteristika der Laufwerke bewusst sind und diese, so gut es geht, beachten. Wahlfreies Schreiben ist also zu vermeiden, gleichzeitig ist das Lesen einer Seite,
die sich nicht mehr im Puer bendet, wesentlich kostengünstiger geworden als bei herkömmlichen Festplatten. Diese veränderten Bedingungen werden von mehreren Pueralgorithmen adressiert, die am Lehrstuhl entwickelt werden. Ein direkter Vergleich der
unterschiedlichen Algorithmen gestaltet sich aus Performancesicht recht einfach. Die in
dieser Arbeit entwickelte Messumgebung kann allerdings auch Aussagen über die Energieezienz der Algorithmen liefern.
6.4 Berechnung von Leistungsparametern
Die Messstrecke ermöglicht die detaillierte Bewertung der Energieezienz von Komponenten und Algorithmen, sodass Aussagen über deren Energieezienz getroen werden
kann. Diese Informationen können bereits helfen, um Datenbanksysteme energieezienter zu gestalten.
6.4.1 Leistungskurven
Neben der Messung des Stromverbrauchs wurde in Abschnitt 4.2 eine andere Herangehensweise vorgestellt, die auf Leistungskurven basiert. Diese Kurven würden die Berechnung des Gesamtverbrauchs anhand der Zugrismuster der Datenbank ermöglichen.
Beispielsweise könnte der Energieverbrauch der Festplatte anhand der Lese- und Schreibzugrie der Datenbank unter Zuhilfenahme der Leistungskurve berechnet werden. Durch
diesen Ansatz könnte auf weitere Energiemessungen verzichtet werden, falls hinreichend
genaue Leistungswerte vorliegen, auÿerdem wären mit diesen Kurven Simulationen möglich, um die Energieezienz von Algorithmen zu bewerten, ohne zeitaufwendige Messungen durchzuführen. Wie erwähnt, existieren für die meisten Komponenten jedoch
keine Leistungskurven, daher ist dieser Ansatz bisher nicht durchführbar. Die fehlenden
Leistungskurven können allerdings mit Hilfe der vorgestellten Messumgebung erzeugt
werden, indem der Energieverbrauch vordenierter Arbeitslasten, wie etwa dem sequentiellen Lesen einer Datei oder dem Sortieren eines Arrays, gemessen und auf die logische
Auslastung der Komponente umgerechnet werden. Die so ermittelten Leistungskurven
können bei späteren Messungen die Messstrecke ersetzten und die Verbrauchswerte der
Komponenten aus deren Auslastung errechnen.
56
6.4 Berechnung von Leistungsparametern
6.4.2 Energiebasierte Anfrageoptimierer
Aktuell stützen sich Anfrageoptimierer bei der Bewertung von Anfrageplänen nur auf performancerelevante Werte, um die Ausführungsgeschwindigkeit der Anfragen zu maximieren. Können Anfragen durch Hinzunahme weiterer Systemressourcen schneller ablaufen,
werden diese vom Optimierer mit einbezogen. Ein Trade-O zwischen Performance und
Energieezienz wird bisher nicht gemacht. Im Zuge der Einführung von Green-IT ist, wie
einführend erwähnt, die alleinige Ausrichtung auf Performance nicht mehr zielführend.
Die Bewertung des Energieverbrauchs von Datenbankanfragen, und die Steigerung deren
Energieezienz, auch zu Lasten der Ausführungsgeschwindigkeit, ist ein vielversprechender Ansatz, um Datenbanken insgesamt energieezienter zu gestalten. Harizopoulos et.
Abbildung 6.2: Geschwindigkeit versus Energieezienz, nach [7]
al. haben untersucht, wie sich Anfrageoptimierung und Energieverbrauch verhalten, indem sie die Ausführungszeit und die Energieezienz einer Datenbankanfrage gegenübergestellt haben. Sie haben eine Anfrage auf einer steigenden Anzahl Festplatten ausgeführt. Jede Festplatte senkte die Bearbeitungsdauer der Anfrage, führte allerdings auch zu
einem steigenden Stromverbrauch. Die Abbildung 6.2 zeigt, dass die Gesamtperformance
durch Hinzunahme weiterer Festplatten jederzeit gesteigert werden kann, die Energieefzienz allerdings ab einem gewissen Punkt (66 Festplatten) ihr Maximum erreicht und
wieder abfällt. Das bedeutet, dass das Hinzunehmen weiterer Festplatten zwar mehr Leistung verspricht, allerdings mit sinkender Energieezienz einhergeht. [7] Die vorgestellte
Arbeit geht allerdings nicht von echten Messwerten oder Leistungskurven aus, sondern
setzt einen konstanten Stromverbrauch der Festplatte für die Dauer der Anfrage in die
Rechnung ein. Die mit Hilfe der Messumgebung errechneten Leistungskurven können
hier zu einer detaillierteren Analyse der Energieezienz herangezogen werden. Insbesondere können die Kurven auch zur Bewertung und Optimierung der Anfragepläne von
Datenbankoptimierern und zur Einbeziehung energierelevanter Aspekte in die Anfrageoptimierung verwendet werden. Das schematische Vorgehen bei der Anfrageoptimierung
ist in Abbildung 6.3 dargestellt. [31] Als Meta-Informationen, die dem Optimierer zur
Verfügung stehen, sind auÿer der relationalen Algebra sowie der logischen und physischen
Verteilung der Daten keine weiteren Informationen bekannt. Der Optimierer errechnet
für eine Anfrage verschiedene Pläne und annotiert diese mit Kosten, die sich unter ande-
57
6 Ausblick
SQLQuery,
XQuery,…
rewriting
rewriting
Nlogical
accessplans
Nphysical
accessplans
Table/Index
information
Disk/Storage
information
+Energy
Information
1physical
accessplan
Costbased
planselection
AccessPlan
OptimizerInformation
Abbildung 6.3: Ablauf der Anfrageoptimierung
rem an der Anzahl der benötigten Externspeicherzugrie und deren Zugrisverzögerung
orientiert. Die kostenbasierte Planselektion bevorzugt daher Anfragepläne mit maximaler
Performance. Durch die Einbeziehung energierelevanter Informationen in die Generierung
der Anfragepläne kann die Energieezienz der Anfragepläne als zusätzliches Kriterium
bei der Selektion eines optimalen Anfrageplanes herangezogen werden. Der alleinige Fokus auf energierelevante Merkmale erweist sich hier als unzureichend, da eine gewisse Geschwindigkeit der Anfrageverarbeitung von Datenbankanwendern erwartet wird. Daher
muss ein Mittelweg zwischen zeit- und energieoptimaler Ausführung gefunden werden.
6.4.3 Energiebasierte Benchmarks
Der vorgestellte Benchmark
SPECpower_ssj2008
erlaubt die Bewertung eines Systems
aufgrund energierelevanter Parameter. Getestet werden allerdings Hardwarekomponenten
wie Prozessor oder Arbeitsspeicher und einfache Java-Programme. Da Datenbanktests
fehlen, kann der Benchmark nicht zur Bewertung von Datenbanksystemen herangezogen
werden. Ein dedizierter Datenbankbenchmark, der die Energiezienz eines Datenbanksystems bewertet, fehlt bisher. Als Basis für ein solches Experiment wäre jeder bestehende
Benchmark verwendbar, sofern dieser um Wartezeiten ergänzt werden kann. Da bei einer
energiebasierten Evaluierung die reine Systemperformance nicht maÿgebend ist, muss
das Datenbanksystem nicht voll ausgelastet werden. Eine realistische Simulation erfordert vielmehr eine ausgewogene Mischung wechselnder Auslastungszustände, da nur so
Stromsparmechanismen und Leerlaufverbrauch bewertet werden können.
Ein einheitlicher Benchmark ist für die Vergleichbarkeit und Nachvollziehbarkeit der Messergebnisse unumgänglich, daher ist der Entwurf eines standardisierten, energiebasierten
Benchmarks wichtig für die Verwendbarkeit der vorgestellten Messumgebung.
58
7 Zusammenfassung
Es wird deutlich, dass die Nachfrage nach energieezienten Datenbanken stetig ansteigt
und die Forschungsbemühungen in diesem Bereich verstärkt werden. Die bereits bestehenden Energieoptimierungen sind als oenbar unzureichend zu bewerten, nicht zuletzt, da
sie nicht speziell für den Server- und Datenbankenbereich entwickelt wurden. Die vorgestellten Forschungsarbeiten zeigen die aktuellen Bestrebungen, Server und Datenbanken
energieezienter zu gestalten. Allerdings wird auch hier deutlich, dass das Thema noch
im Entstehen begrien und Grundlagenarbeit notwendig ist. Insbesondere wird deutlich, dass bisher keine dedizierte Messumgebung für den Bereich existierte und sich viel
Arbeiten auf Schätzungen oder Messungen auf exemplarischer Hardware berufen.
Die in dieser Arbeit vorgestellte Messumgebung erlaubt es, detaillierte Messungen an
einem handelsüblichen PC durchzuführen und den Stromverbrauch der Komponenten
mit internen Messwerten der Datenbanksoftware in Korrelation zu setzen. Dadurch kann
das Verhalten der Datenbank analysiert und der Stromverbrauch von Anfragen ermittelt
werden. In dieser Arbeit wurde der Entwurf und die Implementierung aller benötigten
Komponenten der Messumgebung vorgestellt und erste Testmessungen wurden durchgeführt, um die korrekte Funktion der Messstrecke zu zeigen. Die Messabweichung der
Umgebung wurde analysiert und als unbedenklich bewertet. Ausgehend von der vorgestellten Messumgebung wurden einige Anwendungsgebiete aufgezeigt, mit denen sich die
Arbeitsgruppe in Zukunft befassen wird.
Die hier beschriebene Mess- und Auswertungsumgebung wird dazu beitragen, den
Energieverbrauch von Datenbanken zu bestimmen und zu optimieren. Mit ihr kann die
Energieezienz von Algorithmen bewertet und verbessert werden. Dadurch kann bereits
beim Entwurf künftiger Softwaregenerationen die Energieaufnahme berücksichtigt werden, wodurch wirtschaftliche und ökologische Vorteile zu erwarten sind.
Die zahlreichen Verwendungsmöglichkeiten der Messumgebung zeigen den groÿen Bedarf an einer Lösung, um den Energieverbrauch eines Datenbanksystems komponentengenau bestimmen zu können. Dieser Bedarf kann nun mit der hier vorgestellten Soft- und
Hardware gestillt werden.
59
8 Literaturverzeichnis
[1] Koomey, J.G.: Estimating Total Power Consumption by Servers in the U.S. and the
World. Stanford University (2007)
[2] Weiss, A.: Computing in the clouds. netWorker (2007) 1625
[3] European Energy Exchange:
2009)
Üblicher Strompreis gemäÿ KWK-Gesetz (August
http://www.eex.com/de/document/52446/Phelix_Quarterly.xls.
[4] Härder, T.: Green Computing - ein neues Forschungsthema der Informatik. Technical
report, TU Kaiserslautern, AG DBIS (2008)
[5] Energy Information Administration: Total Energy-Related Carbon Dioxide Emissions by End-Use Sector, and the Electric Power Sector, by Fuel Type, 1949-2007 (Januar 2009)
xls.
http://www.eia.doe.gov/oiaf/1605/ggrpt/excel/historical_co2.
[6] Department of Energy: Carbon Dioxide Emissions from the Generation of Electric
Power in the United States. Technical report, USA Department of Energy (2000)
[7] Harizopoulos, S., Shah, M.A., Meza, J., Ranganathan, P.: Energy Eciency: The
New Holy Grail of Data Management Systems Research. In: Biennial Conference on
Innovative Data Systems Research. (2009)
[8] Spector, A.Z.: Distributed Computing at Multi-dimensional Scale. In: International
Middleware Conference. (2008) Keynote
[9] Krishnan, S., Garimella, S.V., Chrysler, G., Mahajan, R.: Towards a Thermal Moore's Law. In: IEEE Transactions on Advanced Packaging. (2007) 462474
[10] Hewlett-Packard Corporation, Intel Corporation, Microsoft Corporation, Phoenix
Technologies Ltd., Toshiba Corporation: Advanced Conguration and Power Interface Specication Rev. 4.0. Technical report,
http://www.acpi.info/
(2006)
[11] Padala, P., Shin, K.G.: Adaptive Control of Virtualized Resources in Utility Computing Environments. In: European Conference on Computer Systems. (2007) 289302
[12] Barroso, L.A., Hölzle, U.: The Case for Energy-Proportional Computing. Computer
(2007)
[13] Host Europe: Host Europe Pressemitteilung (Mai 2007)
de/presse/Pressemeldung230507.
http://www.hosteurope.
61
8 Literaturverzeichnis
[14] See, S.: Is there a pathway to a Green Grid ?? In: IberIAN GRID INFRASTRUCTURE CONFERENCE. (2008) Keynote
[15] Microsoft Corporation: Power Policy Conguration and Deployment in Windows.
Technical report, WinHEC2008, Los Angeles, CA (2008)
[16] Brown, A.L.: The State of ACPI in the Linux Kernel. In: Proceedings of the Linux
Symposium. (2004) 121132
[17] Matthias Nicola and Agustin Gonzalez and Kevin Xie and Berni Schiefer: An XML
Database Benchmark: Transaction Processing over XML (TPoX) .
Technical re-
port, IBM Corporation and Intel Corporation (2009)
[18] Standard Performance Evaluation Corporation:
SPEC Power and Performan-
ce - Benchmark Methodology V1.1.1 (April 2009)
ssj2008/docs/SPECpower-Methodology.pdf.
http://www.spec.org/power_
[19] Poess, M., Nambiar, R.O.: Energy Cost, the Key Challenge of Today's Data Centers:
A Power Consumption Analysis of TPC-C Results. In: VLDB Endowment. (2008)
12291240
[20] Höpfner, H., Bunse, C.: Towards an Energy Aware DBMS - Energy Consumptions
of Sorting and Join Algorithms. In: Grundlagenworkshop von Datenbanken. (2009)
[21] Härder, T., Schmidt, K., Ou, Y., Bächle, S.: Towards Flash Disk Use in Databases
- Keeping Performance While Saving Energy? In: Datenbanksysteme in Business,
Technologie und Web. (2009) 185204
[22] Rivoire, S., Shah, M.A., Ranganathan, P., Kozyrakis, C.:
Energy-Eciency Benchmark.
JouleSort: A Balanced
In: SIGMOD international conference on Manage-
ment of data. (2007) 365376
[23] Lang, W., Patel, J.M.:
Towards Ecofriendly Database Management Systems.
In:
Biennial Conference on Innovative Data Systems Research. (2009)
[24] Sun
microsystems:
Sun
Developer
Network
-
Java
Management
Extensions
http://java.sun.com/javase/technologies/
core/mntr-mgmt/javamanagement/.
(JMX) Technology (August 2009)
[25] Ou, Y.: Performance Analysis and Optimization of XML Database Systems Exemplied by XTC. Master's thesis, TU Kaiserslautern, AG DBIS (2008)
[26] Schnabel, P.: Elektronik-Fibel. Books on Demand GmbH (2007)
[27] Intel Corporation:
ATX Specication Rev. 2.2.
FFDetail.asp?FFID=1&CatID=1
[28] Popa, P.K.:
http://www.formfactors.org/
(2004)
IBM Systems and Technology Group - Managing Server Energy
http://www-07.ibm.com/
systems/includes/content/x/about/pdf/XSW02410USEN.pdf.
Consumption Using IBM PowerExecutive (Mai 2006)
62
8 Literaturverzeichnis
[29] AnandTech: 300W to 450W: 20 Power Supplies on the Test Bench (Dezember 2008)
http://www.anandtech.com/casecoolingpsus/showdoc.aspx?i=3487&p=39.
[30] Hudlet, V.: Scans und Indexzugrie in Flash-basierten Datenbank-Systemen. Diplomarbeit, TU Kaiserslautern, AG DBIS (2009)
[31] Ioannidis, Y.E.: Query Optimization. In: ACM Computing Surveys. (1996) 121123
63
Anhang
65
Abbildungsverzeichnis
2.1
Energiebezogene C O2 -Emissionen je Sektor
2.2
Anteiliger Energieverbrauch von Serverkomponenten
. . . . . . . . . . . . . . . . .
2.3
Virtualisierung von Servern
2.4
Umordnung zeitgesteuerter Ereignisse in Windows 7
. . . . . . . . . . . .
9
2.5
Energieverbrauch von Sortieralgorithmen . . . . . . . . . . . . . . . . . . .
11
3.1
Systemgrenzen und Schnittstellen . . . . . . . . . . . . . . . . . . . . . . .
14
3.2
Java Management Extensions
. . . . . . . . . . . . . . . . . . . . . . . . .
15
3.3
XTC System Activity Monitor
. . . . . . . . . . . . . . . . . . . . . . . .
16
4.1
Aufbau der Messstrecke
. . . . . . . . . . . . . . . . . . . . . . . . . . . .
19
4.2
Leistungskurve einer embedded-CPU . . . . . . . . . . . . . . . . . . . . .
20
4.3
Messung der Stromstärke und -spannung . . . . . . . . . . . . . . . . . . .
21
4.4
Sitz der Messpunkte
22
4.5
Anschlussplan des Messwandlers
. . . . . . . . . . . . . . . . . . . . . . .
22
4.6
Modul zur Strom- und Spannungsmessung . . . . . . . . . . . . . . . . . .
24
4.7
Bauteile der Messstrecke . . . . . . . . . . . . . . . . . . . . . . . . . . . .
25
4.8
Implementierung der Auswertungssoftware . . . . . . . . . . . . . . . . . .
26
4.9
Pakete der Auswertungssoftware
. . . . . . . . . . . . . . . . . . . . . . .
27
4.10 Sensor-Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
28
4.11 Analog/Digital-Wandlung und Spannungskonvertierung
. . . . . . . . . .
31
. . . . . . . . . . . . . . . . . . . .
32
4.13 Ausgabe-Schnittstellen . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
33
4.14 GUI-Ausgabe als Grak
33
6
. . . . . . . . . . . . . . . . . . . . . . . . . .
8
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4.12 Interne Abläufe des Paktes
Monitoring
. . . . . . . . . . . . . . . . . . . . . . . . . . . .
4.15 Aufbau der Benchmark-Suite
3
. . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . .
35
5.1
Mock-up für den Test der Auswertungssoftware . . . . . . . . . . . . . . .
38
5.2
Ablauf der Testmessung
39
5.3
Test der Auswertungssoftware: Ergebnisse
5.4
Test des A/D-Wandlers
5.5
Test des A/D-Wandlers: Ergebnisse . . . . . . . . . . . . . . . . . . . . . .
43
5.6
Test des Messwandlers . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
44
6.1
Ereignislterung in der Auswertungssoftware . . . . . . . . . . . . . . . . .
53
6.2
Geschwindigkeit versus Energieezienz . . . . . . . . . . . . . . . . . . . .
57
6.3
Ablauf der Anfrageoptimierung
58
. . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . .
40
. . . . . . . . . . . . . . . . . . . . . . . . . . . .
42
. . . . . . . . . . . . . . . . . . . . . . . .
67
Tabellenverzeichnis
3.1
Komponenten des Testsystems
. . . . . . . . . . . . . . . . . . . . . . . .
14
4.1
Liste der Messpunkte . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
23
4.2
Liste der Sensoren
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
29
5.1
Simulationsparameter des Mock-up . . . . . . . . . . . . . . . . . . . . . .
38
5.2
Test des Messwandlers: Ergebnisse
46
. . . . . . . . . . . . . . . . . . . . . .
69