Dieser Blog-Artikel ist auch als DOAG Datenbank Kolumne verfügbar.
In vielen Performance-Optimierungsprojekten gibt es Diskussionen über die Wahl der passenden CPU für den jeweiligen Anwendungszweck. Auch die unterschiedlichen Anforderungen von DBAs und Server Administratoren wollen unter einen Hut gebracht werden.
Oracle Datenbankenanwendungen kann man grob in zwei Kategorien einteilen:
OLTP – Online Transaction Processing
Diese Anwendungen zeichnen sich durch sehr viele, aber eher kurzlaufende Statements aus. Die Single Thread SQL Performance ist – neben dem Hauptspeicher und der Storage-Performance – das wichtigste Kriterium. In unserem Artikel CPU Performance Benchmark unter https://www.dbmasters.at/db/masters/artikel/oracle-datenbank-single-thread-cpu-performance-benchmark haben wir einen einfachen SQL Performance Benchmark zur Verfügung gestellt und sammeln die Ergebnisse von verschiedenen Oracle Versionen und CPUs. Natürlich ist dieser einfache Benchmark unvollkommen, weil er lediglich ein Kreuzprodukt erzeugt. Viele OLTP SQL Statements sind ebenfalls relativ trivial. Daher ist es eine grobe Näherung, um eine Vergleichsmöglichkeit zu haben. Es wird hier ausschließlich die SQL Verarbeitungsgeschwindigkeit der CPU gemessen.
DWH/DSS/Reporing – Data Warehouse, Decision Support und Reporting
Diese zeichnen sich durch Massendatenverarbeitung (Ladejobs) und langlaufende Abfragen aus. In vielen Fällen besteht die Möglichkeit, diese Verarbeitungen zu parallelisieren (Oracle Enterprise Edition und eventuell weitere Optionen wie Partitioning bzw. In-Memory Option). Wenn man Parallelisierung nutzen kann, ist es oft vorteilhafter, viele CPU Cores gleichzeitig beanspruchen zu können. Die Single Thread Performance ist in diesem Fall meist nicht so kritisch, weil in der Regel die Datenanlieferung durch die Storage Lösung den Engpass darstellt.
Neben den beiden Datenbank-Kategorien sind die verschiedenen CPU-Typen ebenfalls ausschlaggebend. Dazu muss man sich mit verschiedenen Begriffen auseinander setzen.
Sockel, Core, Thread und Taktrate
CPUs stecken in sogenannten Sockeln auf dem Mainboard (oder sind bei Notebooks direkt aufgelötet). Je nach Hersteller gibt es in Servern einen, zwei, vier oder acht (selten mehr) CPU-Sockel, wobei bei Commodity Servern in der Regel zwei CPU-Sockel vorhanden sind. Die Sockel sind beispielsweise für die Oracle Standard Edition Lizenzierung relevant, da diese per Sockel erfolgt.
Die CPUs selbst verfügen über eine Reihe von unabhängigen Prozessorkernen (Cores), die jeweils einen Prozess verarbeiten können. Wenn eine CPU also 8 Cores hat, können bis zu acht Prozesse gleichzeitig laufen, ohne sich gegenseitig zu beeinflussen. Aktuelle CPUs haben zwischen vier und über 100 Cores.
Einige CPU-Hersteller teilen diese Prozessorkerne fix oder virtuell weiter auf und nennen diese dann Threads. Wenn Hersteller beispielsweise acht Threads pro Core anbietet, bedeutet das, dass entweder ein Prozess die ganze Zeit laufen kann oder dass bis zu acht Prozesse „gleichzeitig“ (in Wirklichkeit nacheinander) dran kommen. Damit hängt aber die CPU-Leistung, die ein Prozess nutzen kann, stark von der Anzahl der gleichzeitig laufenden Prozesse ab. Läuft ein Prozess alleine auf einem Core, kann er die gesamte Rechenleistung abrufen. Muss sich ein Prozess den Core mit anderen Prozessen teilen, steht jedem Prozess „worst case“ nur 1/8 der CPU-Performance zur Verfügung. Für OLTP Anwendungen ist das oft ein massives Problem, da die Laufzeiten um den Faktor acht bis zehn schwanken können, je nachdem wie viele Verarbeitungen gleichzeitig erfolgen. Im Bereich von DWH/DSS/Reporting ist die Auswirkung meist geringer, da hier die I/O-waits auf die Storage dafür sorgen, dass die Verarbeitung pausieren muss.
Neben Sockel, Core und Thread ist auch die CPU-Taktrate relevant. Moderne CPUs laufen im Bereich von einigen GHz Taktfrequenz. Diese ist in der Regel nicht fix, sondern passt sich dynamisch an die aktuelle Last an. Laufen nur wenige Prozesse, kann die CPU den Takt der entsprechenden Cores erhöhen. Sind viele Prozesse aktiv, wird der Takt entsprechend reduziert. Auch das kann zu unterschiedlichen Laufzeiten führen, allerdings typischerweise im Bereich von 15 bis 25% und somit deutlich geringer als bei Threads.
Die aktuellen CPUs sind hier wie folgt zu klassifizieren:
Intel Based CPUs mit Hyperthreading
Unter Hyperthreading versteht Intel, dass virtuell zwei Prozesse in einem Core laufen. Diese sind jedoch nicht gleichberechtigt! Ein Prozess ist der Hauptprozess und bekommt soviel von der CPU Leistung, wie er benötigt. Der zweite Prozess kann somit nur dann laufen, wenn der erste Prozess gerade auf etwas wartet (I/O,…). Gerade bei kurzlaufenden SQL Verarbeitungen kann dies dazu führen, dass diese einmal sofort fertig sind und dann wieder zehnmal länger benötigen – je nachdem, ob es sich um den Hauptprozess oder den zweiten Prozess auf einer Core handelt. Aus diesem Grund sollte man Hyperthreading deaktivieren, wenn man OLTP Applikationen nutzt. Im DWH/DSS Bereich, wenn man Parallelisierung nutzt, kann Hyperthreading 10 bis 25% mehr Durchsatz bieten.
IBM Power, Oracle Sparc, AMD Epyc mit SMT – Symmetrisches Multi Threading
Hier werden die Cores in (teilweise einstellbare) Anzahl von Threads geteilt. Im Fall von AMD Epyc kann man SMT auch komplett deaktivieren, was für den Einsatz im OLTP Bereich sinnvoll ist. Bei IBM Power kann man den SMT Wert einstellen, wobei der Default SMT8 (also acht Threads/Cores) ist. Möglich sind auch vier, zwei und ein. Siehe auch IBM AIX on Power10 Performance Topics https://www.ibm.com/downloads/cas/6YOG7OMV. Oracle hat die Sparc CPUs inzwischen eingestellt. Diese haben acht Threads/Cores unterstützt.
ARM CPUs
Seit kurzem unterstützt Oracle auch ARM CPUs (unter Linux). Bei ARM CPUs gibt es keine Threads. Allerdings werden bei ARM CPUs oft unterschiedliche Core-Typen in einer CPU angeboten – was seit kurzem auch bei Intel und AMD CPUs Einzug findet. Diese verschiedenen CPU-Cores unterscheiden sich einerseits durch den maximalen CPU-Takt und andererseits durch den Funktionsumfang. Für die SQL Verarbeitung ist in den meisten Fällen nur der CPU-Takt relevant (ausgenommen bei Oracle In-Memory, AI sowie Bloom Filtern oder ähnlichem). In Servern werden in den meisten Fällen aber Cores mit vom gleichen Typ genutzt, lediglich bei Notebooks macht es einen merklichen Unterschied.
Ein weiterer Faktor, den man nicht außer acht lassen darf, sind die Oracle Lizenzkosten. Bei der Oracle Datenbank Standard Edition muss man lediglich die CPU-Sockel lizenzieren, wobei Oracle die Anzahl der gleichzeitig nutzbaren Cores limitiert. Wenn man mehrere Datenbanken auf einem Server betreibt, kann man aber immer alle Cores der CPU nutzen. Bei der Oracle Enterprise Edition ist es viel komplexer.
Neben der wirklichen Rechenleistung spielen hier noch weitere Kriterien mit:
Der CPU-Core-Faktor gibt an, mit welcher Zahl die Cores zu multiplizieren sind. Dieser Faktor reicht von 0.25 für einige Oracle Sparc sowie die aktuellem Ampere (ARM) CPUs über 0.5 und 0.75 bis hin zu 1. Da die Oracle Lizenzkosten einen beträchtlichen Teil der Projektkosten ausmachen, sind diese CPU-Core-Faktoren nicht zu unterschätzen. Aktuelle Intel XEON und AMD EPYC CPUs weisen einen Faktor von 0.5 auf. ARM (ausgenommen Ampere CPUs) und Power-CPUs hingegen einen Faktor von 1.
Zusätzlich darf man die Regeln für Datenbank in der Cloud nicht außer Acht lassen, da Oracle die anderen großen Cloudanbieter bei der CPU-Faktorberechnung benachteiligt. Da alle Cloudanbieter auf CPUs mit vielen Cores (und damit geringer Taktrate) setzen, wirkt sich das zusätzlich negativ auf die Performance und die Gesamtkosten aus.
Je nach Anwendung (OLTP, DWH/DSS/Reporing) und benötigter Core-Anzahl gibt es somit verschiedene mögliche Umsetzungen. Für OLTP sind in der Regel CPUs mit hoher Taktrate, geringer Core Anzahl und niedrigem CPU-Core-Faktor relevant. Im DWH/DSS/Reporting-Umfeld wird man eher CPUs mit vielen Cores bzw. Threads bevorzugen, wobei auch hier der CPU-Core-Faktor nicht zu vernachlässigen sei.
Ein kleines Beispiel von aktuellen CPUs (von den Ergebnissen unseres CPU-Performance-Benchmarks):
- Intel Xeon E-2386G, 6 Cores @ 3.5 Ghz im Turbo auf 5.1Ghz: 1,7 Sekunden
- AMD EPYC 9174F 16-Core Processor @ 4.1GHz mit Turbo bis zu 4.4GHz: 2,1 Sekunden
- Intel Xeon Gold 6346, 16 Core @ 3.1GHz mit Turbo bis zu 3.6GHz: 2,5 Sekunden
- Oracle SPARC-M8 5.0 GHz (Single Thread): 4 Sekunden
- IBM Power9 mit 3,4GHz LPAR mit 4.0 Ent. Cap. , 4 virt. CPUs SMT2 8 Log. CPUs: 5,4 Sekunden
- Oracle Cloud: autonomous database, Okt 2019: 7,3 Sekunden
Geringere Laufzeit ist besser! So schafft ein Intel Xeon E-2386G Core locker die dreifache Last im Vergleich mit einer IBM Power9 Core. Gemeinsam mit dem unterschiedlichen Oracle-Core-Faktor ergibt sich somit die sechsfache SQL-Performance bei gleichen Lizenzkosten!
Im nächsten Artikel dieser Serie wird das Thema Hauptspeicher behandelt.
Stay tuned!