Einfluss der Infrastruktur auf die Oracle Datenbank Jeder sagt: bei mir ist alles in Ordnung und trotzdem geht alles langsam
Themenübersicht Welche I/Os verursacht Oracle? Auswirkungen von Latenzen? Woher kommen die Latenzen? Die geheime neue Technologie, um Latenzen zu eliminieren Und noch einige Überlegungen Richtung SSD/Flash
Welche I/Os macht Oracle? I/O Arten: sync versus async, normal versus direct Benutzer Server Prozess Database Writer Prozess Log Writer Prozess Archiver Prozess
I/O Arten: sync versus async(im SAN) SAN Fabric SAN Storage Datenbank Server SGA DBWR Filesystem Cache acknowledge Synchroner I/O Der DBWR schreibt einen Block und muss auf das Acknowledge warten. Dann erst kommt der nächste Block dran. Asynchroner I/O Der DBWR schreibt ALLE Blöcke sofort hintereinander und wartet dann auf die Acknowledges.
I/O Arten: normal versus direct(im SAN) SAN Fabric Datenbank Server SGA Filesystem Cache DBWR direct normal Der Filesystem Cache ist dazwischen geschalten. direct Der Prozess umgeht das Filesystem Cache. Oracle SETALL Bedeutet DIRECT und ASYNC SAN Storage
Filesystem Cache versus Oracle Buffer Cache Findet ein Prozess einen Block im Oracle Buffer Cache, kann dieser sofort genutzt werden Zugriffzeit im Nanosekundenbereich (einige CPU Takte) Findet der Prozess den Block nicht, wird ein I/O generiert, der vom Filesystem Cache bearbeitet wird. Ist der Block im FS Cache wird, dieser in den Buffer Cache kopiert Zugriff im Microsekundenbereich (einige 100 bis einige 1000 CPU Takte). Overhead: zusätzliche Applikation Context Switches auf der CPU.
Und wie sieht das ganze im NFS/NAS Bereich aus? Normales NFS versus dnfs Datenbank Server SGA DBWR NFS Client Normales NFS dnfs Storage LAN NAS Storage FS Cache Bei NFS liegt das Filesystem (und das Cache) in der Storage. Normales NFS Der I/O Request wird über einen NFS Client abgewickelt dnfs Der I/O erfolgt über einen Oracle internen NFS Client direkt ohne Context Switches
Falle von NFS Es gibt keinen Filesystem Cache auf dem Server sondern im Storage ein Zugriff, der bei einem lokalen Filesystem Cache erledigt würde, muss jetzt über die Netzwerk Infrastruktur zum Storage Zugriff im Millisekundenbereich (Latenzen). Aber: Vergrößert man den Buffer Cache um jenes Memory, das der lokale Filesystem Cache belegen würde, erhält man weniger I/Os in Richtung Storage!! man ist schneller!!
dnfs versus normales NFS und SAN Beim normalen NFS und bei SAN muss der Datenblock vom jeweiligen Oracle Prozess von/in den Buffer Cache kopiert werden. Bei dnfs kann der Datenblock OHNE Zwischenkopie direkt von/zu der Netzwerkkarte ins/vom Buffer Cache geschrieben werden weniger CPU Belastung, keine I/O Waits. In der Praxis: mindestens eine Verdoppelung der IOPS, sofern die Infrastruktur mitspielt. Deutlich weniger CPU Auslastung!
Benutzer Server Prozess (nur lesen, ausgenommen Sort und Direct Path Verarbeitung) Bei einem Zugriff über einen Index => Verhalten: sync!!! Index Blöcke (root, branch, leaf) lesen einen nach dem anderen bis es einen Treffer gibt Den Tabellen Block lesen Optional wieder zurück zum Index Block (wenn mehrere Treffer existieren können) Einen Full Table Scan => Verhalten: async I/O Request für hintereinanderliegende Blöcke (abhängig von verschiedenen Faktoren) maximal 1MB auf einmal.
Database Writer Prozess (nur schreiben, meist einzelne Blöcke) Mit Ausnahme von Bulk Inserts oder Insert APPEND schreibt der DBWR immer nur einzelne Datenbank Blöcke zurück. Hier ist es entscheidend, ob das SYNC oder ASYNC erfolgen kann. Filesystem Cache könnte theoretisch helfen (Write Back Cache) - aber gerade bei Systemen, die unter hoher CPU Belastung stehen, wird es eher langsamer Empfehlung: DIRECT
Log Writer Prozess (schreibt nur in die Online Logfiles) Die I/O Größe hängt von der Transaktionsgröße ab Minimum/Vielfaches von: 512 Bytes Maximum: 1MB Der LGWR ist immer DIRECT und SYNC Nur damit kann Oracle bei einem Instance Crash garantiert wieder Recovery durchführen.
Archiver Prozess (liest Online Logfiles und schreibt Archivelogs) Sequentielles lesen (möglichst Async) in MB Stücken Durch mehr Online Log Gruppen kann man kurzfristige Transaktionsspitzen abfedern, so dass der ARCH Prozess nicht ins Hintertreffen gerät und den LGWR blockiert (Archiver Hung)
Auswirkungen von Latenzen? Wie wirken sich unterschiedlich lange Latenzen auf die verschiedenen I/Os aus? Warum gibt es unterschiedliche Latenzen für Lesen und Schreiben? Warum schwankt die Latenz abhängig von der I/O Anzahl?
Wie wirken sich unterschiedlich lange Latenzen auf die verschiedenen I/Os aus? Benutzer Prozess (SQL Verarbeitung) Bei Cache Hit Ratios von >= 99% bei OLTP Systemen muss im Durchschnitt nur bei jedem 100ten Blockzugriff (Index Zugriffe) überhaupt ein I/O zur Storage erzeugt werden mittlere Auswirkung Database Writer sowie Archiver Solange der DBWR und der ARCH seine I/Os los werden, ist die Latenz nicht kritisch geringe Auswirkung Log Writer Der LGWR schafft bei 1ms pro I/O 1000 Transaktionen / Sec. Bei 10ms pro I/O nur noch 100 Transaktionen und bei 100ms pro I/O nur noch 10 Transaktionen / Sec extreme Auswirkungen
Warum gibt es unterschiedliche Latenzen für Lesen und Schreiben? Jedes Storage hat ein Read Cache Beim Lesen kann ein Block im Read Cache stehen das Storage kann sofort antworten Latenz typischerweise <= 1ms Muss das Storage auf der Disk lesen, wird der I/O in eine Disk Queue gestellt selbst unter geringer Last sind 4-5ms schon sehr gut wenn im schlechtesten Fall gerade viel in der Disk Queue steht, kann es auch einmal 50-100ms dauern! und meist auch ein Write Cache Solange im Write Cache noch Platz ist, wird der Block dort abgelegt und das Storage meldet fertig typischerweise 1-2 ms Kommt das Storage mit dem Schreiben nicht nach siehe Read Cache
Warum schwankt die Latenz abhängig von der I/O Anzahl? Weil oft gelesene Bereiche von Disks im Storage Cache liegen I/O Requests werden im Schnitt öfter aus dem Cache beantwortet Seltener gelesene Bereiche müssen immer über I/Os befriedigt werden I/O Requests dauern immer mindestens 4-5 ms und teilweise viel länger Kommen zu viele I/O Requests im Storage an, beginnen die Disk Queues zu wachsen I/Os dauern immer länger
Woher kommen die Latenzen? Einige Beispiele und Infos Nutzung von File System Cache SPC Benchmarks (Storage Benchmarks) Direct Attached Storage SAN Storage / NAS Storage
Ausgangsbasis: Zugriff auf Datenblock im Buffer Cache Im Idealfall liegt ein Block schon im Buffer Cache der Oracle Datenbank Instanz. Ein Zugriff (ermitteln wo der Block im Cache liegt) erfolgt über HASH Chains und im Schnitt sind 4 Blöcke in der Chain bei aktuellen CPUs sollten das in Summe nur einige wenige bis maximal 100 CPU Operationen sein. Eine CPU Operation bei einer x GHz CPU benötigt unter einer NANO Sekunde gehen wir daher von einer durchschnittlichen Lookupzeit von 20-30 Nano Sekunden aus in dieser Zeit kann der Block verarbeitet werden.
Im Server SAN mit FilesystemCache Alle Zeiten sind Beispiele und Schätzungen, von HW/SW abhängig! Oracle Prozess: Block ist nicht im Buffer Cache Erzeugen eines I/O Requests in Richtung FS Cache Context Switch (im optimalen Fall, kein andere Prozess braucht die CPU) Suche im FS Cache I/O weiter Richtung FS Treiber Worst Case: ein Context Switch (bei einigen FS) Filesystem übergibt den I/O an die Treiber Context Switch (im optimalen Fall, kein andere Prozess braucht die CPU) 20-30ns 10-100ns 10-30ns 20-100tens 10-30ns 10-100ns 10-30ns I/O Request Queue im Treiber und im HBA (warten bis man dran ist)??? I/O Request geht auf die Leitung, siehe nächste Seite Gesamtdauer: nicht unter 100ns (=0,1μs), können aber viele ms werden!
Die Physik. Bei 10GBit Leitungen (Glasfaser) Latenz pro 1m Leitungslänge (ca. 1/3 Lichtgeschwindigkeit) somit pro 100m I/O Request übertragen nur einige Bytes (unter 50) Laufzeit im Kabel um 50 Bytes = 400 Bits zu übertragen 8k Daten brauchen für die Übertragung 10ns 1000ns 40ns 6-7000ns
SPC Benchmarks (SPC-1 = Block Based Benchmark) http://www.storageperformance.org Hier findet man eine Menge von Storage Benchmarks, leider nicht 1:1 für Oracle nutzbar Es werden 4K Blöcke verwendet Es laufen immer mehrere Streams / Sessions parallel Bei vielen Benchmarks wird nur das Storage Cache gestresst, nicht die Disks (relative kleine Datenmengen)
Direct Attached Storage (SAN) Beispiel Aus Benchmarks HP P6500, 515GB Datenbereich 2.000 IOPS 0,43ms Storage Cache 10.000 IOPS 0,99ms Storage Cache 16.000 IOPS 2,27ms Storage Cache 19.000 IOPS 5,30ms 20.003 IOPS (maximaler Durchsatz) 11,23ms XIO Emprise 5000, 4.6TB Datenbereich 600 IOPS 1,88ms Storage Cache 3000 IOPS 3,34ms Storage Cache 5700 IOPS 7,14ms 6066 IOPS (maximaler Durchsatz) 9,21ms
SAN (8 Gbit) / LAN (10 Gbit) Infrastruktur I/O Request I/O Request sind nur einige Bytes (unter 50) Laufzeit im Kabel um 50 Bytes = 400 Bits zu übertragen Latenz pro 1m Leitungslänge (ca. 1/3 Lichtgeschwindigkeit) Latenz im Switch 5ns 10ns Cisco Nexus 3548 ca. 300ns Cisco Nexus N6004 ca. 1.000ns Cisco Nexus N5500 Serie ca. 2.000ns Cisco Catalyst 6500 Serie ca. 11-15.000ns Worst Case: Warten im Switch, bis die Leitung frei wird??? Gesamtzeit bei 100m Leitungslänge/Nexus 3548 nicht unter 1,3μs bis zu einige 10μs
SAN (8 Gbit) / LAN (10 Gbit) Infrastruktur Datenblock über SAN/NAS Im Prinzip das gleiche wie zuvor, allerdings 8k Daten brauchen mehr Zeit, bis diese übertragen sind ca. 6-7μs NFS ohne Jumbo Frames: werden aus 8k in Summe 6 Einzelpakete!??? Jede Übertragung (jedes Paket) braucht ein Acknowledge Das kann man grundsätzlich nicht der Übertragung anlasten, es kann aber die Leitung kurz blockieren Gesamtzeit: um mindestens 6-7μs länger als der I/O Request, bei NFS ohne Jumbo Frames kommen noch einige 100ns dazu.
Zusammenfassung SAN / LAN Infrastruktur Latenz - Optimalfall Mit neuester Hardware (Cisco Nexus 3548) Mit etwas älterer Hardware Alte Hardware (Cisco 6500 Serie) < 10μs min 15μs min 30-40μs
NFS Storage Benchmarks http://www.spec.org/sfs2008/results/sfs2008nfs.html Hier geht es weniger um die Ergebnisse als um den Vergleich mit Direct Attached Storages bei NFS muss ein Switch dazwischen sein Die Ergebnisse sind daher praxisnäher. Erkenntnis aus den Benchmarks: Unter 0,6 ms bis 0,7ms (aus dem Storage Cache) kommt keiner (EMC, NetApp, ) Viele schaffen es nicht unter 1ms!
SAN/NAS Benchmarks im Vergleich Interessant sind sowohl die IOPS als auch der Punkt, ab dem die Latenz deutlich über 3ms steigt Source: http://searchstorage.techtarget.com/new-benchmark-results-for- Unified-Scale-Out-Storage
Zusammenfassung der Erkenntnisse zur Latenz Block im Oracle Buffer Cache (Memory) Block im Filesystem Cache Direct Attached Storage SAN/NAS Storages ca 0,02μs >7μs (copy to BC) >500μs >6-700μs, eher >1ms Was lernt man daraus? Jeder Block, der schon im Memory der Instanz ist, muss nicht gelesen werden das entlastet die Infrastruktur und bringt massive Performancevorteile für den Benutzer! So gesehen beginnt Infrastrukturtuning mit einem optimalen Sizing des Datenbank Instanz Buffer Caches!
Die geheime neue Technologie um Latenzenzu eliminieren Wir stellen die geheime neue Technologie vor
Die geheime neue Technologie ist Nutze die aktuellen Möglichkeiten bezüglich des Hauptspeicherausbaus von Servern sinnvoll aus!
Erinnern Sie sich an die Key-Note SGA Sizing Projekt bei Egger Projekt ist aktuell noch ongoing, hier einige Beispiele SAP BW Landschaft Buffer Cache von 60G auf 280G Von 7.000-8.000 IOPS auf einige 100 IOPS SAP EGP Datenbank Buffer Cache von 60G auf 280G Von 500 IOPs auf unter 100 IOPS Pro Tag über 44 Stunde weniger I/O Wait, die beim Benutzer ankommen!
Oracle Huge Buffer Cache Datenbanken Aktuelle Server können schon TBs an Hauptspeicher bereitstellen! Sie haben schon 99,87% Cache Hit Ratio? Der Memory Advisor sagt: kein Bedarf an mehr Memory Aber wie erklären Sie sich das? V$DB_CACHE_ADVICE: 55% ESTD_PCT_OF_DB_TIME_FOR_READS Über 99% der Verarbeitung ist I/O Wait Bei einem Statement Cache Hit Ratio von über 99% Wo aber häufig laufende Statements um den Faktor 100 schneller werden könnten
Kundenprojekt / SGA Sizing für SAP BW Landschaft Oracle Memory Advisor: alles OK, 60GB Buffer Cache sind perfekt Unsere Empfehlung: mindestens 200GB Buffer Cache, Umsetzung: 240GB Vorher: 300MB/Sec, Peaks 450MB/Sec, 7.000-8000 IOPS, Peaks >10.000 IOPS Nachher: wenige MB/sec, Peaks 40MB/Sec, wenige 100 IOPS, Peaks <1.000 IOPS
Oracle 12c In-Memory Database Cache Option SGA Bereich für In-Memory Cache In der SGA wird ein zusätzlicher Bereich der In-Memory Column Store bereitgestellt Sobald auf den Tabellen definiert ist, dass sie In-Memory nutzen sollen, landen diese auch im Column Store Innerhalb des Column Stores gibt es 1MB große Column Units in denen die Daten abgelegt werden. Verwaltungsstruktur (Transaktionsbereich) umfasst ca. 15% des Column Stores
Wie ist der Column Store aufgebaut Jede Column Unit gehört zu einer bestimmten Tabelle (eine Tabelle belegt mehrere/viele Column Units) und enthält die Daten von aufeinanderfolgenden Daten (Rows) Die Daten werden aber nicht zeilenweise (Row) sondern spaltenweise (Column) abgelegt dabei werden diese nach der Spalte sortiert und pro CU und Spalte gibt es einen MAX und MIN Information hilft bei Queries, CUs auszulassen, die keine relevanten Daten enthalten.
Was ist der Vorteil von In-Memory gegenüber anderen Lösungen?(Marketingeinschaltung) In Memory einschalten, Tabellen In-Memory aktivieren, fertig Applikationsanpassungen: keine (außer drop Index) Funktionseinschränkungen: keine, alle Features sind unterstützt Migrationsaufwand: keiner Änderungen bei Backup/Recovery: keine
Full Database Caching Offiziell ab Oracle 12.1.0.2 Datenbank muss komplett ins Memory passen Bei FTS wird die Tabelle komplett in den Cache geladen (davor nur dann, wenn auf der Tabelle das CACHE Attribut gesetzt war) Buffer Cache LRU wird deaktiviert Einschalten: STARTUP MOUNT; ALTER DATBASE FORCE FULL DATABASE CACHING; ALTER DATABASE OPEN; SELECT force_full_db_caching FROM V$DATABASE;
Automatisches Big Table Caching Speziell bei Parallel Query / DML Oracle 11gR2 / 12.1.0.1 Full Tables Scan bei Parallel Query/DML Die Tabelle wurde mit DirectReads nur für die PQ/PX Prozesse eingelesen und landete nicht im normalen Buffer Cache mehrere Abfragen auf die gleiche Tabelle bedeutet mehrfaches Einlesen vom Storage Oracle 12.1.0.2 Instanz Parameter DB_BIG_TABLE_CACHE_PERCENT_TARGET 0 bis 90 PARALLEL_DEGREE_POLICY AUTO oder ADAPTIVE Die hottest Big Tables werden auch bei Parallel Verarbeitung ins Buffer Cache geladen, solange es sich ausgeht.
Zusammenfassung: Hauptspeicher um Latenzenzu eliminieren Einfach nur jeder Datenbank viel mehr Hauptspeicher zu geben bringt auch nichts Die Memory Advisors von Oracle helfen nicht weiter, weil diese nicht mit viel mehr Memory umgehen können. Sie betrachten nur maximal eine Verdopplung des SGA Memorys. Eine Analyse und eine Empfehlung für das Memory-Sizing dauert pro Datenbank Instanz maximal eine Stunde. Wir empfehlen aber trotzdem, die ganze Infrastruktur zu betrachten! DB Masters kann Sie bei solchen Vorhaben optimal unterstützen!
Und noch einige Überlegungen in Richtung SSD/Flash Wie passt SSD in das Bild? Die Planung der Infrastruktur ist entscheidend Storage Eigenheiten muss man verstehen Glaube keinem Benchmark, den Du nicht selbst gefälscht hast..
Wie passt SSD in das Bild? Server SSDs haben Zugriffszeiten von unter 0,01ms Intel sagt avg. Latency: 80μs andere Hersteller reden von 65μs Nutzung im Storage? Direct Attached Storage >= 0,5ms SAN/NAS Storages >= 0,6ms SSD machen in Storages durchaus Sinn 0,5ms ist verglichen mit >4ms (HDD) Faktor 8 Aber Die wirkliche Performance entfalten diese nur im Server (oder wie bei Exadata von Oracle, wenn die Verarbeitung auf dem Storage Node erfolgt) Oracle Feature: Flash Cache Erweitern des Buffer Caches mit Flash Cache im Server
spezielle SSD-only Storages Beispiel: Texas Memory Systems RamSan Serie Was ist so besonders? Hohe CPU Leistung in der Storage Optimierung für SSD Zugriff Dadurch geringere Latenzen Beispiel für Direct Attached < 150.000 IOPS Latenz < 0,3ms ~ 330.000 IOPS Latenz ~ 1ms Je nach Infrastruktur kommen noch mindestens 5-10 μs dazu
Die Planung der Infrastruktur ist entscheidend Jede aktive Infrastrukturkomponente hat Latenzen Jeder unnötige Meter Kabel addiert Latenz Die Wahl der aktiven Komponenten wirkt sich merklich aus SAN und NAS sind bei neuen Lösungen (Nexus 3548) gleich performant, mit dnfs ist man (zumindest auf der Server Seite) schneller als mit SAN Lösungen usw.
Storage Eigenheiten muss man verstehen Jedes Storage hat Eigenheiten Wo ist diese besonders gut Was wurde dem Storage aufgrund Marktdrucks angeflanscht Wie funktioniert das Storage intern Beispiel: NetApp mit WAFL FileSystem Snapshots kosten keine Performance Intelligenz in der Storage mit SW (SnapManager, Deduplizierung, ) Aber WAFL sorgt dafür, dass Files mit der Zeit immer weiter verstreut werden Full Table Scans/Backups werden zu Random I/O Aber dafür sind LGWR/DBWR I/Os meist schneller als bei anderen Herstellern (WAFL Write Eigenschaft)
Glaube keinem Benchmark, den Du nicht selbst gefälscht hast! Jeder Hersteller versucht bei Benchmarks bis zum Letzten zu optimieren in der Praxis werden Sie viel weniger Energie in die Optimierung stecken Leider gibt es keine Benchmarks mit vorgegebenen Oracle Datenbanken gegen verschiedene Storages Die verschiedenen Benchmarks spiegeln nicht das I/O Verhalten einer Datenbank wieder
Zusammenfassung Wir haben Kunden / Projekte, wo wir die Quellen für die Latenzen analysieren und wir lernen immer wieder etwas Neues Es gibt viele Details zu beachten und jeder hat seine eigene Sicht der Dinge: Infrastruktur / Netzwerk: Bei mir ist alles im grünen Bereich nur leider zeigen die Monitoring Tools nur Minuten Averages und keine Peaks Infrastruktur (meist SAN): also bei mir dauert kein I/O mehr als 2ms. Falsch: erstens ist das ein Durchschnittswert, zweitens wird auf der FC Fabric gemessen (der Weg zum Server wird nicht berücksichtigt) Storage Kollege: Die Storage Auslastung liegt unter 50% - ja, aber wie sieht es mit den I/O Queues der einzelnen Disks/Diskgruppen aus? OS Admin: Alle I/Os sind unter 5ms fertig ja, weil die I/Os, die Oracle gar nicht erst abschicken kann (max outstanding I/Os, SYNC, ), nur innerhalb der Datenbank gemessen werden