IO Calibrate, Parallel Server und Datenbank auf Filesystemen

updated on

Ausgangssituation

Die alten Datenbank Server sollen gegen neue ausgetauscht werden, die Storage selbst bleibt wie diese ist. Auf den alten Datenbank Server wird ASM genutzt. Für die neuen Server wird überlegt auf ASM zu verzichten, da es keinen Grund mehr dafür gibt.

Um zu verifizieren, dass dies ein Umstieg von ASM auf Filesystem keinen Performancenachteil mit sich bringt, soll mittels IO Calibrate sowohl von einem alten Server als auch von einem neuen Server aus getestet werden. Auf dem alten Server wurde eine VM mit 4 Cores und einer Entwicklungsdatenbank ausgewählt, auf der zum Zeitpunkt vom IO Calibrate laufe, keine Benutzer angemeldet waren. Das Ergebnis war wie folgt:

/* Alter Server, VM mit 4 Cores, ASM */

max_iops = 225981
latency  = 1.338
max_mbps = 5267

Auf dem neuen Server wurde ebenfalls eine VM mit 4 Cores gebaut und eine leere Datenbank mit der gleichen Größe wie die Entwicklungsdatenbank angelegt.

Anmerkung: Die Größe einer Datenbank hat Auswirkungen auf die Ergebnisse von IO Calibrate, abhängig vom Cache in der Storage. Um fair zu vergleichen, muss die Datenbank grob gleich groß sein. Es ist dabei irrelevant ob Daten in den Datenbankfiles vorhanden sind.

Abgesehen vom setzen von FILESYSTEMIO_OPTIONS=SETALL wurde in der Instanz nichts eingestellt. Als Filesystem wurde EXT4 ausgewählt. Das Ergebnis des ersten Tests war ernüchternd:

/* Neuer Server, VM mit 4 Cores, EXT4 */

max_iops = 5058
latency  = 0.712
max_mbps = 2640

Die Werte sind – abgesehen von der Latenz – massiv schlechter, nur warum?

Schaut man sich während IO Calibrate läuft, die „average load“ in den VMs an, fällt auf, dass diese im Fall von ASM auf rund 4 (somit die Anzahl der Cores) steigt. Im Fall von EXT4 explodiert die „average load“ aber auf weit über 100! Was ist der Grund für dieses Verhalten?

Dazu muss man wissen, dass IO Calibrate die Last mit Hilfe von Parallel Query Prozessen während des Test laufend erhöht. Auf Grund der Defaults von Oracle, wird auf einem Server mit 4 Cores der Wert für PARALLEL_MAX_SERVERS auf 80 eingestellt. Somit versuchen bis zu 80 Prozess „gleichzeitig“ IOs zu machen, wodurch die Filesystem Treiber ebenfalls viele Threads/Prozesse starten, die sich gegenseiten behindern.

In der Praxis wird es in der Regel nicht vorkommen, dass ein einziges SQL Statement alle Parallel Query Server Prozesse gleichzeitig nutzt. Im Fall von 4 Cores, wird der Oracle CBO üblicherweise nur 8 Prozesse für ein Statement nutzen. Das Verhalten von IO Calibrate entspricht insofern also nicht einer normalen Belastung.

Workaround für IO Calibrate und Datenbanken auf Filesystemen

Damit man sinnvoller/realistische Werte vom IO Calibrate bekommt, sollte man somit PARALLEL_MAX_SERVERS auf Anzahl Cores mal zwei einstellen. Diese Änderung führt zu folgendem Ergebnis:

/* Neuer Server, 4 Cores, EXT4, PARALLEL_MAX_SERVERS=8 */

max_iops = 219893
latency  = 0.332
max_mbps = 6206

Das schaut schon viel besser aus. Die IOPS sind ähnlich wie mit dem alten Server und innerhalb der Messungenauigkeit, weil die Storage ja produktiv genutzt wird. Die Latenz hat sich gegenüber den alten Servern deutlich verbessert und beim Durchsatz sind es auch 20% mehr.

Die besseren Werte für die Latenz und den Durchsatz sind auf die neuen, schnelleren CPUs zurückzuführen, die einfach mehr in der gleichen Zeit leisten. Die IOPS Werte dürften durch die aktuelle Storageauslastung gegeben sein.

Zusammenfassung

Mit den Defaulteinstellungen für PARALLEL_MAX_SERVERS schließt IO Calibration bei Filesystemen über das Ziel hinaus. Erst durch eine Anpassung des Parameters bekommt man die gewünschten, korrekten Ergebnisse.

Referenzen