DBA Community - Mai 2011
DBA Community - Mai 2011
|
I/O Kalibrierung mit Orion in 11.2.0.2
von Frank Schneede, ORACLE Deutschland B.V. & Co. KG
Die Performance von Datenbanksystemen wird in der Praxis häufig durch die Fähigkeiten des verwendeten Storage Systems bestimmt. Um die Charakteristika
des Storage Systems vermessen und beurteilen zu können, gibt es verschiedene geeignete Ansätze.
Grundlegendes über das ORION Utility Die I/O Fähigkeiten einer Systemlandschaft lassen sich mit relativ einfachen Mitteln vermessen. Ein solches Mittel ist zum Beispiel die Verwendung des Unix Kommandos dd, das man in einem Skript parallelisiert aufrufen kann und so eine Aussage zur Leseperformance bekommt. Die folgenden Ausgaben zeigen einen solchen Testlauf, es wird ein parallelisiertes Lesen einer großen Datenmenge (hier: 4GB Daten) simuliert, wie man sie häufig in Datawarehouses mit dem Einsatz des Parallel Query Features vorfindet. [oracle@sccloud027 ~]$ dd bs=1048576 count=200 if=/home/oracle/data_02 of=/dev/null & [1] 18593 [oracle@sccloud027 ~]$ dd bs=1048576 count=200 skip=200 if=/home/oracle/data_02 of=/dev/null & [2] 18594 [oracle@sccloud027 ~]$ dd bs=1048576 count=200 skip=400 if=/home/oracle/data_02 of=/dev/null & [3] 18595 [oracle@sccloud027 ~]$ dd bs=1048576 count=200 skip=600 if=/home/oracle/data_02 of=/dev/null & [4] 18596 [oracle@sccloud027 ~]$ dd bs=1048576 count=200 skip=800 if=/home/oracle/data_02 of=/dev/null & [5] 18597 [oracle@sccloud027 ~]$ dd bs=1048576 count=200 if=/opt/oracle/data_01 of=/dev/null & [6] 18598 [oracle@sccloud027 ~]$ dd bs=1048576 count=200 skip=200 if=/opt/oracle/data_01 of=/dev/null & [7] 18599 [oracle@sccloud027 ~]$ dd bs=1048576 count=200 skip=400 if=/opt/oracle/data_01 of=/dev/null & [8] 18600 [oracle@sccloud027 ~]$ dd bs=1048576 count=200 skip=600 if=/opt/oracle/data_01 of=/dev/null & [9] 18601 [oracle@sccloud027 ~]$ dd bs=1048576 count=200 skip=800 if=/opt/oracle/data_01 of=/dev/null & [10] 18602 [oracle@sccloud027 ~]$ 200+0 records in 200+0 records out 200+0 records in 200+0 records out 200+0 records in 200+0 records out 209715200 bytes (210 MB) copied, 24.1506 seconds, 8.7 MB/s 209715200 bytes (210 MB) copied, 24.2083 seconds, 8.7 MB/s 209715200 bytes (210 MB) copied, 24.1999 seconds, 8.7 MB/s 200+0 records in 200+0 records out 209715200 bytes (210 MB) copied, 24.2363 seconds, 8.7 MB/s 200+0 records in 200+0 records out 209715200 bytes (210 MB) copied, 24.477 seconds, 8.6 MB/s 200+0 records in 200+0 records out 209715200 bytes (210 MB) copied, 24.4491 seconds, 8.6 MB/s 200+0 records in 200+0 records out 209715200 bytes (210 MB) copied, 24.416 seconds, 8.6 MB/s 200+0 records in 200+0 records out 209715200 bytes (210 MB) copied, 24.344 seconds, 8.6 MB/s 200+0 records in 200+0 records out 209715200 bytes (210 MB) copied, 24.404 seconds, 8.6 MB/s 200+0 records in 200+0 records out 209715200 bytes (210 MB) copied, 24.7684 seconds, 8.5 MB/s [1] Done dd bs=1048576 count=200 if=/home/oracle/data_02 of=/dev/null [2] Done dd bs=1048576 count=200 skip=200 if=/home/oracle/data_02 of=/dev/null [3] Done dd bs=1048576 count=200 skip=400 if=/home/oracle/data_02 of=/dev/null [4] Done dd bs=1048576 count=200 skip=600 if=/home/oracle/data_02 of=/dev/null [5] Done dd bs=1048576 count=200 skip=800 if=/home/oracle/data_02 of=/dev/null [6] Done dd bs=1048576 count=200 if=/opt/oracle/data_01 of=/dev/null [7] Done dd bs=1048576 count=200 skip=200 if=/opt/oracle/data_01 of=/dev/null [8] Done dd bs=1048576 count=200 skip=400 if=/opt/oracle/data_01 of=/dev/null [9]- Done dd bs=1048576 count=200 skip=600 if=/opt/oracle/data_01 of=/dev/null [10]+ Done dd bs=1048576 count=200 skip=800 if=/opt/oracle/data_01 of=/dev/null [oracle@sccloud027 ~]$Die Messung zeigt, dass hier für jede Session ca. 8,5MB/sec gelesen werden, das ergibt in Summe also eine Bandbreite von 85MB/sec. Leider haben die ausgeführten I/O Operationen nichts mit der realen Last, die auf einer Oracle Datenbank entsteht, zu tun. Daher ist es sinnvoll, die Messung mit Methoden zu präzisieren, die eine realistische Datenbanklast abbilden können. Hierzu stehen zwei Alternativen zur Verfügung:
OLTP Systeme zeichnen sich durch eine hohe Rate von small random reads und writes aus, deren Größe mit der Blockgröße der Datenbank übereinstimmt. Ein gängiger Wert der Datenbank Blockgröße ist in OLTP Systemen 8k. Die Performance von OLTP Systemen wird in erster Linie bestimmt durch den Durchsatz von I/O Operationen pro Sekunde (IOPS) und die Zeit, die für den Transport der I/O Operation durch das System benötigt wird (Latenz). ORION kann einen solchen Workload simulieren. Hierzu wird das Verhältnis von Lese- zu Schreiboperationen festgelegt, die Größe der einzelnen I/O Operation und die Anzahl der ausstehenden I/O Requests. ORION verteilt dabei die I/O Operationen über alle in den Test eingebundenen Platten. Im Gegensatz zu OLTP Systemen zeichnen sich DWH Systeme durch large sequential reads und writes aus, die standardmäßig als kontinuierlicher Strom von 1MB großen I/O Requests dargestellt werden. Die Größe einer einzelnen I/O Operation kann frei parametrisiert werden. Die Performance eines DWH Systems wird damit bestimmt durch den Durchsatz in MB pro Sekunde (MBPS). Neben DWH Systemen produzieren auch Operationen wie Bulk Loads, Backup und Restores derartige Workloads. Auf der Ebene der Festplatten stellt sich die Last im Allgemeinen jedoch anders dar. Bei der Verwendung von ASM, das alle Daten gleichmäßig über alle zur Verfügung stehenden Festplatten verteilt, sprechen wir von large random reads und writes, ebenfalls in einer Größe von 1MB oder einem Vielfachen davon. In einem realistischen Einsatzszenario hat man in den seltensten Fällen einen reinen OLTP oder reinen DWH Workload. Daher kann ORION verschiedene Lastcharakteristika miteinander kombinieren. Small random I/O kann mit large sequential I/O oder large random I/O kombiniert werden. Auf diese Weise ist es zum Beispiel möglich, eine OLTP Last von 8k small random reads und writes mit einer gleichzeitigen Backup-Last von mehreren parallelen 1MB large sequential reads zu simulieren und zu vermessen. Es versteht sich eigentlich von selbst, dass eine I/O Kalibrierung mit ORION nur dann belastbare Ergebnisse liefert, wenn das Storage System nicht oder nur sehr gering belastet ist. Zeitgleich zu einer Kalibrierung laufende ORION unabhängige Workloads können nicht berücksichtigt werden. Die Beispiele in diesem Tipp sind in einer virtuellen Maschine gelaufen, was die Werte natürlich verfälscht. Die ermittelten Messergebnisse sind nur dargestellt, um das grundsätzliche Arbeiten mit ORION zu illustrieren und reflektieren eine Situation, die sicher nur sehr eingeschränkt mit der realen Welt vergleichbar ist. Ein ORION Testlauf besteht aus einer parametrisierbaren Mischung von small und large I/O Workloads über ein gewisses Zeitintervall. Die Messergebnisse werden als Matrix dargestellt, wobei die x-Achse small I/O und die y-Achse large I/O darstellt. Eine Zeile der Matrix beinhaltet also die Messungen verschiedener small I/O Operationen zu einer festgelegten Anzahl von large I/O Operationen. In einer Spalte der Matrix kann man die Messungen verschiedener large I/O Operationen zu einer festgelegten Anzahl von smal I/O Operationen ablesen. Als Messwerte werden die Bandbreite in MBPS, der Durchsatz in IOPS und die Latenz festgehalten. Ein ORION Kalibrierungslauf kann wahlweise eine Zelle, eine Zeile, eine Spalte der Matrix oder die komplette Matrix selbst umfassen. Das ORION Utility arbeitet nur mit Dateien oder RAW Volumes, nicht mit Verzeichnissen. Es ist bei der Anlage der Dateien für die Kalibrierung wichtig, dass sie eine Größe haben, mit der eine Érzeugung eines relevanten I/O Volumens möglich ist. Für die Tests wurden Dateien in der Größe von 2GB angelegt. ORION kann auf unterschiedlichen festplattenbasierten Speichersystemen, die asynchrones I/O unterstützen, eingesetzt werden:
Vorbereitungen für die Durchführung einer Kalibrierung Für einen Testlauf mit ORION müssen eine Datei oder mehrere Dateien oder RAW Volumes angelegt sein, deren Bezeichnung(en) in ein Parameterfile eingetragen wird / werden. Jedes Volume steht in einer eigenen Zeile, ansonsten enthält das Parameterfile keine weiteren Angaben. Da in diesem Testbeispiel keine RAW Volumes zur Verfügung standen, wurden zwei Dateien angelegt, die jeweils ca. 2GB groß waren. Das Parameterfile trägt den Namen des Testlaufes mit der Erweiterung .lun. [oracle@sccloud027 bin]$ cat mytest.lun /opt/oracle/data_01 /home/oracle/data_02 [oracle@sccloud027 bin]$Die spezifizierten Volumes müssen für den Benutzer, der den Test durchführt, erreichbar sein. Dieses kann über das Linux Kommando dd leicht verifiziert werden. ORION verwendet für die Kalibrierung asynchrone I/O Operationen. Zur Sicherheit sollte daher noch festgestellt werden, dass die für asynchrones I/O verantwortlichen Bibliothek libaio im aktuellen Pfad enthalten ist. Bei der Verwendung auf dem Betriebssystem Windows spielt das keine Rolle, denn Windows hat entsprechende Bibliotheken bereits eingebaut. Jetzt kann es bereits mit einem einfachen Test losgehen, da es für den weniger versierten Administrator vorbelegte Parameter gibt, die im folgenden Abschnitt beschrieben werden. Testvarianten Der wichtigste Parameter zur Steuerung des ORION Utilities ist der Parameter -run level. Mit ihm lassen sich 4 vordefinierte Tests durchführen. Diese Tests entsprechen im Wesentlichen den unterschiedlichen Lastcharakteristika, die bereits oben beschrieben worden sind. Für den versierten Administrator ist es darüber hinaus möglich, durch die Angabe -run advanced jeden möglichen Parameter individuell festzulegen. Die vordefinerten Tests sind:
Durchführung und Auswertung der Kalibrierung Der Aufruf des ORION Utilities erfolgt über einen einfachen Aufruf. In der Shell Oberfläche erscheint nach dem Aufruf der Name, unter dem die Ergebnisdateien erstellt werden, sowie ein kurzer Hinweis auf die vermutliche Dauer der Kalibrierung. Die Dauer des Tests hängt natürlich in starkem Maße vom gewählten Umfang der Kalibrierung ab. Daher kann es durchaus sinnvoll sein, nur einen Teil der Ergebnismatrix berechnen zu lassen. [oracle@sccloud027 bin]$ ./orion -testname mytest -run normal ORION: ORacle IO Numbers -- Version 11.2.0.2.0 mytest_20110510_2303 Calibration will take approximately 19 minutes. Using a large value for -cache_size may take longer.Sobald der Testlauf beendet worden ist, erfolgt eine Ausgabe der ermittelten Messwerte (Maximum für MBPS, IOPS und Minimum für Latenz) in der Shell. Zusätzlich zu dieser Bildschirmausgabe werden sechs Ergebnisdateien erzeugt, mit Hilfe derer eine grafische Darstellung der Ergebnisse möglich ist. Die durch den Test im aktuellen Verzeichnis erstellten sechs Ergebnisdateien tragen als Präfix den Testnamen aus der Bildschirmausgabe (hier: mytest_20110510_2303) und lassen sich auf diese Weise leicht identifizieren. Die Datei mytest_20110510_2303_summary.txt stellt die Zusammenfassung des Tests dar und bietet einen Überblick über die Parametrisierung des Tests und die bereits oben beschriebenen maximal gemessenen Werte für large random/sequential I/O in MBPS, small random I/O in IOPS und die minimale Latenz für small random I/O.
ORION VERSION 11.2.0.2.0
Command line:
-testname mytest -run normal
These options enable these settings:
Test: mytest
Small IO size: 8 KB
Large IO size: 1024 KB
IO types: small random IOs, large random IOs
Sequential stream pattern: one LUN per stream
Writes: 0%
Cache size: not specified
Duration for each data point: 60 seconds
Small Columns:, 0, 1, 2, 3, 4, 5
Large Columns:, 0, 1, 2
Total Data Points: 18
Name: /home/oracle/data_02 Size: 2147483648
1 files found.
Maximum Large MBPS=131.12 @ Small=0 and Large=2
Maximum Small IOPS=4734 @ Small=5 and Large=0
Small Read Latency: avg=639 us, min=0 us, max=1305307 us, std dev=4348 us @ Small=3 and Large=0
Minimum Small Latency=248 usecs @ Small=1 and Large=0
Small Read Latency: avg=248 us, min=0 us, max=445929 us, std dev=1363 us @ Small=1 and Large=0
Small Read / Write Latency Histogram @ Small=3 and Large=0
Latency: # of IOs (read) # of IOs (write)
0 - 1 us: 7418 0
2 - 4 us: 0 0
4 - 8 us: 0 0
8 - 16 us: 0 0
16 - 32 us: 2 0
32 - 64 us: 105971 0
64 - 128 us: 18208 0
128 - 256 us: 389 0
256 - 512 us: 101880 0
512 - 1024 us: 5593 0
1024 - 2048 us: 629 0
2048 - 4096 us: 143 0
4096 - 8192 us: 338 0
8192 - 16384 us: 321 0
16384 - 32768 us: 102 0
32768 - 65536 us: 40 0
65536 - 131072 us: 7 0
131072 - 262144 us: 0 0
262144 - 524288 us: 1 0
524288 - 1048576 us: 0 0
1048576 - 2097152 us: 0 0
2097152 - 4194304 us: 0 0
4194304 - 8388608 us: 0 0
8388608 - 16777216 us: 0 0
16777216 - 33554432 us: 0 0
33554432 - 67108864 us: 0 0
67108864 - 134217728 us: 0 0
134217728 - 268435456 us: 0 0
Die Datei mytest_20110510_2303_mbps.csv beinhaltet die durch Komma getrennten Werte für die erzielte Bandbreite. In dem Test, der hier als Beispiel dargestellt ist, sieht man eine zweidimensionale Matrix, aus der sich durch einen Import in Excel eine aussagekräftige Grafik erzeugen läßt. Die Kurven sollten sich bei einer sauber durchgeführten Kalibrierung asymptotisch einem Maximalwert annähern, wie in der Dokumentation mit synthetischen Werten dargestellt. Zur Erinnerung sei an dieser Stelle vermerkt, dass die hier gezeigte Messung auf einer virtuellen Umgebung erstellt wurde, auf der andere laufende virtuelle Maschinen das Ergebnis verfälschen. Trotzdem wird eine qualitativ gute Messung erreicht. An dem folgenden Bild sieht man, dass mit mehr ausstehenden large I/O die maximal erreichbaren Bandbreite schneller erreicht wird. Diese liegt bei gut 130MB/sec. 
Abbildung 1: Bandbreite in MBPS Die Datei mytest_20110510_2303_iops.csv beinhaltet die durch Komma getrennten Werte für den Durchsatz. Auch hier läßt sich mit Hilfe von Excel eine Grafik erstellen. 
Abbildung 2: Durchsatz in IOPS Im Idealfall sollten sich die Kurven auch hier asymptotisch einem Maximalwert annähern, der den maximalen Durchsatz an I/O Operationen pro Sekunde markiert. Man sieht deutlich, dass auf dem eingesetzten System eine reine Last aus small I/O einen höheren Durchsatz erzielt, als wenn large I/O hinzukommen. Es werden maximal gut 4800 I/O Operationen pro Sekunde erreicht. Die dritte Datei mytest_20110510_2303_lat.csv enthält ebenfalls eine zweidimensionale Matrix mit Testergebnissen, die sich wie bereits oben beschrieben als Grafik aufbereiten lässt. 
Abbildung 3: Latenz in ms In der realen Welt sollte die gemessene Latenz mit steigendem I/O linear ansteigen, wie es auch in diesem Testlauf der Fall ist. Die Latenz steigt bei der gemischten Last, die durch die rote und grüne Kurve dargestellt wird, am schnellsten an. Dieses Ergebnis hat sich bereits durch die Analyse der IOPS dieses Testlaufes angedeutet. Die verbleibenden zwei Ergebnisdateien liegen im Textformat vor. Die Datei mytest_20110510_2303_hist.txt enthält Latenzen für die durchgeführten Messreihen, die Datei mytest_20110510_2303_trace.txt enthält schließlich die detaillierten Testergebnisse. Fazit Das ORION Utility ist eine gute Möglichkeit, die I/O Kennzahlen eines Systems zu vermessen. Das System sollte hierzu real sein, das heißt, nicht auf einer virtualisierten Plattform laufen, auf der in der Regel keine aussagekräftigen Messungen möglich sind. Ebenso sollte während einer I/O Kalibrierung das System anderweitig nicht oder nur sehr gering durch andere Sessions belastet sein. Die vielfältigen Parametrisierungsmöglichkeiten können den weniger versierten Administrator leicht in die Irre führen. Daher ist es hilfreich, mit einfachen Messungen zu beginnen und sich nach und nach tiefer in die Materie einzuarbeiten. Eine Kalibrierung mit einem festen Wert für small random I/O oder large sequential/random I/O berechnet nur eine Zeile beziehungsweise Spalte der Ergebnismatrix. Die damit ermittelten Messwerte sind ebenfalls leichter zu verstehen und zu interpretieren. Weitergehende Informationen zur Verwendung des ORION Utilities und ergänzende Beispiele finden sich in der Dokumentation. |