Dieses Webinar finden Sie auch auf unserem Youtube Webinar Channel.

DB Masters Webinar: CPU Performanz und deren Einfluss auf die Lizenzkosten

Gerade in herausfordernden Zeiten mit immer weiter steigenden Anforderungen bei gleichzeitigem Kostendruck wird die Wahl der richtigen CPU die vorhandene Datenbanklast immer wichtiger. In diesem Webinar erklären wir Ihnen einige dafür relevante Begriffe und gehen darauf ein, welche Kriterien für die Auswahl der passenden CPU relevant sind.

Kriterien für die Auswahl der richtigen CPU

Eines der wichtigsten Kriterien ist sicher, wie viele gleichzeitige Verarbeitungen finden statt. Was hilft mir eine CPU mit 64 Cores, wenn nur 2-3 Sessions gleichzeitig arbeiten?

Sofern man schon einen Datenbank Server hat, kann man das in der Regel sehr einfach feststellen. Man muss ich die load average der CPU über einen längeren Zeitraum (Tage/Wochen) ansehen. Bei vielen Unix/Linux Betriebssystemen ist das mittel SAR oder NMON einfach ermittelbar. Bei Windows kann man diese Informationen mittels Performance Monitor mitschreiben lassen.

Eine kurzen Überblick bietet natürlich auch die aktuelle Last am System - hier vom Linux top

top - 15:38:03 up 65 days, 6:13, 2 users, load average: 12.07, 11.22, 11.04
Tasks: 2144 total, 13 running, 2131 sleeping, 0 stopped, 0 zombie
%Cpu(s): 77.7 us, 20.8 sy, 0.1 ni, 0.0 id, 0.0 wa, 0.0 hi, 1.3 si, 0.0 st

Die load average liegt hier bei 11-12 was bedeutet, dass so viele Prozesse im Moment gerne arbeiten würden. Schaut man sich die aktuelle CPU Auslastung an, sieht man das idle (als id abgekürzt) bei 0.0 liegt. Die CPU ist somit 100% ausgelastet. In dem konkreten Beispiel liegt das daran, dass der Server nur 8 Cores hat.

Ein weiteres wichtiges Kriterium ist, wie lange die Statements laufen und ob man diese parallelisieren kann. Statements, die nur Millisekunden bis wenige Sekunden laufen, kann man nicht parallelisieren. Statements, die Minuten oder gar Stunden laufen, potentiell schon. Das würde bedeutet, dass man für die Parallelisierung auch entsprechend mehr CPU Cores benötigt. Letztendlich ist es somit die Datenbank Anwendung (OLTP versus DWH/DSS) die den CPU Core Bedarf beeinflusst.

Begriffe: Sockel, Core, Thread - was bedeutet das?

Der Prozessorsockel

Ein Prozessorsockel ist der Platz in dem man eine CPU (= Prozessor) in den Rechner einbauen kann. Verschiedene CPUs benötigen verschiedene Sockel - man kann somit nicht einfach eine beliebige CPU in einen Server einbauen. Je nach Server stehen 1, 2, 4, 8 oder noch mehr Sockel zur Verfügung, wobei jedoch Server mit 1 oder 2 Sockel preislich am interessantesten sind.

Hinweis: Für die Oracle Standard Edition 2 Lizensierung ist die Anzahl der Sockel im Server relevant. Es dürfen maximal 2 sein! Lizenz benötigt man nur für die wirklich eingebauten CPUs.

Die Prozessorkerne

Aktuelle CPUs besitzen mehrere Rechnereinheiten, die Cores. Diese Teilen sich Ressourcen wie Cache, Hauptspeicheranbindung und IO Ports.

Aktuelle Server haben zwischen 4 und 64 Cores (Stand Herbst 2020) - hier eine aktuelle Übersicht:

• Intel Xeon zwischen 4 bis 56 Cores, wahlweise mit Hyperthreading
• AMD EPIC zwischen 8 und 64 Cores, wahlweise mit 1 oder 2 Threads pro Core
• Oracle Sparc M8 hat 32 Cores, mit 8 Threads pro Core
• IBM Power 10 hat 15 Cores mit 8 Threads oder 30 Cores mit 4 Threads
• ARM CPUs sind hier nicht bewertet, weil es dafür keine Oracle Datenbank gibt.

Threads

Manche CPUs unterstützen mehrere Threads pro Core. Das bedeutet, dass mehrere Prozesse "gleichzeitig" auf einer Core verarbeitet werden können. Gleichzeitig bedeutet in Wirklichkeit "hintereinander", es laufen nicht wirklich mehrere Prozesse zum gleichen Augenblick. Das hat natürlich auch entsprechende Auswirkungen - dazu später mehr.

Je nach Hersteller gibt es für diese mehreren Threads Implementierungsunterschiede:

• Intel Xeon CPUs mit Hyperthreading
  Wenn ein Prozess auf der Core gerade auf etwas warten muss (Hauptspeicherzugriff, I/O, etc.) kann ein zweiter Prozess verarbeitet werden. In der Regel ist bekommt der zweite Prozess nur ca. 10-20% der Rechenleistung der Core, sprich die Verarbeitung dauert entsprechend länger.
• IBM Power, Oracle SPARC und AMD EPYC – Symmetrisches Multi Threading
  Die Rechenleistung der CPU Core wird in gleiche Einheiten (meist 2,4 oder 8) geteilt. Damit können entsprechend viele Prozesse "gleichzeitig" laufen, allerdings eben nicht mit der vollen CPU Core Performance, sondern nur mit einem Teil davon. Der AMD EPYC hat hier eine Sonderrolle, weil man SMT auch deaktivieren kann.
  Wenn auf einer CPU mit 8 Thread viele Prozesse laufen, so bekommt jeder Prozess potentiell auch nur 1/8 der CPU Core Rechenleitung! Das ist für Single Thread Applikationen eine massive Performanzeinschränkung, bei Parallelverarbeitungen ist das meist nicht (so) störend.

Die Auswirkung von SMT auf die Laufzeit von Statements hängt somit von der Gesamtlast am System an, hier ein Beispiel, wie wir es bei verschiedenen Systemen nachvollziehen konnten. Das Beispiel ist für eine CPU mir 32 Cores / 256 Threads - beispielsweise Sparc M8:

• Laufen nur wenige (unter 30) Verarbeitungen (load avarage) gleichzeitig, so braucht ein Statement beispielsweise eine Minute.
• Laufen hingegen ca. 60 Verarbeitungen gleichzeitig, braucht das Statement schon über zwei Minuten.
• Bei 120 gleichzeitigen Verarbeitungen dauert das Statement schon deutlich über 4 Minuten.
• Wenn über 200 gleichzeitige Verarbeitungen laufen, sind es schon über 9 Minuten.

Die nicht lineare Skalierung liegt daran, dass auch das Betriebssystem CPU Ressourcen benötigt, beispielsweise für Task Scheduling, IO, etc.

Single Thread CPU Performance innerhalb Oracle Datenbanken messen

Grundsätzlich braucht man ein einfaches Statement, dass möglichst nur einen Oracle Block im Memory angreift und damit möglichst viel macht. Einen solche CPU Performance Benchmark finden Sie hier.

Ein Auszug aus den Ergebnissen - je niedriger der Wert, um so besser:

CPUs und Oracle Lizenzkosten

Für die Auswahl der richtigen CPU sind neben der Anwendung (OLTP, DWH/DSS) und der load average auch noch weitere Faktoren relevant:

• Oracle Datenbank Edition: Enterprise (Core Lizensierung) versus Standard (Sockel Lizensierung)
• Bei EE auch noch die Oracle Processor Core Factor Table
• Bei SE2 die Limitation einer Instanz auf maximal 16 Cores.
• Die Performance pro CPU Core - siehe CPU Performance Benchmark

Rechenbeispiel

Diese Beispiel bezieht sich nur auf die CPU Performance. Andere Auswirkungen wie Storage Funktionalitäten (zb: SQL Offloading) werden hier nicht berücksichtigt und sind bei Statements mit kurzer Laufzeit auch nicht relevant.

Wenn Sie aktuell eine aktuelle Oracle Exadata oder ein beliebiges Cloud Service (Oracle, Amazon, Microsoft, Google,...) nutzen und dort einen load avarage von 20 aufweisen. Wie könnte man hier die benötigten Oracle Lizenzkosten reduzieren? Dabei ist es natürlich wichtig, dass die Verarbeitung nicht langsamer werden darf und eine ausreichende Anzahl von Cores/Threads zur Verfügung steht. Gegebene Falles ist auch noch die zuvor erwähnte Oracle Processor Core Factor Table relevant.

Wählen wir einmal einen Intel Xeon Gold 6244 mit 8 Cores @ 3.6GHz und prüfen wir, ob dieser ausreichend wäre.

• Oracle Exadata/oder Cloud Anbieter, schaffen den CPU Benchmark in ca. 7,3 bis 8 Sekunden
• Die Intel Xeon Gold 6244 benötigt jedoch nur 2,8 Sekunden --> die Single Thread Performance ist also ca. 2.6 mal so hoch ( 7,3 : 2,8 = 2,6)
• Wenn jetzt ein Core 2,6 mal so schnell ist, schaffen 8 Cores also ( 8 * 2,6 = 20,8) gleich viel zu berechnen wie die Exadata/Cloud Anbieter bei einem load average von 20. Man braucht aber deutlich weniger Oracle Enterprise Edition Lizenzen dafür. Da die CPU auch noch Hyperthreading beherrscht, könne auch bis zu 16 Prozesse "gleichzeitig" laufen.

Eine alternative Art die Rechenleistung grob zu vergleichen, sofern man aktuelle CPUs des gleichen Herstellers vergleicht, wäre das Produkt aus Cores mal Taktrate. Das Beispiel dazu:

• Oracle Exadata X8M-2 CPU: Intel Xeon 8260 24 Cores @ 2.4GHz = 1 CPU * 24 Cores * 2.4GHz = 57,6GHz
• zwei Intel Xeon Gold 6250 Processor 8 Cores @ 3.9GHz = 2 CPUs * 8 Cores * 3,9GHz = 62,4GHz

Damit erreicht man eine deutlich höhere Rechenleistung mit 16 Cores als die 24 Core CPU der Exadata bietet und kann gleichzeitig 1/3 der Oracle Lizenzkosten einsparen!

Zusammenfassung

CPU Performance ist nicht alles. Natürlich spielen auch der Hauptspeicher und die Storage eine große Rolle – aber es hat direkten Einfluss auf die Oracle Lizenzkosten. Neben der reinen Single Thread CPU Performance, die vor allem bei OLTP Applikationen relevant ist, spielen aber noch andere Faktoren eine Rolle:

• Parallelisierbarkeit der Abfrage – hier braucht man viele Threads
• Anzahl der „gleichzeitigen“ Verarbeitungen

Interesse an diesem Webinar geweckt?

Dann schauen Sie es sich doch direkt auf unserem Youtube Channel an: DB Masters Webinar: CPU Performance und deren Einfluss auf die Lizenzkosten.

Vergessen Sie nicht unseren Youtube Channel zu abonnieren, damit Sie keines unserer Videos verpassen!