Fakult¨ at f¨ ur Informatik
Institut f¨ ur Technische und Betriebliche Informationssysteme Arbeitsgruppe Datenbanken
Masterarbeit
Ein selbstlernendes Entscheidungsmodell f¨ ur die Verteilung von Datenbankoperationen auf
CPU/GPU-Systemen
Verfasser:
Sebastian Breß
26. Februar 2012
Betreuer:
Dr.-Ing. Eike Schallehn
Universit¨at Magdeburg Fakult¨at f¨ur Informatik Postfach 4120, D–39016 Magdeburg
Germany
Prof. Dr.-Ing. habil. Kai-Uwe Sattler
Technische Universit¨at Ilmenau Fakult¨at f¨ur Informatik und Automatisierung
Postfach 100 565, D–98684 Ilmenau Germany
Breß, Sebastian:
Ein selbstlernendes Entscheidungsmodell f¨ur die Verteilung von Datenbankoperationen auf CPU/GPU-Systemen
Masterarbeit, Otto-von-Guericke-Universit¨at Magdeburg, 2012.
Danksagung
Zuerst m¨ochte ich mich bei Dr. Eike Schallehn bedanken, ohne dessen Anleitung und konstruktive Kritik diese Arbeit nicht m¨oglich gewesen w¨are.
Weiterhin m¨ochte ich mich bei Prof. Dr. Kai-Uwe Sattler f¨ur die Bereitschaft be- danken, die Rolle des Zweitgutachters zu ¨ubernehmen.
Bei Andreas L¨ubcke und Dr. Veit K¨oppen m¨ochte ich mich f¨ur Hilfestellungen und Korrekturlesen bedanken. F¨ur Hinweise zum wissenschaftlichen Arbeiten gilt mein Dank Ingolf Geist. F¨ur die Bereitstellung von Literatur gilt mein Dank Alexander Grebhahn.
Ferner m¨ochte ich den anonymen Reviewern des Workshops f¨ur Self-Managing- Database-Systems (SMDB) danken, da durch deren Feedback das Modell signifikant verbessert werden konnte.
Abschließend m¨ochte ich mich bei allen bedanken, die mich w¨ahrend der Anfertigung dieser Arbeit noch unterst¨utzt haben.
ii
Inhaltsverzeichnis
Inhaltsverzeichnis iii
Abbildungsverzeichnis vii
Tabellenverzeichnis ix
Verzeichnis der Abk¨urzungen xi
Abk¨urzungen im Modell xii
1 Einleitung 3
1.1 Hintergrund . . . 3
1.2 Motivation . . . 3
1.3 Ziele . . . 4
1.4 Struktur der Arbeit . . . 4
1.5 Derzeitiger Stand der Technik . . . 5
1.6 Allgemeine Beschreibung des Projektes . . . 5
2 Grundlagen 7 2.1 Grundlegende Begriffe . . . 7
2.2 Grundlegende Architektur von Datenbanken . . . 9
2.3 Anfrageoptimierung . . . 11
2.3.1 Phasen der Anfrageoptimierung . . . 12
2.3.2 Physische Optimierung . . . 12
2.3.3 Zusammenfassung . . . 14
2.4 Datenbank-Tuning . . . 14
2.4.1 Zielstellung . . . 14
iv INHALTSVERZEICHNIS
2.4.2 Optimierbare Systembestandteile . . . 15
2.4.3 Grundlegende Prinzipien . . . 16
2.4.4 Zusammenfassung . . . 17
2.5 Self-Tuning . . . 17
2.5.1 Motivation . . . 17
2.5.2 Prinzipien . . . 18
2.5.3 Zusammenfassung . . . 21
2.6 Interpolationsverfahren . . . 21
2.6.1 Methode der kleinsten Quadrate . . . 21
2.6.2 Interpolation mit kubischen Splines . . . 22
2.6.3 Zusammenfassung . . . 23
2.7 GPU . . . 23
2.7.1 Uberblick . . . .¨ 23
2.7.2 SIMT-Architektur . . . 24
2.7.3 Abgrenzung SIMD- vs. SIMT-Architektur . . . 26
2.7.4 Zusammenfassung . . . 26
2.8 Stand der Forschung . . . 26
2.8.1 Forschungstrend: Auslagerung von DB-Operationen auf GPUs . . 26
2.8.2 Analytische Modelle f¨ur die Ausf¨uhrungszeitsch¨atzung von GPU- Algorithmen . . . 27
2.8.3 Statistik-basierte Ausf¨uhrungszeit-Sch¨atzmodelle . . . 28
2.8.4 Zusammenfassung . . . 31
2.9 Sortieralgorithmen . . . 31
2.9.1 Radixsort . . . 31
2.9.2 Quicksort . . . 32
2.9.3 Mergesort . . . 32
2.10 Zusammenfassung . . . 32
3 Das Entscheidungsmodell 33 3.1 Motivation . . . 33
3.2 Bewertungskriterien . . . 34
3.3 Grundlegendes Modell . . . 35
3.4 Self-Tuning Ausf¨uhrungszeitsch¨atzer . . . 36
3.4.1 Aktualisierung des Modells . . . 36
3.4.2 Self-Tuning-Zyklus des Ausf¨uhrungszeitsch¨atzers . . . 37
3.4.3 Adaption an neue Lastsituationen . . . 38
3.4.4 Statistische Verfahren . . . 40
3.4.5 Zusammenfassung . . . 42
3.5 Entscheidungskomponente . . . 42
3.5.1 Optimierungskriterien . . . 42
3.6 Zusammenfassung . . . 44
4 Diskussion m¨oglicher Erweiterungen 45 4.1 Erweiterung: alternde Statistik . . . 45
4.2 Erweiterung: Ereignisbasierte Modellaktualisierung . . . 46
4.3 Erweiterung: Abschalten des Self-Tunings . . . 47
4.4 GPU-Metriken . . . 48
4.4.1 Motivation . . . 48
4.4.2 Notation . . . 49
4.4.3 Erweiterungen von vorhandenen Metriken . . . 50
4.4.4 Berechnung der totalen Ausf¨uhrungszeit . . . 51
4.4.5 Berechnung der Antwortzeit unter Ber¨ucksichtigung der Parallelit¨at 51 4.4.6 Nutzung bei der physischen Optimierung . . . 52
4.4.7 Zusammenfassung . . . 54
4.5 Modellparameter . . . 54
4.5.1 Ausreißer-Erkennung und Ringpuffergr¨oße . . . 55
4.5.2 Grad von Polynomen bei der Methode der kleinsten Quadrate . . 55
4.5.3 L¨ange der Trainingsphasen . . . 56
4.5.4 Zusammenfassung Modellparameter . . . 56
4.6 Einsatz des Modells in RDBMS f¨ur Joins . . . 56
4.7 Zusammenfassung . . . 57
5 Implementierung und Evaluation 59 5.1 Implementierung . . . 59
5.1.1 Framework Grundlagen . . . 59
5.1.2 Verwendete Bibliotheken . . . 60
vi INHALTSVERZEICHNIS
5.1.3 Kontrollfluss des Frameworks . . . 60
5.1.4 Zusammenfassung . . . 61
5.2 Modell Qualit¨atsmaße . . . 61
5.2.1 Ausf¨uhrungszeitsch¨atzer . . . 61
5.2.2 Entscheidungskomponente . . . 62
5.2.3 Zusammenfassung Modell Qualit¨atsmaße . . . 64
5.3 Fallstudie: Sortierungen . . . 65
5.3.1 Motivation . . . 65
5.3.2 Grundlegender Messprozess . . . 65
5.3.3 Modellparameter . . . 66
5.3.4 Gewinnung der Messdaten . . . 66
5.3.5 Darstellung der Experimente in Modellnotation . . . 67
5.3.6 Validierung der Sch¨atzkomponente . . . 68
5.3.7 Validierung der Entscheidungskomponente . . . 71
5.4 Zusammenfassung . . . 79
6 Abschluss 81 6.1 Zusammenfassung . . . 81
6.2 Beurteilung . . . 81
6.3 Ausblick . . . 82
Literaturverzeichnis 85
Abbildungsverzeichnis
2.1 DBMS Architektur in Anlehnung an [Vos08] . . . 9
2.2 Optimierungsproblem in Anlehnung an [SHS05] . . . 13
2.3 Relevante Systemkomponenten beim Datenbank Tuning in Anlehnung an [Sch11] . . . 15
2.4 Datenbank-Tuning-Quandrilemma in Anlehnung an [Sch11] . . . 16
2.5 IBMs Self-Tuning-Zyklus MAPE in Anlehnung an [KC03] . . . 20
2.6 Grid aus Thread-Bl¨ocken, entnommen aus [NVI12b] . . . 24
3.1 Informationsfluss im Modell . . . 36
3.2 Beispielalgorithmen GPU und CPU f¨ur eine Operation O . . . 39
3.3 Beispiel f¨ur die Erh¨ohung der Last auf der CPU . . . 40
3.4 Beispiel f¨ur das Sinken der Last auf der CPU . . . 40
3.5 Beispiel f¨ur eine zu starke Erh¨ohung der Last auf der CPU . . . 41
5.1 Ausf¨uhrungskurven der Sortieralgorithmen . . . 67
5.2 Durchschnittlicher prozentualer Sch¨atzfehler bei der Methode der klein- sten Quadrate . . . 70
5.3 Gesch¨atzte und gemessene Werte . . . 70
5.4 Durchschnittlicher prozentualer Sch¨atzfehler bei kubischen Splines . . . . 72
5.5 Gesch¨atzte und gemessene Werte . . . 72
5.6 Trefferrate . . . 73
5.7 Modellentscheidung . . . 74
5.8 Trefferrate . . . 77
5.9 Modellentscheidung . . . 78
viii ABBILDUNGSVERZEICHNIS
Tabellenverzeichnis
5.1 Modellqualit¨at ausgew¨ahlter Entscheidungsmodelle . . . 75 5.2 Performance-Steigerung des Modells verglichen mit der Einzelausf¨uhrung
von Algorithmen . . . 75 5.3 Modellqualit¨at ausgew¨ahlter Entscheidungsmodelle . . . 77 5.4 Performance-Steigerung des Modells verglichen mit der Einzelausf¨uhrung
von Algorithmen . . . 78
x TABELLENVERZEICHNIS
Verzeichnis der Abk¨ urzungen
ACID Atomicity, Consistency, Isolation und Durability; Eigenschaften einer Transaktion
CPU Central-Processing-Unit
CUDA Compute-Unified-Device-Architecture DB Datenbank
DBMS Datenbankmanagementsystem
DBS Datenbanksystem, umfasst die konkrete Instanz einer Datenbank, die von einem Datenbankmanagementsystem verwaltet wird
GPU Graphics-Processing-Units
GPGPU General-Purpose-Computation-on-Graphics-Processing-Units MAPE Monitor-Analyse-Plan-Execute
RAM Random Access Memory
SIMD Single-Instruction, Multiple-Data SIMT Single-Instruction, Multiple-Thread SM Streaming-Multiprocessors
Spore Spares POlynomial REgression TXN Transaktion
VRAM Video-RAM
xii
Abk¨ urzungen im Modell
Abk¨ urzungen f¨ ur Modellparameter
A Algorithmus D Datenmenge D
ITL initiale Trainingsl¨ange
MMPA minimale Messpaar Anzahl MP Messpaar
MTL maximale Trainingsl¨ange (in Anzahl der ben¨otigten Messpaare) NBR Neuberechnungsrate
O Operation O
PAG prozentuale Ausreißergrenze
RPG Ringpuffergr¨oße (Anzahl der Messpaare im Ringpuffer)
W Workload, ist ein Tupel W = (DS, O), wobei DS =D1, D2,· · · , Dn eine Menge von zu verarbeitende Datenmengen Di darstellt und O die auszuf¨uhrende Operation ist.
Abk¨ urzungen innerhalb des Modells
APO Algorithmenpool der Operation O, beinhaltet alle Algorithmen, die f¨ur die Ausf¨uhrung der Operation zur Verf¨ugung stehen
DP SF durchschnittlicher prozentualer Sch¨atzfehler EMi, EMj Entscheidungsmodelle
ETi in Schritt i (f¨ur die Datenmenge Di aus der Workload W) gesch¨atzte Zeit
FA(D) Approximationsfunktion f¨ur Algorithmus A in Abh¨angigkeit von der Datenmenge D
LA Lernverfahren f¨ur Algorithmus A M P LA Messpaarliste f¨ur Algorithmus A M Q Modellqualit¨at
M Ti in Schritt i (f¨ur die Datenmenge Di aus der Workload W) gemessene Zeit N Anzahl der Modell Iterationen
P SFi prozentualer Sch¨atzfehler in Schritt i
RE Anzahl der richtigen Entscheidungen (f¨ur den kostenminimalen Algorithmus) TA(D) Ausf¨uhrungszeit des Algorithmus A f¨ur die Datenmenge D
Test(A, D) vom Modell berechneter Sch¨atzwert, ¨aquivalent zu FA(D)
TEM(W) die vom Entscheidungsmodell (EM) hervorgerufene totale Ausf¨uhrungszeit f¨ur die Abarbeitung der Workload W
TEM−X(W) durch den Einsatz des Modells EM-X resultierende Zeit f¨ur die Abarbeitung der Workload W.
TN A(W) Zeit, die insgesamt f¨ur alle Neuberechnungen der Approximationsfunktionen (NA) ben¨otigt wurde
TOverhead(EM, W) Zeit, die durch das Modell zus¨atzlich verbraucht wurde
Treal(D, A) ist die gemessene Ausf¨uhrungszeit, die der Algorithmus A f¨ur die Verar- beitung der Datenmenge D ben¨otigt hat
TSW B(W) Zeit, die insgesamt f¨ur alle Sch¨atzwertberechnungen (SWB) ben¨otigt wurde T E Anzahl der insgesamt getroffenen Entscheidungen
T R Trefferrate
T RM Z Totale Reale Modellzeit, beinhaltet Modell-Overhead
xiv
Zusammenfassung Modellqualit¨ atsmaße
P SFi = |ETi−M Ti| M Ti
DP SF =
N
P
i=1
P SFi
N T R = RE
T E
TOverhead(EM, W) =TSW B(W) +TN A(W) TEM(W) = X
D∈DS
Treal(D, w¨ahleAlgorithmus(D, O)) +TOverhead(EM, W) P GS(EM −X →EM −Y, W) = TEM−X(W)−TEM−Y(W)
TEM−X(W)
Betrachtete Entscheidungsmodelle:
EM −Ideal ideales Entscheidungsmodell, entscheidet sich immer f¨ur den schnellsten Algorithmus
EM −Real das in dieser Arbeit konstruierte Entscheidungsmodell
EM −M ergesort Entscheidungsmodell, dass immer Mergesort f¨ur die Ausf¨uhrung einer Sortieroperation ausw¨ahlt
EM −Radixsort Entscheidungsmodell, dass immer Radixsort f¨ur die Ausf¨uhrung einer Sortieroperation ausw¨ahlt
EM −Quicksort Entscheidungsmodell, dass immer Quicksort f¨ur die Ausf¨uhrung einer Sortieroperation ausw¨ahlt
EM −W orst−Case Worst-Case-Entscheidungsmodell, entscheidet sich immer f¨ur den langsamsten Algorithmus
Abstract
Ein aktueller Datenbankforschungstrend fokussiert die Abarbeitung von Datenbankop- erationen auf Grafikkarten (GPU), um eine schnellere Anfrageverarbeitung zu erre- ichen. Die GPU-Algorithmen sind aber nicht in allen F¨allen schneller als ihre CPU- Gegenst¨ucke und umgekehrt. Dies liegt vor allem am Overhead des Datentransfers zwis- chen dem Hauptspeicher der CPU und dem Speicher der Grafikkarte. Um eine optimale Geschwindigkeitssteigerung erreichen zu k¨onnen, ist es erforderlich, f¨ur eine Operation den schnellsten Algorithmus auszuw¨ahlen. In Abh¨angigkeit davon, ob ein Algorithmus f¨ur die CPU oder die GPU geschrieben wurde, wird die zugeh¨orige Operation auf der CPU oder GPU ausgef¨uhrt. Auf diese Weise werden Operationen optimal auf vorhandene Recheneinheiten verteilt.
F¨ur die Verteilung von Operationen wird ein Entscheidungsmodell ben¨otigt. Ein solches soll in dieser Arbeit entwickelt werden. Es abstrahiert von hardwarenahen Pa- rametern und nutzt statistische Verfahren, wie die Methode der kleinsten Quadrate und Spline-Interpolation, zur Sch¨atzung von Ausf¨uhrungszeiten auf Basis von zuvor gemesse- nen Ausf¨uhrungszeiten. Der Einsatz statistischer Verfahren und das kontinuierliche Sam- meln von Messdaten erm¨oglicht zus¨atzlich eine dynamische Anpassung an neue Lastsit- uationen, da ver¨anderte Messwerte zu ver¨anderten Sch¨atzungen f¨uhren.
In der pr¨asentierten Fallstudie wurden CPU- und GPU-Algorithmen zum Sortieren verwendet. Das Ergebnis war eine minimale Performance-Steigerung von ca. 7%. Die erreichte Modellqualit¨at liegt bei 99%. Der relative Sch¨atzfehler liegt bei Einsatz des kleinste Quadrate Verfahrens unter 20% und bei Verwendung von Splines unter 5%.
2
Kapitel 1 Einleitung
In diesem Kapitel wird eine kurze Einleitung in die Thematik dieser Arbeit gegeben.
Zun¨achst wird der Hintergrund vorgestellt und die Arbeit motiviert. Anschließend folgt die Vorstellung der f¨ur die Arbeit gesetzten Ziele und der genutzten Kapitelstruktur. Ein kurzer ¨Uberblick ¨uber den Forschungsstand und eine kurze Beschreibung des Projektes schließen das Kapitel.
1.1 Hintergrund
Ein aktueller Forschungstrend fokussiert die Beschleunigung von Daten- banken, durch die Auslagerung von Datenbankoperationen auf Grafikkarten [HLY+09],[WWN+10],[PMK11],[GLW+04]. Allerdings sind weder die CPU-, noch die GPU-Algorithmen bei der Ausf¨uhrung einer Operation immer schneller als die jeweils anderen.
Es w¨are performanter, wenn immer der schnellste Algorithmus zur Ausf¨uhrung aus- gew¨ahlt werden w¨urde, um eine bestm¨ogliche Performance gew¨ahrleisten zu k¨onnen.
Ein weiteres Problem ist die antwortzeitminimale Algorithmenauswahl (und damit ver- bundene Verteilung von Operationen auf CPU und GPU) ohne Kenntnis der konkreten Hardware durchzuf¨uhren, denn die Verwaltung der Parameter eines analytischen Kosten- modells w¨urde in der Praxis einen hohen Aufwand bedeuten und w¨are somit kostenin- tensiv.
1.2 Motivation
Darum wird ein Entscheidungsmodell ben¨otigt, dass Datenbankoperationen zur Laufzeit auf CPU und GPU verteilt und sich an neue Lastsituationen anpassen kann. Diese Arbeit hat das Ziel, ein solches Modell zu erstellen.
Von hardwarenahen Parametern wird abstrahiert, indem das Ausf¨uhrungsverhalten von Algorithmen, die f¨ur die Ausf¨uhrung einer Operation genutzt werden, gelernt wird.
Dies soll durch den Einsatz von statistischen Verfahren erfolgen, die f¨ur jeden Algorith- mus eine Sch¨atzfunktion trainieren, die dann f¨ur die Sch¨atzung der Ausf¨uhrungszeiten der f¨ur eine Operation verf¨ugbaren Algorithmen verwendet wird. Der Algorithmus mit der niedrigsten gesch¨atzten Ausf¨uhrungszeit wird zur Ausf¨uhrung gebracht. Auf diese
4 1.3. Ziele
Weise wird eine antwortzeitminimale Verteilung von Operationen auf CPU und GPU1 realisiert. Durch den Einsatz statistischer Verfahren und das kontinuierliche Sammeln von Messpaaren f¨ur die zur Ausf¨uhrung gebrachten Algorithmen ist eine dynamische Lastanpassung zur Laufzeit m¨oglich.
1.3 Ziele
Das Ziel dieser Arbeit ist die Beschleunigung der Anfrageverabeitung in Datenbankman- agementsystemen (DBMS) durch eine antwortzeitminimale Verteilung von Datenbank- operationen auf unterschiedliche Recheneinheiten (CPU/GPU). Ein wesentliche An- forderung ist, dass das zu erstellende Modell ohne hardwarenahe Parameter auskommt und sich prinzipiell an ver¨anderte Lastsituationen anpassen kann. Auf diese Weise soll auch bei schwankender Last auf CPU und GPU ein maximaler Performancenutzen erreicht werden.
Weitere Ziele dieser Arbeit sind deshalb die Beantwortung folgender Fragen:
1. Wie kann eine antwortzeitminimale Verteilung von Datenbankoperationen ohne Kenntnis der zugrunde liegenden Hardware (CPU,GPU) umgesetzt werden?
2. Hat diese Vorgehensweise einen Nutzen und wenn ja, wie hoch ist er im Vergleich zum Idealfall?
3. Wie kann dabei eine Anpassung an neue Lastsituationen erfolgen?
4. Welches der betrachteten statistische Verfahren erzeugt ein (nahezu) optimales Modell?
Die Ziele dieser Arbeit werden zum einen durch qualitative Diskussionen und zum anderen durch Experimente erreicht.
1.4 Struktur der Arbeit
Die weitere Arbeit ist wie folgt aufgebaut:
Kapitel 2 In Kapitel 2 wird eine Einf¨uhrung in den f¨ur diese Arbeit relevanten The- menbereich gegeben.
Kapitel 3 In Kapitel 3 wird das Entscheidungsmodell vorgestellt und dessen Be- standteile aufgeschl¨usselt und diskutiert.
Kapitel 4 In Kapitel 4 werden ¨Uberlegungen zur Adressierung aktueller Schw¨achen des Modells pr¨asentiert, die nicht mit Experimenten validiert werden.
Kapitel 5 In Kapitel 5 folgt die Beschreibung und Auswertung der durchgef¨uhrten Ex- perimente.
Kapitel 6 In Kapitel 6 wird die Arbeit zusammengefasst und ein Ausblick gegeben.
1Nachfolgend wird das auch einfach als Scheduling bezeichnet.
1.5 Derzeitiger Stand der Technik
In aktuellen Publikationen wird die Auswahl von Algorithmen vor der Laufzeit durchgef¨uhrt [KDY10]. Es gibt keinen Ansatz, der geeignet w¨are, Operationen dynamisch auf CPU und GPU zu verteilen. Genauere Informationen zum relevanten Forschungs- stand werden in Abschnitt 2.8.1 auf Seite 26 gegeben.
Offene Probleme: F¨ur die GPU wurden einige analytische Modelle erstellt, die sich aber nicht an neue Lastsituationen anpassen k¨onnen. Außerdem erfordern sie die Kennt- nis von hardwarenahen Parametern wie z.B. Taktrate und Anzahl der verf¨ugen Prozes- soren. In der Praxis w¨urde dies die Wartung erschweren, weswegen das Lernen des Ausf¨uhrungsverhaltens eines Algorithmus w¨unschenswert w¨are. Dies wird von dem in dieser Arbeit entwickelten Modell umgesetzt.
Unterschiede zu bisherigen Ans¨atzen: Ein weiterer Unterschied ist, dass das Modell die Ausf¨uhrungszeit von Operationen sch¨atzt, und nicht f¨ur Anfragen. Dadurch k¨onnen die zu einer Anfrage geh¨orenden Operationen auf die jeweils geeignetste Rech- eneinheit verteilt werden, was bei einem Anfrage basiertem Ansatz nicht m¨oglich w¨are.
Wie bereits erw¨ahnt wurde, verschenken bisherige Ans¨atze m¨ogliche Zeiteinsparungen bei der Anfragebearbeitung dadurch, dass sie statisch einen Algorithmus w¨ahlen, der ent- weder f¨ur die CPU oder die GPU geschrieben wurde. Das zu erstellende Modell hingegen w¨ahlt dynamisch zur Laufzeit einen Algorithmus aus und kann so mehr Ausf¨uhrungszeit sparen.
1.6 Allgemeine Beschreibung des Projektes
In diesem Abschnitt werden allgemeine Informationen zum Projekt gegeben.
Die Arbeit wurde bei der Arbeitsgruppe Datenbanken des Instituts f¨ur Technische und Betriebliche Informationssysteme der Universit¨at Magdeburg verfasst. Von den darin gewonnenen Ergebnissen k¨onnen alle Datenbankmanagementsysteme profitieren, die auf einem hybriden CPU/GPU System laufen. Anfragen k¨onnen in k¨urzerer Zeit verarbeitet werden und somit den Nutzern eines DBMS einen besseren Service bieten. Von dem Ansatz k¨onnen besonders Antwortzeit sensitive Systeme wie z.B. Data-Warehouses profi- tieren.
6 1.6. Allgemeine Beschreibung des Projektes
Kapitel 2 Grundlagen
In diesem Kapitel werden die Grundlagen f¨ur das Verst¨andnis des sp¨ater zu entwickelnden Konzeptes gelegt. Zun¨achst erfolgt eine Einf¨uhrung in allgemeine Grundlagen von Daten- banken und deren Tuning. Daf¨ur werden grundlegende Begriffe definiert, der Aufbau eines DBMS beschrieben und darauf folgend der Optimierungsprozess von Anfragen n¨aher betrachtet. Anschließend folgt eine Einf¨uhrung ¨uber Datenbank-Tuning und darauf aufbauend ¨uber Self-Tuning. Zu den speziellen Grundlagen, die f¨ur das Verst¨andnis er- forderlich sind, geh¨ort eine kurze Erl¨auterung der sp¨ater verwendeten Interpolationsver- fahren, eine n¨ahere Betrachtung von GPUs und deren Architektur und eine kurze Vorstel- lung der genutzten Sortierverfahren. Anschließend folgen Ausf¨uhrungen zum aktuellen Forschungsstand. Das Kapitel schließt mit einer Zusammenfassung.
2.1 Grundlegende Begriffe
In diesem Abschnitt werden grundlegende Begriffe erkl¨art, die f¨ur das Verst¨andnis dieser Arbeit erforderlich sind. Sofern nicht anders gekennzeichnet, sind alle Inhalte dieses Abschnitts aus [SSH10] entnommen worden.
• ”Ein Algorithmus ist eine pr¨azise (d.h. in einer festgelegten Sprache abge- fasste) endliche Beschreibung eines allgemeinen Verfahrens unter Verwendung ausf¨uhrbarer elementarer (Verarbeitungs-) Schritte.” [SS06]
• Eine Datenbank (DB) ist ein strukturierter, von einem DBMS verwalteter Datenbestand.
• Ein Datenbank Management System (DBMS) ist die Software, die f¨ur die Ver- waltung von Datenbanken verantwortlich ist.
• Ein Datenbanksystem (DBS) besteht aus einer konkreten Instanz einer Daten- bank, die von einemDBMS verwaltet wird.
• Eine Operation, die auf einer Datenbank ausgef¨uhrt wird, wird Datenbankopera- tion genannt [SHS05].
• Eine Folge von Datenbankoperationen, die aus einer oder mehreren Basisrelationen eine Ergebnisrelation berechnet, wird als Anfrage bezeichnet.
8 2.1. Grundlegende Begriffe
• Eine Transaktion (TXN) ist eine Folge von Operationen, die die Datenbank von einem konsistenten Zustand in einen neuen konsistenten Zustand ¨uberf¨uhrt, wobei das ACID-Prinzip gilt [SHS05]:
– Atomarit¨at (Atomicity): Eine Transaktion wird entweder ganz oder gar nicht ausgef¨uhrt. Sie darf keine (inkonsistenten) Zwischenzust¨ande hinterlassen, selbst beim Auftreten von Fehlern.
– Konsistenz (Consistency): Der von einer Transaktion hinterlassende Daten- bankzustand muss den Integrit¨atsbedingungen gen¨ugen.
– Isolation (Isolation): Ein Nutzer sollte den Eindruck haben, als w¨urde er allein auf der Datenbank arbeiten, selbst wenn in Wirklichkeit mehrere Nutzer auf ihr arbeiten. Das Ergebnis einer Transaktion darf sich somit nicht ¨andern, nur weil sie parallel zu anderen Transaktionen ausgef¨uhrt wird.
– Persistenz (Durability): Am Ende einer Transaktion m¨ussen alle vorgenomme- nen ¨Anderungen dauerhaft in der Datenbank gespeichert sein.
• Datenbank Tuning umfasst alle Aktivit¨aten, die ausgef¨uhrt werden, um An- forderungen bez¨uglich der Performance eines Datenbanksystems zu erf¨ullen [Sha92].
• Datenbank Self-Tuning beschreibt die F¨ahigkeit eines DBMS seine eigene Funk- tionalit¨at, Parameter und interne Strukturen f¨ur ein gegebenes Datenbanksystem zu optimieren, um die Performance zu optimieren und den gestellten Anforderun- gen zu gen¨ugen [CN07].
• Die Central Processing Unit (CPU) ist die zentrale Komponente eines Rechnersys- tems. Sie f¨uhrt Programme aus, indem sie deren Maschinenanweisungen nacheinan- der abarbeitet [Gla10].
• Graphics Processing Units (GPU), zu deutsch Grafikprozessoren, sind Vielkern- Prozessoren, die sehr große Rechenkapazit¨at besitzen und einen hohen Datendurch- satz erreichen k¨onnen. Fr¨uher wurden sie speziell f¨ur den Einsatz in der Computer- grafik entworfen, heute sind es parallele Mehrzweck-Prozessoren mit Unterst¨utzung von Programmierschnittstellen f¨ur etablierten Hochsprachen wie C [GPG11].
• GPGPU steht f¨ur General-Purpose-Computation-on-Graphics-Processing-Units, zu deutsch Mehrzweckberechnungen auf Grafikprozessoren. Ein alternativer Begriff ist GPU-Computing [GPG11]. Dabei wird die GPU von ihrem traditionellem An- wendungsbereich, dem Rendering, auf ein weiteres Anwendungsspektrum erweitert, um allgemeine Probleme in der Informatik zu l¨osen.
• Scheduling ist ein Entscheidungsprozess, in dem die Allokation von Ressourcen zu Aufgaben ¨uber einen bestimmten Zeitraum gesteuert wird. Das Ziel ist die Optimierung eines Systems anhand einem oder mehreren Optimierungskriterien [Pin08]. Im Rahmen dieser Arbeit beschr¨ankt sich das Scheduling auf die Zuweisung von Datenbankoperationen (Tasks) auf Berechnungseinheiten wie CPU und GPU (Ressourcen) f¨ur die Dauer einer Operation mit dem Ziel die Systemeigenschaften anhand eines Optimierungsziels zu verbessern.
2.2 Grundlegende Architektur von Datenbanken
In diesem Abschnitt wird die Architektur eines DBMS kurz vorgestellt. Die einzel- nen Komponenten werden genannt und deren Funktionsweise erkl¨art. Falls nicht an- ders angegeben, wurden die Inhalte dieses Abschnittes aus [Vos08] entnommen. Die beschriebene Architektur und deren Komponenten wird in Abbildung 2.1 dargestellt.
Input/Output Prozessor
Parser Autorisierungskontrolle Precompiler
Integritäts-
prüfung Update-
Prozessor Query-
Prozessor Optimierer
Zugriffsplanerstellung Code-Erzeugung
Transaktionsmanager
Recovery-Manager Scheduler
Data-Manager Puffer-Manager
Datenbank Log
Data-Dictionary
Ebene 1 Der Benutzer- sprache
Ebene 2 Der Anfrage- bearbeitung
Ebene 3
Der Zugriffstrukturen und Code-Erzeugung
Ebene 4
Der Synchronisation paralleler Zugriffe
Ebene 5 Der Speicher- verwaltung
Abbildung 2.1: DBMS Architektur in Anlehnung an [Vos08]
Der Benutzer kommuniziert mit einem System ¨uber einenInput-/Output Prozes- sor, der Anfragen des Nutzers entgegen nimmt und f¨ur die Anfragebearbeitung notwendi- ge Aktionen im System veranlasst. Falls die Anfrage erfolgreich ausgef¨uhrt werden kon- nte, wird das Ergebnis der Anfrage zur¨uckgegeben, andernfalls wird mit einer Fehlermel- dung abgebrochen.
Die vomInput/Output Prozessorentgegengenommene Anfrage wird demParser
¨ubergeben, der die syntaktische Richtigkeit der Anfrage ¨uberpr¨uft. Dabei wird getestet, ob das Kommando entsprechend eines vorgegebenen Schemas aufgebaut ist (Semantik) und die in der Anfrage verwendeten Schl¨usselw¨orter zu der Anfragesprache geh¨oren (Syn-
10 2.2. Grundlegende Architektur von Datenbanken
tax). Bereits in dieser Komponente werden Informationen aus dem Data-Dictionary ben¨otigt (z.B. um zu pr¨ufen ob es die in einer Anfrage angegebenen Tabellen ¨uberhaupt gibt), deshalb muss der Parser mit Data-Dictionary kommunizieren k¨onnen. Im Fall von eingebetteten Kommandos ist unter Umst¨anden die Nutzung desPrecompilerser- forderlich. Unabh¨angig vom Anfragetyp ist eine Autorisierungskontrolle notwendig, die sicherstellt, dass der Nutzer nur ihm erlaubte Aktionen imDBMSdurchf¨uhren darf und nur die f¨ur ihn freigegebenen Daten lesen oder ver¨andern kann.
Das Ergebnis dieser ersten Phase der Anfrageverarbeitung ist eine interne Darstel- lung der vom Nutzer eingegebenen Anfrage. Bei relationalen DBMS w¨are dies z.B. ein Anfragebaum, dessen Bl¨atter Relationen und deren innere Knoten die auszuf¨uhrenden Operationen sind.
Das DBMS kann abh¨angig davon, ob eine Anfrage nur Daten liest oder auch Daten schreibt (aktualisiert), unterschiedliche Aktionen ausf¨uhren. Bei Aktualisierungen ist die Einhaltung der Integrit¨atsbedingungen notwendig, um die semantische Korrektheit oder Konsistenz einer Datenbank sicher zu stellen. Diese Spiegeln in der Außenwelt vorherrschende Eigenschaften und Zusammenh¨ange wieder, wie z.B. dass das Alter eines Menschen nicht negativ sein darf und das keine lebende Person in der Zukunft geboren werden kann. Diese Integrit¨atsbedingungen werden bei der Definition des konzeptuellen Schemas festgelegt und zur Laufzeit vomDBMSselbstst¨andig ¨uberwacht. Die bisherige interne Repr¨asentation der Nutzeranfrage wird in diesem Fall dem Update-Prozessor unter Verwendung der Integrit¨atspr¨ufung ¨ubergeben.
Falls eine Anfrage nur Leseoperationen ausf¨uhrt, so ist keine Integrit¨atspr¨ufung erforderlich, da sie keine Daten ver¨andern wird und somit auch keine In- tegrit¨atsverletzungen verursachen kann. Falls eine Anfrage ¨uber einem externem Schema gestellt worden ist, so muss der Query-Prozessor sie so umwandeln, dass sie ¨uber dem konzeptuellen Schema gestellt werden kann. Hierf¨ur ist es beispielsweise n¨otig, im externen Schema definierte Abk¨urzungen mit deren Definition zu ersetzen, was als View- Aufl¨osung bezeichnet wird.
Nutzer werden nicht notwendigerweise Anfragen stellen, die vom DBMS effizient verarbeitet werden k¨onnen. Deswegen versucht dasDBMS Anfragepl¨ane zu verbessern.
F¨ur diese Aufgabe ist der Optimierer zust¨andig, der aus der bisherigen Zwischenform der Nutzeranfrage einen semantisch ¨aquivalenten1 Anfrageplan erstellt, der effizienter ausf¨uhrbar ist.
Im n¨achsten Schritt werden die vomDBMSverf¨ugbaren Zugriffsstrukturen ermittelt (z.B. Indexe), ein m¨oglichst effizienter Zugriffspfad ausgew¨ahlt und ein ausf¨uhrbarer Plan mithilfe des Code-Erzeugers erstellt.
Meistens arbeiten eine Vielzahl von Nutzern an einem Datenbanksystem. Aus diesem Grund muss dass DBMS gleichzeitige Zugriffe auf die Datenbank synchronisieren.
Im laufendem Betrieb werden alle aktiven Transaktionen verzahnt miteinander aus- gef¨uhrt, um einen hohen Durchsatz zu erreichen. Damit der gleichzeitige Zugriff auf gemeinsame Daten keine Inkonsistenzen verursacht, m¨ussen die Lese- und Schreibzu- griffe von Transaktionen synchronisiert werden. Aus diesem Grund besitzt ein DBMS einen Transaktionsmanager, der das DBS einem Nutzer so erscheinen l¨asst, als w¨urde er alleine auf der Datenbank arbeiten. Die Synchronisation selbst ¨ubernimmt der
1Das Ergebnis darf sich unabh¨angig von den Daten durch die Transformation nicht ver¨andern.
Scheduler, der damit die sogenannte Concurrency Control (Gleichzeitigkeitskontrolle) umsetzt.
Eine Transaktion wird entweder ganz oder gar nicht ausgef¨uhrt. Sollte eine Transak- tion abgebrochen werden, d¨urfen die von der Transaktion vorgenommenen ¨Anderungen nicht in der Datenbank verbleiben. Sollte der Transaktions-Manager feststellen, dass eine Transaktion abgebrochen wurde, wird sie dem Recovery-Manager ¨ubergeben.
Dieser muss nun die ¨Anderungen der abgebrochenen Transaktion r¨uckg¨angig machen.
Daf¨ur nutzt er den Log desDBMS, indem unter anderem alle ¨Anderungen verzeichnet werden. Der Recovery-Manager hat außerdem die Aufgabe, das Datenbanksystem nach einem Fehlerfall (Festplattencrash, Betriebssystem oder DBMS abgest¨urzt) wieder an- laufen zu lassen. Dazu ist es n¨otig, die Datenbank wieder in einen konsistenten Zustand zu versetzen. Alle erfolgreich beendeten (comitteten) Transaktionen, deren ¨Anderungen durch den Absturz verloren gegangen sind, m¨ussen erneut ausgef¨uhrt werden, alle an- deren nicht.
Die Speicherverwaltung bildet den untersten Bereich des DBMS und umfasst den Puffer-Manager und den Data-Manager. Der Puffer-Manager dient der Verwal- tung des vom DBMS genutzten Hauptspeichers. Der Data-Manager verwaltet die vom DBMSgenutzten Betriebsmittel und f¨uhrt unter der Aufsicht des Transaktionsmanagers alle physischen Zugriffe auf die Datenbank aus.
Das bereits erw¨ahnte Data-Dictionary stellt Informationen bereit, die von vielen Komponenten desDBMS ben¨otigt werden.
Ein DBMS kann in f¨unf Ebenen eingeteilt werden, denen wiederum die bereits beschriebenen Komponenten zugeordnet werden k¨onnen.
1. Ebene der Benutzersprache: I/O Prozessor, Parser, Precompiler, Au- torisierungskontrolle
2. Ebene der Anfrageverarbeitung: Integrit¨atspr¨ufung, Update- sowie Query Prozessor, Optimierer
3. Ebene der Zugriffsstrukturen: Zugriffsplanerstellung, Code-Erzeugung
4. Ebene der Synchronisation: paralleler Zugriffe, Transaktionsverwaltung, Sche- duler, Recovery Manager
5. Ebene der Speicherverwaltung: Puffer- sowie Data-Manager
Im n¨achsten Abschnitt wird die Funktionsweise des Optimierers n¨aher betrachtet.
2.3 Anfrageoptimierung
Die Optimierung von Anfragen ist von zentraler Bedeutung in einem DBMS, da sie maßgeblich die Performance des Systems beeinflusst. Aus diesem Grund folgt nun eine kurze Einf¨uhrung in die Anfrageoptimierung. Zu Beginn wird auf die einzelnen Phasen eingegangen, um anschließend speziell die physische Optimierung n¨aher zu beleuchten.
Der Abschnitt schließt mit einer kurzen Zusammenfassung.
12 2.3. Anfrageoptimierung
2.3.1 Phasen der Anfrageoptimierung
Sofern nicht anders gekennzeichnet, sind alle Inhalte dieses Abschnitts aus [SSH10] ent- nommen worden.
1. Ubersetzung und Sichtexpansion:¨ Aus einer SQL Anfrage wird zun¨achst ein initialer Anfrageplan erzeugt. Dabei werden bei verschachtelten SQL Anfragen die Unteranfragen aufgel¨ost, um die sp¨ater folgende Optimierung zu vereinfachen.
Außerdem werden arithmetische Ausdr¨ucke vereinfacht. Bei Zugriffen auf Sichten m¨ussen diese aufgel¨ost werden, indem sie durch ihre Sichtdefinition ersetzt werden.
Dieser Vorgang wird als Sichtexpansion bezeichnet.
2. Logische und algebraische Optimierung: Bei dieser Optimierung wird der Anfrageplan des vorherigen Schritts anhand algebraischer Regeln seman- tisch ¨aquivalent umgeformt, um einen verbesserten Anfrageplan zu erhalten.
Ublicherweise werden Selektionsoperationen im Anfrageplan in Richtung der Basis¨ Relationen verschoben, um Zwischenergebnisse m¨oglichst klein zu halten.
3. Physische oder interne Optimierung: Bei dieser Optimierung werden die ab- strakten Operationen im Anfrageplan durch Algorithmen ersetzt, die diese Opera- tionen ausf¨uhren werden. Weiterhin wird die physische Speicherung der Daten und die dabei eingesetzten Datenstrukturen mit ber¨ucksichtigt. Auf diese Weise entste- hen gew¨ohnlich mehrere semantisch ¨aquivalente Anfragepl¨ane. Aus diesen kann auf Basis von Heuristiken in dieser Phase oder durch Einsatz eines Kostenmodells in der n¨achsten Phase ein Anfrageplan ausgew¨ahlt werden.
4. Kostenbasierte Auswahl: In dieser Phase werden zu den in der letzten Phase generierten Anfragepl¨anen die Kosten berechnet und der kostenminimale Anfrage- plan zur Ausf¨uhrung gebracht.2
5. Planparametrisierung: Diese Phase ist nur Teil des Optimierungsvorgangs, wenn vorkompilierte SQL Anweisungen zur Ausf¨uhrung gebracht werden sollen. In diesem Fall werden die vorherigen Optimierungsphasen ¨ubersprungen, da bereits ein optimierter Anfrageplan vorliegt. Dieser wurde mit Parametern versehen, in die die Werte aus der SQL Anfrage eingef¨ugt werden.
6. Code-Erzeugung: In der letzten Optimierungsphase wird der Zugriffsplan zu ausf¨uhrbaren Code kompiliert. Bei einigen Systemen werden Zugriffspl¨ane auch mit einem Interpreter ausgef¨uhrt.
2.3.2 Physische Optimierung
Die physische Optimierung hat das Ziel, einen optimierten logischen Anfrageplan in einen ausf¨uhrbaren Anfrageplan umzuformen. Dies wird dadurch erreicht, indem die logischen Operationen im logischen Anfrageplan mit konkreten Algorithmen ersetzt werden. Die Entscheidung, welche Operation durch welchen Algorithmus ersetzt werden muss, wird
2Bei dieser Entscheidung werden Parameter wie die Tabellengr¨oße und die Selektivit¨at von Attributen mit ber¨ucksichtigt.
durch den Einsatz eines Kostenmodells realisiert. Das Ziel ist die Ermittlung eines kosten- minimalen ausf¨uhrbaren Anfrageplans [SHS05].
Plangenerierung und Suchstrategien
Der Einsatz von Transformationsregeln, sowohl in der logischen als auch der physischen Optimierung, resultiert (normalerweise) in mehreren semantisch ¨aquivalenten Anfrage- pl¨anen. Das bedeutet, dass die Ausf¨uhrung von all diesen Pl¨anen auf jeweils identischen Datenbanken zu jeweils dem gleichen Ergebnis f¨uhren w¨urde. Allerdings sind die Kosten meistens unterschiedlich. Das Ziel ist, den kostenminimalen Anfrageplan zu ermitteln.
Auf diese Weise soll die Performance des DBSmaximiert werden [SHS05].
Das Problem kann dabei in zwei Teilprobleme zerlegt werden. Das Erste ist das Auf- spannen des Suchraums, der s¨amtliche semantisch ¨aquivalenten Anfragepl¨ane enth¨alt.
Daf¨ur m¨ussen zun¨achst alle m¨oglichen Pl¨ane erstellt werden.3Das zweite Problem ist den kostenminimalen Plan im Suchraum zu finden. Daf¨ur wird eine Suchstrategie ben¨otigt, die m¨oglichst schnell den optimalen oder fast optimalen Anfrageplan ausw¨ahlt. Das Auswahlkriterium stellen die Kosten eines Anfrageplans dar, die anhand eines Kosten- modells f¨ur jeden betrachteten Anfrageplan berechnet werden m¨ussen [SHS05].
Meistens werden beide Phasen parallel ausgef¨uhrt, d.h. w¨ahrend neue Anfragepl¨ane generiert werden, k¨onnen von schon bestehenden Pl¨anen die Kosten berechnet werden.
Die eben beschriebenen Zusammenh¨ange werden in Abbildung 2.2 zusammenfassend dargestellt. Eine ausf¨uhrliche Diskussion der hier angesprochenen Problematik ist in [SHS05] zu finden.
Anfrage
Aufspannen des Suchraums
Aufspannen des Suchraums Äquivalente Pläne
Transformationsregeln
Kostenmodell
''Optimaler'' Plan
Abbildung 2.2: Optimierungsproblem in Anlehnung an [SHS05]
3Dies wird in der Praxis aus Effizienzgr¨unden nicht gemacht. Vielmehr wird dort mit Heuristiken gearbeitet, die den Optimierungsraum m¨oglichst einschr¨anken sollen.
14 2.4. Datenbank-Tuning
Kostenmodelle
Ein Kostenmodell bildet die wichtigste Grundlage f¨ur die Auswahl eines Anfrageplans.
Es stellt ein Entscheidungskriterium bez¨uglich eines Optimierungsziels zur Verf¨ugung.
Ublicherweise besteht ein Kostenmodell aus drei Teilen. Der Erste wird von Kostenfunk-¨ tionen gebildet, die die Ausf¨uhrungskosten von einzelnen Operationen und Anfragen berechnen. Statistiken stellen den zweiten Teil dar. Sie umfassen n¨ahere Informationen zu Tabellen wie Anzahl der Tupel, Wertebereiche und Werteverteilungen einzelner At- tribute usw. Formeln stellen den letzten Teil dar. Sie werden ben¨otigt, um mithilfe der Statistiken die Gr¨oßen von Zwischenergebnissen, die f¨ur die Kostenfunktionen ben¨otigt werden, zu sch¨atzen [SHS05].
Eine detailliertere Diskussion findet der interessierte Leser in [SHS05].
2.3.3 Zusammenfassung
In diesem Abschnitt wurde eine kurze Einf¨uhrung in die Anfrageoptimierung eines DBMS gegeben. Die einzelnen Phasen wurden kurz vorgestellt und die Phase der physischen Optimierung zus¨atzlich detaillierter beschrieben, da sie f¨ur den Kontext der sp¨ateren Inhalte dieser Arbeit wichtig ist. Im n¨achsten Abschnitt wird eine kurze Einf¨uhrung in das Tuning von Datenbanksystemen gegeben.
2.4 Datenbank-Tuning
In diesem Abschnitt wird eine kurze Einf¨uhrung in das Datenbank-Tuning gegeben.
Zun¨achst wird auf die Ziele des Datenbank-Tunings eingegangen, um anschließend einen Uberblick ¨¨ uber die optimierbaren Systembestandteile zu geben. Darauf folgend werden die Grundprinzipien vorgestellt und eine Zusammenfassung gegeben.
Falls nicht anders angeben, wurden die Inhalte dieses Abschnitts aus [Sha92] ent- nommen.
2.4.1 Zielstellung
Das grundlegende Ziel von Tuning ist die Verbesserung der Performance eines Systems.
Aber Performance ist ein weit gefasster Begriff, der vieles bedeuten kann, z.B. Qualit¨at der Verarbeitung und deren Ergebnisse, Verf¨ugbarkeit und Nutzbarkeit.
Datenbank-Tuning zielt meistens auf die Laufzeit-Performance ab, wobei es drei grundlegende Optimierungskriterien gibt. Dazu geh¨oren Durchsatz, Antwortzeit und Ressourcennutzung.
• Durchsatz:Hier ist das Ziel, die Anzahl der Anfragen oder Transaktionen, die in einem festen Zeitraum verarbeitet werden k¨onnen, zu maximieren.
• Antwortzeit: Die Antwortzeit ist die Zeit, die vom Startzeitpunkt einer Anfrage bis zu dem Zeitpunkt, an dem das vollst¨andige Ergebnisse vorliegt, vergeht. Diese Zeit soll minimiert werden.
• Ressourcennutzung:Optimiert die tempor¨ar (CPU, Hauptspeicher) und perma- nent (Festplattenplatz) verwendeten Ressourcen.
Diese Optimierungskriterien k¨onnen sich widersprechen, z.B. kann eine Optimierung der Antwortzeit den Durchsatz senken.
Der allgemeine Ansatz f¨ur eine Optimierung ist es, einige Beschr¨ankungen zu setzen (z.B. die maximale Auslastung einer Ressource), und die bestm¨ogliche L¨osung f¨ur ein spezifisches Optimierungsziel zu finden (z.B. f¨ur den Durchsatz).
2.4.2 Optimierbare Systembestandteile
Heutige Informationssysteme sind sehr komplex und bestehen aus einer Vielzahl von Komponenten. Im Wesentlichen k¨onnen vier Schichten genutzt werden, um eine f¨ur das Tuning geeignete Abstraktion zu erhalten. An erster Stelle steht eine Anwendung, die die Funktionalit¨at des DBMSverwendet. DasDBMSselbst nutzt die vom Betriebssystem bereitgestellte Schnittstelle, um Daten persistent auf der Festplatte zu speichern. Das Betriebssystem wiederum abstrahiert die zugrunde liegende Hardware und pr¨asentiert Anwendungen eine einheitliche Schnittstelle f¨ur die Kommunikation mit der Hardware.
Diese Zusammenh¨ange wurden zusammenfassend in Abbildung 2.3 dargestellt [Sha92].
Datenbank Management System (DBMS)
Anwendungen
Betriebssystem (BS)
Hardware
Abbildung 2.3: Relevante Systemkomponenten beim Datenbank Tuning in Anlehnung an [Sch11]
Um ein Datenbanksystem tunen zu k¨onnen, ist ein tief greifendes Wissen ¨uber alle Komponenten erforderlich. Weder Systementwickler und Datenbankadministratoren noch Datenbankexperten kennen alle Details aller Schichten. Dieses Problem wird als Datenbank-Tuning-Quadrilemma bezeichnet [Sch11], das zusammenfassend in Abbil- dung 2.4 zu sehen ist.
16 2.4. Datenbank-Tuning
Betriebssystem Hardware
Anwendungen DBMS
ein optimales Datenbanktuning erfordert umfassendes Wissen über
Abbildung 2.4: Datenbank-Tuning-Quandrilemma in Anlehnung an [Sch11]
2.4.3 Grundlegende Prinzipien
Die Kenntnis der grundlegenden Prinzipien des Datenbank-Tunings sind elementar f¨ur das Verst¨andnis der weiteren Diskussion, deshalb werden sie in diesem Abschnitt kurz pr¨asentiert. Zu den wichtigsten Prinzipien geh¨oren nach [Sha92]: denke Global, tune (repariere) Lokal; Partitionierung l¨ost Flaschenh¨alse auf; Startkosten sind hoch, Laufzeitkosten sind gering; und ¨uberlasse dem Server, was dem Server geb¨uhrt.
1. denke Global, tune Lokal:Die Idee dieses Prinzips ist, die richtigen Gr¨oßen zu messen und zu den richtigen Schlussfolgerungen zu kommen, um den Flaschenhals4, der das Performance-Problem verursacht, zu finden und zu beseitigen.
2. Partitionierung l¨ost Flaschenh¨alse auf: Falls ein Flaschenhals identifiziert wurde, sollte erst versucht werden, die zugeh¨orige Komponente zu beschleunigen (z.B. durch eine Anpassung der Konfiguration). Falls dies nicht zum Erfolg f¨uhrt, dann sollte die Last ¨uber mehr Ressourcen verteilt werden. Ein Beispiel ist z.B.
eine große Tabelle aufzuteilen und die entstandenen Partitionen auf verschiedene Festplatten zu verteilen, um den Ein-/Ausgabe Flaschenhals zu reduzieren. Eine weitere M¨oglichkeit einen Flaschenhals aufzul¨osen, ist einen Teil der Arbeitslast
¨uber einen gr¨oßeren Zeitraum zu verteilen. Ein Beispiel ist die Verschiebung des t¨aglichen Backups von der Mittagszeit in die Nacht.
3. Startup-Kosten sind hoch, Laufzeitkosten sind gering:Die meisten Kompo- nenten ben¨otigen einen signifikanten Anteil ihrer Ressourcen zum Starten. Dies ist z.B. f¨ur das Betriebssystem und Teile des DBMS der Fall. Also sollten alle Kom- ponenten m¨oglichst in Ausf¨uhrung bleiben und wenn m¨oglich nicht neu gestartet werden, um Ressourcen zu sparen.
4. ¨uberlasse dem Server, was dem Server geb¨uhrt: Dieses Prinzip sieht vor, dass die Last zwischen demDBMSund der Anwendung balanciert sein sollte. Der
4Teil eines Systems, dass die Gesamt-Performance begrenzt.
Server sollte die Aufgaben ¨ubernehmen, die er am besten l¨osen kann. Das gleiche gilt f¨ur die Anwendung.
Eine tiefgreifendere Diskussion findet der interessierte Leser in [Sha92].
2.4.4 Zusammenfassung
In diesem Abschnitt wurde eine grundlegende Einf¨uhrung in das Datenbank-Tuning gegeben, um die nachfolgende Diskussion ¨uber Self-Tuning in Datenbanksystemen vorzu- bereiten. Es wurden Ziele und Prinzipien erl¨autert und die optimierbaren Systembe- standteile vorgestellt.
2.5 Self-Tuning
In diesem Abschnitt wird eine Einf¨uhrung in das Self-Tuning von Datenbanksystemen gegeben. Zun¨achst wird das Konzept des Self-Tunings motiviert, um anschließend auf die zugrunde liegenden Prinzipien einzugehen. Der Abschnitt schließt mit einer Zusam- menfassung.
2.5.1 Motivation
Datenbanksysteme unterliegen st¨andigen Ver¨anderungen, sie m¨ussen immer gr¨oßere Datenmengen verwalten und werden dabei von immer mehr Benutzern und Anwen- dungen verwendet. Außerdem ¨andern sich die Anforderungen st¨andig, sie m¨ussen immer performanter und skalierbarer werden. Datenbankadministratoren ben¨otigen aber allein 50% ihrer Zeit daf¨ur, das System weiterhin im operativen Betrieb zu halten, um eine hohe Verf¨ugbarkeit zu gew¨ahrleisten. ¨Uber 80% der Kosten f¨ur das Tuning von Daten- banksystemen werden f¨ur Personal ben¨otigt. Außerdem kommen viele Datenbankadmin- istratoren mit den st¨andig steigenden Anforderungen mit dem Tuning kaum hinterher.
Aus diesem Gr¨unden w¨are es w¨unschenswert, wenn ein Datenbanksystem sich selbst op- timieren w¨urde, um auf diese Weise Kosten zu sparen und ein Maximum an Performance zu erreichen [Sat06],[CN07],[WHMZ94],[CW06].
Das Self-Tuning hat folgende Ziele [Sch11]:
1. Reduktion der Kosten f¨ur Wartung und Administration von Datenbanksystemen, 2. Automatisierung von so vielen Aufgaben wie m¨oglich,
3. Reduktion der Anzahl der Tuning-Parameter,
4. Erreichen der Performance Anforderungen mit weniger Aufwand.
Die grundlegende Idee ist, dass dasDBMSder beste Tuning-Experte ist, weil es sich selbst und seine Interaktionen mit Betriebssystem und Hardware am besten kennt. Die Analyse von fr¨uherer und aktueller Nutzung erlaubt in einem begrenztem Rahmen eine
18 2.5. Self-Tuning
Vorhersage der zuk¨unftigem Nutzung, f¨ur die die notwendigen ¨Anderungen durchgef¨uhrt werden5 [CW06].
2.5.2 Prinzipien
Zun¨achst werden die Grundprinzipien des Self-Tunings in diesem Abschnitt grob umris- sen, um in den folgenden Abschnitten detaillierter auf sie einzugehen.
Zu den Grundprinzipien des Self-Tunings geh¨oren :
Trade-off-Eliminierung ist ein wichtiges Ziel des Self-Tunings, n¨amlich das DBMS alle Entscheidungen treffen zu lassen, dies es selbst treffen kann [CW06].
Statisches vs. Dynamisches Tuning beschreibt zeitliche Aspekte, wann Entschei- dungen getroffen werden k¨onnen oder m¨ussen [CW06].
Self-Tuning Kreislauf zielt auf einen automatischen kontinuierlichen Entschei- dungsprozess zur Laufzeit ab [CW06].
Self-Tuning Overhead ber¨ucksichtigt schließlich die negativen Einfl¨usse des Self- Tunings auf ein System [Sch11].
Trade-off Eliminierung
Bei der Trade-off Eliminierung wird das Prinzip verfolgt, Tuning-Parameter zu entfernen oder schwer zu beherrschende Low-Level-Parameter mit einfacher zu verwaltenden High- Level-Parametern zu ersetzen. Die zwei wesentlichen Aspekte sind dabei erstens, die Automatisierung einfacher Entscheidungen und zweitens die Ersetzung von schwierigen Entscheidungen durch Einfache [CN07]. Beispiele f¨ur ein solches Vorgehen ist z.B. die Einstellung der Gr¨oße des Datenbankpuffers oder die Wahl der Seitenersetzungsstrategie [CW06],[Sat06].
Statisches vs. Dynamisches Tuning
Beim statischen Self-Tuning werden Aktivit¨aten einmal oder mehrmals durchgef¨uhrt, wobei sie manuell oder vom DBMS ausgel¨ost werden k¨onnen. Die Analyse und das Anpassen des Systems k¨onnen zu einem großen Grad vom DBMS entkoppelt werden.
Statisches Self-Tuning ist f¨ur die Justierung von sich langsam ver¨andernden oder sta- bilen Eigenschaften des Datenbanksystems geeignet [CW06],[Sat06]. Beispiele sind die Auswahl von Indexen f¨ur ein Attribut einer Tabelle oder die Bestimmung einer geeigneten Partitionierung einer Tabelle.
Das dynamische Self-Tuning f¨uhrt kontinuierlich Aktivit¨aten durch und ist tief in das DBMS integriert. Es nutzt Algorithmen, die eigenst¨andig Parameter anpassen und ist f¨ur das Tuning von Systemeigenschaften geeignet, die sich h¨aufig oder kontinuierlich
¨andern [CW06],[Sat06].
5DasDBMSkann z.B. nicht voraussehen, dass sich die Anzahl der Nutzer n¨achsten Monat verdop- pelt oder wie es sich auf anderer Hardware verhalten w¨urde.
Self-Tuning Kreislauf
Beim Self-Tuning kommt das Konzept des online Regelkreises zum Einsatz. Dabei beobachtet das System kontinuierlich bestimmte Performance-Metriken und justiert dy- namisch zur Laufzeit Tuning-Parameter, falls eine Performance-Metrik einen bestimmten Grenzwert ¨uberschreitet [CN07].
Der online Regelkreis wird in drei Phasen unterteilt, diese heißen Beobachtung, Vorhersage und Reaktion [CN07].
Die Beobachtungsphase ¨uberwacht Performance-Metriken und Workload- Parameter, die als Indikatoren f¨ur Performance-Probleme oder die Erkennung einer signifikanten Ver¨anderung der Last genutzt werden k¨onnen. Das entscheidende Prob- lem in dieser Phase ist die Wahl der zu betrachtenden Parameter. Durchsatz und die Antwortzeiten von Anfragen sind gute globale Indikatoren, geben aber keinen Hinweis auf die Ursache eines Performance-Problems. Deswegen ist die Betrachtung von mikroskopischen Daten notwendig, um einen adequaten Tuning-Parameter f¨ur die Justierung auszuw¨ahlen. Eine geeignete mikroskopische Metrik ist die L¨ange der Fest- plattenwarteschlangen [CN07].
Der Zweck der Vorhersagephase ist es die hypothetischen Anpassungen ver- schiedener Tuning-Parameter quantitativ abzusch¨atzen. Es wird also ein mathematisches Modell f¨ur die Funktion
Last-Parameter×Tuning-Parameter→Performance-Metrik
ben¨otigt, welche die Last und Tuning-Parameter eines Systems auf Performance- Metriken abbildet. Ein Tuning-Parameter sollte nur ver¨andert werden, wenn eine sig- nifikante Verbesserung vorhergesagt wird und zu erwarten ist, dass das System in einem stabilen Zustand bleibt. Die Vorhersage hilft auch den geeignetsten Tuning-Parameter auszuw¨ahlen, wenn es mehrere Kandidaten gibt. Die Stabilit¨atskontrolle ist wichtig, da es ansonsten passieren kann, das nur bestimmte Aspekte des Systems verbessert wer- den, w¨ahrend sich andere Teile des Systems verschlechtern. Ein Beispiel daf¨ur w¨are, alle Indexseiten im Hauptspeicher zu belassen, was die Geschwindigkeit von Index-Lookups erh¨ohen w¨urde, aber eventuell unzureichenden Speicher f¨ur Sortieroperationen oder Joins nach sich zieht [CN07].
Die letzte Phase des online Regelkreises ist derReaktionsschritt. Wenn der Vorher- sageschritt eine klare Empfehlung gibt, welcher Tuning-Parameter um welchen Wert angepasst werden sollte, dann muss theoretisch nur diese Anpassung vorgenommen wer- den. Aus praktischer Sicht ist es aber nicht einfach, ein System zu entwickeln, bei dem zur Laufzeit alle Tuning-Parameter ge¨andert werden k¨onnen, w¨ahrend das System seine Workload abarbeitet [CN07].
Ein DBMS das erfolgreich einen online Regelkreis in seinem Optimierer verwendet, ist DB2, dass einen Self-Tuning Optimierer namens LEO einsetzt [GLMK01].
Kephart et al. pr¨asentieren in [KC03] eine ¨Ubersicht ¨uber die Eigenschaften von selbst verwaltenden Systemen. Dabei wird ein System als eine Menge von autonomen Elementen abstrahiert, die miteinander kommunizieren k¨onnen. Jedes autonome Element hat seinen eigenen Regelkreis, der als MAPE (Monitor Analyse Plan Execute) bezeich- net wird.6 Im Mittelpunkt steht eine zu verwaltende Ressource, die durch einen Sensor
6In [CN07] besteht der Regelkreis aus drei Phasen und bei MAPE aus vier Phasen.
20 2.5. Self-Tuning
beobachtet wird. Die Informationen vom Sensor werden von einer Beobachtungkompo- nente entgegengenommen, die abh¨angig von den Eingabewerten die Analysekomponente benachrichtigt, die das System auf vorliegende Probleme analysiert. Anschließend wer- den ¨Anderungen am System geplant, um das Problem zu beheben. Dieser Plan wird dann ausgef¨uhrt, indem die Ausf¨uhrungskomponente den Effektor ansteuert. Eine Be- nachrichtigung anderer autonomer Elemente ist ebenfalls m¨oglich. In allen Phasen des Zyklus k¨onnen Informationen aus einer gemeinsamen Wissensbasis verwendet werden.
Die verwaltete Ressource, Sensor und Effektor stellen das zu verwaltende System dar und die ¨ubrigen Komponenten bilden den Autonomic Manager. Die erl¨auterten Zusam- menh¨ange wurden in Abbildung 2.5 visualisiert.
Beobachten (Monitor)
Analysieren Planen
Ausführen (Execute) Wissen
Autonomic Manager
Verwaltete Ressource
Sensor Effektor verwaltetes
System
Abbildung 2.5: IBMs Self-Tuning-Zyklus MAPE in Anlehnung an [KC03]
Self-Tuning Overhead
Self-Tuning verursacht immer einen zus¨atzlichen Aufwand, der immer mit betrachtet werden sollte. Beispiele hierf¨ur sind der Verbrauch zus¨atzlicher CPU-Zeit und die Bele- gung von mehr Festplattenplatz f¨ur das Ablegen von Informationen f¨ur den Entschei- dungsprozess. Der vom Self-Tuning gebrachte Nutzen muss gr¨oßer sein als die zus¨atzlich verursachten Kosten, sonst w¨urde das System besser ohne das Self-Tuning arbeiten [GLMK01]. Es kann aber passieren, dass das Self-Tuning eine Fehlfunktion verursacht oder zu schwer lokalisierbaren Problemen f¨uhrt. Aus diesem Grund muss es folgenden zwei Bedingungen gen¨ugen. Erstens muss Self-Tuning transparent arbeiten, d.h. seine Ak- tivit¨aten m¨ussen verfolgbar sein, um das aktuelle Systemverhalten erkl¨aren zu k¨onnen.
Zweitens muss es im Fehlerfall m¨oglich sein, das Self-Tuning abzuschalten und manuell die Tuning-Parameter einzustellen [LLH+06].
2.5.3 Zusammenfassung
In diesem Abschnitt wurde eine Einf¨uhrung in das Self-Tuning von Datenbanksystemen gegeben. Daf¨ur wurde die Thematik motiviert und die zugrunde liegenden Prinzipien erl¨autert. Im n¨achsten Abschnitt werden Interpolationsverfahren vorgestellt, die f¨ur das sp¨ater zu konstruierende Modell verwendet werden.
2.6 Interpolationsverfahren
In diesem Abschnitt wird eine kurze Einf¨uhrung von zwei Interpolationsverfahren gegeben, die sp¨ater genutzt werden, um die Ausf¨uhrungszeitkurven von Algorithmen zu sch¨atzen. Zun¨achst wird die Methode der kleinsten Quadrate vorgestellt, um an- schließend die Grundlagen der Interpolation mit kubischen Splines zu erl¨autern. Der Abschnitt schließt mit einer Zusammenfassung.
2.6.1 Methode der kleinsten Quadrate
Die Inhalte dieses Abschnitt wurden, sofern nicht anders gekennzeichnet, aus [BKKN03]
entnommen. Ein Polynom m-ten Grades wird als N¨aherungsfunktion verwendet, um eine gegebene Datenmenge
(x1, y1),(x2, y2),· · · ,(xm, ym) anzun¨ahern, wobeim >=n+ 1 sein muss.7
y=f(x) = a0+a1x+a2x2+· · ·+anxm
Die beste N¨aherungsfunktion hat den kleinsten quadratischen Fehler. Dies hat den Vorteil, dass große Fehler stark bestraft werden und kleine Fehler (< 1) durch die Quadrierung noch weniger ins Gewicht fallen. Dies soll f¨ur eine insgesamt gute Ap- proximation sorgen.
min=F(a0, a1,· · ·, an) =
n
X
i=1
[yi−f(xi)]2 =
n
X
i=1
[yi−(a0+a1x+a2x2+· · ·+anxm)]2 Die Unbekannten a0, a1,· · · , an sollen so bestimmt werden, dass der quadratische Fehler minimal wird. Ein Minimum wird dort erreicht, wo alle partiellen Ableitungen von F nach ai Null werden:
∂F
∂ai = 0 ∀i∈ {1,2,· · · , n}
F¨ur jede Ableitung entsteht eine Gleichung. Somit entsteht bei n Ableitungen ein Gleichungssystem mit n Unbekannten. Die L¨osung des Gleichungssystems ergibt den gesuchten L¨osungsvektor A = (a0, a1,· · · , an), mit dem das Interpolationspolynom aufgestellt werden kann.
7Wir brauchen mehr Datenpunkte als freie Parameter in der Gleichung.
22 2.6. Interpolationsverfahren
m
X
i=1
yi =a0
m
X
i=1
1 +a1
m
X
i=1
xi+a2
m
X
i=1
x2i +· · ·+an
m
X
i=1
xni (2.1)
m
X
i=1
xiyi =a0
m
X
i=1
xi+a1
m
X
i=1
x2i +a2
m
X
i=1
x3i +· · ·+an
m
X
i=1
xn+1i (2.2)
m
X
i=1
x2iyi =a0 m
X
i=1
x2i +a1 m
X
i=1
x3i +a2 m
X
i=1
x4i +· · ·+an m
X
i=1
xn+2i (2.3)
... (2.4)
m
X
i=1
xniyi =a0
m
X
i=1
xni +a1
m
X
i=1
xn+1i +a2
m
X
i=1
xn+2i +· · ·+an
m
X
i=1
xn+ni (2.5) Als Ausgleichs/Regressionspolynom m-ten Grades ergibt sich f¨ur den Datensatz (x1, y1),· · ·(xm, ym):
f(x) =a0+a1x+a2x2 +· · ·+anxm
Je nach genutztem Algorithmus und der Darstellung des Polynoms ist die Berech- nungskomplexit¨at des Verfahrens anders. Polynom-Interpolation ist nur f¨ur Aufgaben mit einem kleinerem Umfang geeignet. Die Approximationsg¨ute w¨achst nicht notwendi- gerweise mit steigendem Polynomgrad. Es kommt bei zu hohem Polynomgraden zu Os- zillationen, die die Sch¨atzgenauigkeit stark vermindern und das Verfahren unbrauchbar machen. Eine alternative Methode stellen die Splines dar, die zwar eine schlechtere Kon- vergenz als die Polynom-Interpolation aufweist, daf¨ur aber bessere Sch¨atzungen erreicht [SK09b].
2.6.2 Interpolation mit kubischen Splines
Kubische Spline-Interpolation ist eine schnelle, effiziente Methode f¨ur die Interpolation von Funktionen. Sie ist eine Alternative zur Polynom-Interpolation und funktioniert nach folgendem Prinzip: Das Interpolationsintervall wird in kleinere Teilintervalle un- terteilt. In jedem dieser Teilintervalle wird die zu interpolierende Funktion durch ein kubisches Polynom approximiert. Die Koeffizienten des Polynoms werden so gew¨ahlt, dass bestimmte Bedingungen erf¨ullt sind, die von der genutzten Interpolationsmethode abh¨angen. Allgemeine Anforderungen sind Stetigkeit der Funktion, und dass sie durch alle gegebenen Punkte verl¨auft. Es k¨onnten auch zus¨atzliche Anforderungen gestellt wer- den, z.B. die Linearit¨at der Funktion zwischen Knoten [ALG12b].
Nun folgt die formalere Darstellung. Sei ∆ = {a = x0 < x1 < · · · < xn = b}
eine Unterteilung des Intervalls [a,b]. Dann ist eine Splinefunktion eine aus n kubischen Polynomen st¨uckweise zusammengesetzte Funktion S∆. Dabei mussS∆ und seine ersten beiden Ableitungen an den Intervallunterteilungen x1, x2,· · · , xn−1 stetig sein [FH07].
Die formale Definition aus [FH07] lautet:
Definition 1 Unter einer zu ∆ geh¨origen kubischen Spline Funktion S∆ versteht man eine reelle Funktion S∆: [a,b] 7→ R mit den Eigenschaften
a) S∆ ∈C2 [a,b]: S∆ ist auf [a,b] zweimal stetig differenzierbar.
b) Auf jedem Teilintervall [xi, xi+1],i= 0,1,· · · , n−1, stimmt S∆ mit einem kubischen Polynom ¨uberein.
Allerdings ist S∆ noch nicht eindeutig bestimmt, weswegen noch zwei Zusatzbe- dingungen gefordert werden. Zwei m¨ogliche Zusatzforderungen sind, dass die zweite Ableitung der Splinefunktion an den Intervallgrenzen a und b Null wird und das an den gleichen Stellen die erste Ableitung der zu interpolierenden Funktion mit der ersten Ableitung der Splinefunktion ¨ubereinstimmt. Weitere Details sind in [FH07],[Far97] und [ALG12b] zu finden.
Die gr¨oßten Vorteile der Spline-Interpolation sind ihre Stabilit¨at und Berechnungsef- fizienz. Mengen von linearen Gleichungssystemen, welche f¨ur die Konstruktion der Splines gel¨ost werden m¨ussen, sind sehr gut konditioniert8. Dadurch werden die Polynomko- effizienten pr¨azise berechnet. Als Ergebnis bleibt das Berechnungsschema selbst f¨ur große N stabil. Die Konstruktion der Spline Koeffizienten Tabelle ist in linearer Zeit (O(n)) m¨oglich, w¨ahrend die Interpolation nur logarithmischen Aufwand (O(log n)) hat [ALG12b].
Aufgrund dieser Eigenschaften ist es als Sch¨atzverfahren f¨ur Ausf¨uhrungszeiten in einem Self-Tuning-Datenbankmanagementsystem geeignet, da nur ein geringen Overhead und eine gute Sch¨atzgenauigkeit zu erwarten sind. In Experimenten des Autors mit der Alglib [ALG12a] wurde f¨ur die Berechnung eines Sch¨atzwertes zwischen 0 und 3µs ben¨otigt, im Durchschnitt waren es 0.891465µ. Die Berechnung der Spline Funktion dauerte zwischen 260µs und 1468µs.
2.6.3 Zusammenfassung
In diesem Abschnitt wurde eine kurze Einf¨uhrung in die Interpolationsverfahren Methode der kleinsten Quadrate und Spline-Interpolation gegeben. Im n¨achsten Abschnitt werden einige Grundlagen zu Grafikkarten gegeben, da sie einige Besonderheiten aufweisen, die f¨ur die sp¨ateren Diskussion in dieser Arbeit relevant sind.
2.7 GPU
In diesem Abschnitt wird eine kurze Einf¨uhrung in den Aufbau und die Funktionsweise von GPUs gegeben. Zun¨achst erfolgt ein ¨Uberblick, um nachfolgend die zugrunde liegende Architektur vorzustellen. Anschließend folgt eine kurze Abgrenzung zwischen der von aktuellen GPUs genutzten SIMT-Architektur und der SIMD-Architektur. Der Abschnitt schließt mit einer Zusammenfassung.
2.7.1 Uberblick ¨
In den letzten Jahren ¨anderte sich die Nutzung von GPUs von rein graphischen Anwendungen zu einer Mehrzwecknutzung. Dieser Trend wird als General-Purpose-
8Sei Ax=b ein Gleichungssystem. Dann ist die Kondition einer Matrix A ein Maß daf¨ur, wie empfind- lich der relative Fehler einer L¨osung x ist, wenn ¨Anderungen an der rechten Seite b vorgenommen werden [FH07].
24 2.7. GPU
Computation-on-Graphics-Processing-Units (GPGPU) bezeichnet, was zu deutsch
”Mehrzweckberechnungen auf Grafikkarten” bedeutet. Die Idee ist, dass Anwendungen, die einen hohen Grad an Datenparallelit¨at aufweisen, von der massiv parallelen Architek- tur von GPUs profitieren k¨onnen [NVI12a].
2.7.2 SIMT-Architektur
Abbildung 2.6: Grid aus Thread-Bl¨ocken, entnommen aus [NVI12b]
Die nun folgenden Erl¨auterungen zu GPUs werden am Beispiel von Nvidia GPUs und CUDA (Compute Unified Device Architecture). CUDA ist eine parallele Berech- nungsplattform und ein Programmiermodell, welches von NVIDIA entwickelt wurde [NVI12a].
Eine GPU wird in CUDA als CUDA-Device abstrahiert, welches im Kern ein skalier- bares Array von Multithread-Streaming-Multiprocessors (SMs) ist. Ein solcher Multi-
