Der Einfluss der Storage auf die Datenbankperformance 

updated on

Hinweis: Dieser Blog-Artikel ist auch als DOAG Datenbank Kolumne erschienen.

Dieser Artikel ist der Dritte einer dreiteiligen Serie, in der wir den Einfluss von CPU, Hauptspeicher und Storage auf die Datenbankperformance beleuchten.

„It´s all about latency, stupid!“ (angelehnt an „It´s the economy, stupid!“)

Im Storage-Bereich werden oft nur IOPS und MBPS beachtet. Selbstverständlich sind sie für das Sizing einer Storagelösung relevant, für die Datenbank-Performance ist aber die Latency viel wichtiger.

Wie sind diese Kennzahlen definiert?

Latenz: Wie lange dauert es um eine I/O-Anforderung zu beantworten?
Nicht alle I/O-Anforderungen sind gleich groß (Indexzugriffe führen zu I/Os mit der Oracle Blocksize und Full Table Scans meist im Bereich von 1MB). Bei OLTP-Datenbanken sind es meist einzelne Oracle-Blöcke, die gelesen werden, bei DWH/DSS/Reporting eher mehrere Blöcke auf einmal.

IOPS: Gibt an wie viele einzelne I/O Requests (die meisten Storage-Hersteller nutzen 4k I/Os als Basis) die Storage maximal ausliefern kann. Das setzt voraus, dass der Datenbank-Server genug Rechenleistung hat, um diese Datenmenge zu verarbeiten beziehungsweise dass die Anbindung an die Storage ausreichend dimensioniert ist. Aktuelle Storages (SSD bzw. NVMe) schaffen meist ausreichende Performance, sofern man durch sinnvolles Hauptspeichersizing (siehe den zweiten Artikel dieser Serie) dafür sorgt, dass nur jene I/Os gemacht werden, die wirklich notwendig sind.

MBPS

Wie viele fortlaufende MBs kann man pro Sekunden abrufen? Das ist für Full Table Scans, Archiving oder RMAN Backup relevant.

Diese drei Kennzahlen hängen auch von der Rechenleistung und der Anbindung des Datenbankservers ab. Verfügt eine VM beispielsweise nur über 1 CPU Core, so wird diese deutlich weniger I/O-Leistung erreichen können, als eine VM mit 16 CPU Cores. Als Tool zur Ermittlung der Leseperformance eignet sich I/O-Calibration der Oracle-Datenbank. Siehe auch:

Vorsicht: I/O-Calibration dient zum Stressen der Datenbank (und somit der Storage). Die Ausführung sollte nur zu Zeiten stattfinden, wo keine anderen Storage- und/oder Datenbankbenutzer gestört werden.

Die Bedeutung der Latenz

Die Werte für IOPS und MBPS sind natürlich auch relevant, aber viel wichtiger ist die Latenz. Diese ist einerseits von der genutzten Storage-Technologie (Harddisks liegen im Bereich von 3-16ms, NVMes eher bei 3-20us um den Faktor 1000 niedriger) als auch von der aktuellen Auslastung der Storage-Infrastruktur abhängig. Um eine gleichmäßige Storage-Performance sicherzustellen, sollte die Auslastung des Storage-Systems deutlich unter 80% liegen (Empfehlung: unter 50%). Der Grund ist, dass diese Werte immer über einen bestimmten Zeitraum (meist mehrere Sekunden bis wenige Minuten) gemittelt werden. Damit erkennt man kurzfristige Lastspitzen nicht, die sich aber durchaus auf die Datenbankperformance auswirken. Speziell wenn man viele Oracle-Datenbanken nutzt, führen die stündlichen AWR-Snapshots zu regelmäßigen Spikes. Die Storage-Administratoren beklommen diese oft nicht mit, weil ihr Monitoring nur 5 oder 10 Minuten Mittelwerte anzeigt. Die Last durch die AWR-Snapshots dauert in der Regel aber deutlich unter einer Minute. Erst wenn man das Monitoring im Sekundenbereich aktiviert, sieht man entsprechende Spikes, die sich nicht nur auf alle Oracle-Datenbanken, sondern auf alle Systeme auswirken, die mit dieser Storage verbunden sind.

Jeder I/O, der durchgeführt werden muss, beschäftigt:

  • Die CPU des Datenbankservers
  • Die Storage-Infrastruktur-Komponenten
  • Die Storage und deren Devices (HDDs, SSDs, NVMes,…)

Somit ist der beste I/O der, den man NICHT macht. Selbst wenn man über eine große NVMe Storage verfügt, liegt die Latenz im Bereich von mehreren/vielen Mikrosekunden (1/1.000.000 Sekunden) und wird oft durch die Leitungslängen zwischen Datenbank- Server und Storage verzerrt. In der Praxis schafft man mit typischen NVMe Storages nur Latenzen im Bereich von 0,01 und 0,2 Millisekunden.

Vergleicht man diese Zeit mit der Dauer, um einen Datenbank-Block im Buffer Cache zu finden – diese liegt aktuell unter 0,01 Mikrosekunden um den Faktor 1.000 unter der minimalen Latenz einer NVMe Storage – so liegen hier nochmals (Performance-)Welten dazwischen.

Somit ist klar: Jeder I/O, den man sich ersparen kann – und das sind nur die lesenden I/Os, Änderungen müssen immer auf die Storage geschrieben werden – ist der beste I/O.

Oracle hat in den 1990ern angegeben, dass das Verhältnis zwischen lesenden und schreibenden I/Os den Wert von 20 möglichst nicht überschreiten sollte (20 lesende I/Os auf einen schreibenden I/O). Allerdings wurde nie ganz genau spezifiziert, welche I/Os (Datenbank Blocks, Online Logfile, Archivelogfile,…) Oracle hier wertet. Aktuell empfehlen wir, dass die Datenbank weniger lesende als schreibende Oracle-Blockzugriffe machen sollte. Diese kann man am einfachsten in einen AWR- oder Statspack-Report nachlesen. Diese Werte findet man am Anfang im „Load Profile“ als „Physical read (blocks)“ beziehungsweise „Physical write (blocks)“.

Bei OLTP-Datenbanken sollte dies typischerweise durch Vergrößern des Buffer Caches möglich sein. Bei DWH/DSS/Reporting mit vielen 1 MB großen I/Os wird das nicht immer erreichbar sein.

Die Latenz für die I/O-Operationen findet man ebenfalls im AWR- oder Statspack-Report unter „Top 10 Foreground Events by Total Wait Time“. Es handelt sich um die Events „db file sequential read“ (Indexzugriffe, Single Block) sowie „db file scattered read“ (FTS, Multiblock). Diese Werte spiegeln die für die Datenbank realistischen I/O-waits wieder.

Speziell im Bereich Storage Performance reden Datenbank- und Storage-Administratoren oft aneinander vorbei. Das liegt einerseits daran, dass auf verschiedene Werte geschaut wird (DBA auf Latenz der Datenbank-IOs, Storage Admins auf IOPS/MBPS der Storage) und andererseits daran, dass der Fokus bei einem DBA nur auf Datenbanken und bei einem Storage Administrator auf der gesamten I/O-Last im Unternehmen liegt. Viele vernachlässigen dabei jedoch, dass beispielsweise mehrere VMs auf einem physischen Server sich gegenseitig beeinflussen, wenn mehrere/alle VMs hohe I/O-Lasten generieren. Das muss auf der Storage selbst noch nicht zu einer höheren Last führen, für die Datenbank in den VMs aber schon.

Wenn man nach einem sinnvollen Sizing des Buffer Caches – und damit deutlicher Reduktion des I/O-Bedarfs der Datenbank – immer noch Probleme hat, muss man sich alle involvierten Komponenten genauer ansehen:

  • physischer Server, auf dem die Datenbank läuft
  • Virtualisierungslösung
  • Storage-Infrastruktur (Leitungen und aktuelle Auslastung der aktiven Komponenten)
  • Storage Auslastung allgemein
  • Auslastung von Volumes/Aggragaten/Storage Devices

Ein Beispiel aus der Praxis

Die Datenbank-Performance war extrem schlecht, mehr als 100-200 IOPS hat sie nicht geschafft. Erst eine detaillierte Analyse hat ergeben, dass der Storage Verantwortliche alle „Datenbanken“ auf eine Gruppe von (damals noch Harddisks) gelegt hat. Das waren neben einer Oracle-Datenbank auch eine Exchange-„Datenbank“. Da beim Kunden extrem viele eMails verarbeitet/versendet wurden, hat Exchange so viele I/O-Requests erzeugt, dass über 98 % aller I/Os von Exchange waren. Das Verschieben der Oracle-Datenbank auf einen anderen Diskbereich hat das Problem gelöst.

Die Storage Admins haben zu Recht behauptet, dass die Oracle-Datenbank “keine nenneswerte” Last erzeugt, aber nicht berücksichtigt, dass eben Exchange alle verfügbaren I/O-Ressourcen konsumiert hat.

Das war der letzte Teil der Artikelserie „Der Einfluss … auf die Datenbankperformance“.