CPU-Leistungsvergleiche mit der Hammer DB

Überblick

Einer unserer Kunden hatte ein unerwartetes Ergebnis: Im Rahmen der Migration einer MSSQL Instanz von Version 2019 nach 2022 hatte er neue Hardware angeschafft, insbesondere auch neue CPUs und hatte in anschließenden Performancebetrachtungen eine deutliche Verlangsamung seiner Datenbankzugriffe festgestellt. Dies hatte ihn veranlasst, bei uns ein SQL Server Assessment  zu buchen und es kam die Frage auf, ob es sein könne, dass MSSQL Version 2022 sehr viel langsamer sei als die Vorgängerversion.

Das Assessment lieferte zwar, wie von uns erwartet, einiges an Optimierungspotential, aber bei der Migration hatte sich ja an den Datenbankeinstellungen und -inhalten nichts geändert. Insbesondere war der Storage - ebenfalls ein Ergebnis des Assessments - in der neuen Umgebung rasend schnell, so dass hier eine deutliche Steigerung zu erwarten gewesen wäre. Als Verursacher für den Performance-Einbruch wurden schließlich die CPUs identifiziert.

Dies hat uns veranlasst, diesen Beitrag zu schreiben und den Umgang mit der HammerDB zu zeigen. Wir haben die zum Zeitpunkt der Erstellung dieses Beitrags neueste Version 4.12 verwendet.

Wir stellen hier beispielhaft den Durchsatz dreier CPU-Typen bzw. Server dar.

Die HammerDB

Die HammerDB, ist ein Tool, das man unter GitHub HammerDB herunterladen und mit dem man den Durchsatz verschiedener Datenbanken testen kann. Unter GitHub beschreiben die Entwickler ihr Tool folgendermaßen:

“HammerDB is the leading benchmarking and load testing software for the worlds most popular databases supporting Oracle Database, Microsoft SQL Server, IBM Db2, PostgreSQL, MySQL and MariaDB.“

Unter anderem lässt sich dieses Tool auch dazu verwenden, die Performance der Datenbanken dieser DB-Produkte miteinander zu vergleichen, indem eine große Anzahl fiktiver Bestellprozesse in einer vorkonfigurierten Datenbank ausgeführt wird. Das Ergebnis derartiger Testdurchläufe sind zwei Metriken, nämlich

1. NOPM - Number of Orders per Minute
2. TPM - Transactions per Minute

Hierbei sollte beim Vergleich unterschiedlicher DB-Produkte miteinander wegen des unterschiedlichen Transaktionsverhaltens die Metrik NOPM verwendet werden.

Bevor Sie aber die HammerDB verwenden, um beispielsweise die Leistung Ihrer CPUs miteinander zu vergleichen, berücksichtigen Sie bitte, dass alle anderen Parameter, wie Geschwindigkeit des Storage oder Bandbreite der Verbindung zur Datenbank, für alle Vergleichskandidaten gleich sein müssen.

Verwendete MSSQL Version

Zur Durchführung der Tests wurde Microsoft SQL Server 2022 (RTM-CU16) (KB5048033) - 16.0.4165.4 (X64)   Nov  6 2024 19:24:49 verwendet.

Initialisierung

Es wurde das Benchmark-Verfahren für hohe Transaktionslast, HammerDB Bezeichnung “TPROC-C”, verwendet. In einem ersten Schritt muss eine leere Zieldatenbank angelegt werden, in der die HammerDB die für den Test verwendeten Tabellen

1. customer
2. district
3. history
4. item
5. new_order
6. order_line
7. orders
8. stock
9. warehouse

anlegt und mit initialen Daten befüllt. Hierzu sollte die Datenbank zunächst im Simple Recovery Modus betrieben werden. Die Dateigrößen sollten hier auch bereits ausreichend dimensioniert sein, um ein permanentes Anwachsen der Files zu vermeiden. In unserem Fall wurden initial 15 GB für die Datendatei und 5 GB für das Transaktionslog angelegt.

Anschließend gibt man in der GUI der HammerDB unter dem Menüpunkt Schema ==> Option die Verbindungsdaten zu dieser neuen Datenbank und die Anzahl der gewünschten virtuellen User und der Anzahl gewünschter zu simulierender Warenhäuser an. Als virtuelle Useranzahl sollte die Anzahl der verfügbaren CPU-Kerne gewählt werden, als Anzahl der Warenhäuser etwa der zehnfache Wert der vorhandenen CPUs. Dieser Vorschlag beruht darauf, dass sichergestellt ist, dass alle CPUs ausgelastet werden. In den hier durchgeführten Tests haben wir, mit Ausnahme des Laptop, jeweils 10 User und 80 Warehouses verwendet.

Durch Doppelklick der Schaltfläche Schema ==> Build werden die o.a. neun Tabellen angelegt und mit initialen Daten gefüllt.

Bevor nun der eigentliche Test gestartet wird, müssen die im vorherigen Schritt angelegten virtuellen User gelöscht, die Datenbank in den Full Recovery Modus gebracht und eine Datensicherung durchgeführt werden. Dies ist Voraussetzung dafür, dass der Umschaltvorgang Simple ==> Full Recovery Modus aktiviert wird.

Microsoft ODBC Driver 18 für SQL Server

Das HammerDB-Tool benötigt zur Verbindung mit einer MSSQL Datenbank den ODBC Treiber 18 für SQL Server der unter dem hier angegebenen Link heruntergeladen werden kann.

Testdurchführung

Nach erfolgter Datensicherung und im jetzt aktivierten Full Recovery Modus wird das Treiber-Script eingerichtet. Das Treiberskript führt die DML-Operationen in der Datenbank aus. Es wird konfiguriert durch die Informationen zur Datenbankverbindung und eine gewünschte Zeitspanne, während der die Transaktionen laufen sollen.  Wir haben 20 Minuten gewählt. Durch einen Doppelklick auf den Knoten Driver Script ==> Load wird das Treiberscript aktiviert (aber noch nicht gestartet). Anschließend wird eine Anzahl virtueller User spezifiziert. Die Empfehlung ist hier, pro CPU-Kern einen User zu verwenden.  Abschließend wird nun das Treiber-Skript für die gewünschten virtuellen User ausgeführt und hierdurch der Test für die vorgegebene Zeitdauer gestartet. Dabei sollten in den “Virtual User Options” die beiden Punkte “Show Output” und Log Output to Temp” aktiviert werden, so dass die gewünschten Leistungsdaten NOPM und TPM in einer Datei erfasst werden. Sofern Sie mehrere Testreihen planen, sollten Sie auch die Option “Use Unique Log Name“ aktivieren, so dass jeder Testlauf in einer separaten Log-Datei protokolliert wird.

Testergebnis

Wir haben drei Testkandidaten gewählt die direkt miteinander verglichen wurden und einen vierten außer der Reihe wegen vollkommen abweichender Parameter, nämlich einen Laptop mit mehr CPUs, uneingeschränktem 64 GB Hauptspeicher, aber geringerer CPU-Leistung:

‍

Grundsätzlicher Vergleich von Xeon Silber und Xeon Gold Prozessoren

Grundsätzlich sollte für die Verwendung in einem Server, der für den Betrieb einer SQL Server Datenbank vorgesehen ist und an den hohe Performanceanforderungen gestellt werden, eher zu dem Xeon Gold Prozessor gegriffen werden. Hier lässt sich i.d.R. mehr Leistung mit weniger Kernen erreichen. Damit sind die einmaligen Anschaffungskosten zwar höher, aber die regelmäßigen Lizenzkosten niedriger. Gründe für die höhere Leistungsfähigkeit sind

• Gold-Prozessoren verfügen über eine höhere Taktfrequenz und einen höheren maximalen Turbo-Takt
• Gold-Prozesoren verfügen über einen größeren L3-Cache der gegenüber dem “normalen” Arbeitsspeicher eine höhere Geschwindigkeit hat
• Gold-Prozessoren verfügen i.d.R. über höhere Speicherfrequenzen und mehr Speicherkanäle
• Sofern es sich um eine virtualisierte Umgebung handelt, bieten Gold-Prozessoren hierzu leistungsfähigere Features zu deren Unterstützung
• Gold-Prozessoren verfügen über erweiterte AVX-Instruktionen, die in datenintensiven Berechnungen (z. B. Analytik oder Data Warehousing) eine erhebliche Leistungssteigerung bieten.
• Die i.d.R. höhere Anzahl von NUMA-Knoten führt zu einer höheren Leistung bei der Parallelverarbeitung

Weiterhin sollte bei der Wahl des Prozessors auch die Prozessorgeneration berücksichtigt werden: Auch hier gilt: Neuere Generationen sind erheblich leistungsfähiger als ältere, erfordern höhere Kosten bei der Anschaffung, die aber i.d.R. durch eine geringere Anforderung an die Anzahl der benötigten Kerne zu geringeren laufenden Betriebskosten durch Lizenzgebühren führen. Im Fall des Laptop sehen wir, dass trotz einer relativ hohen Anzahl von CPUs, einer mittleren I/O-Zeit und einer gegenüber den ersten beiden getesten CPUs  

Fazit

Die Wahl der passenden Prozessoren für den Betrieb von SQL Server Datenbanken ist ein komplexes Thema und ist im Wesentlichen von den Anforderungen an die Performance der Datenbank aber auch von den Anschaffungs- und laufenden Kosten beeinflusst. Direkte Vergleichsmöglichkeiten verschiedener Systeme mit, abgesehen von den unterschiedlichen CPU-Typen, vollkommen identischen Parametern sind oft nicht vorhanden. Als Hilfsmittel zum Vergleich der Performance unterschiedlicher Server kann in solchen Fällen die HammerDB eingesetzt werden.

Wenn Sie mehr zu diesem Thema erfahren möchten, stehen Ihnen unsere Experten gerne zur Verfügung. Vereinbaren Sie unverbindlich ein Beratungsgespräch über unser Kontaktformular. Wir unterstützen Sie gerne!

‍