Benchmark: MySQL 5.5 Hyper Threading Performance

November 14th, 2012

Hintergrund dieses damaligen Benchmarks war der Fakt, dass zwei neue eigentlich identisch ausgelegte Server deutlich unterschiedliche Ergebnisse beim gleichen MySQL Benchmark Test lieferten.
Nach kurzem Suchen, fiel uns doch ein Unterschied auf: Auf einem Server war Intel Hyper Threading aktiviert, auf dem anderen nicht.
Normalerweise war auf all unseren Datenbankservern Hyper Threading deaktiviert. Nach kurzem Suchen im Netz fand ich folgenden Blog-Eintrag, in dem ein Benchmark-Ergebnis beschrieben wurde, bei die MySQL-Instanz mit aktiviertem Intel Hyper Threading bessere Ergebnisse lieferte als mit deaktiviertem Hyper Threading. Aus diesem Grund starteten wir zwei Benchmark-Test-Läufe um ein eigenes Bild zu machen.

Die Ausgangssituation:
Hardware:

Server: HP DL380 G7
2 x Intel® Xeon® Processor X5660 (6 Core) 2,8 GHz
56 GB RAM (DDR3-1333/PC3-10600)
HP QLogic Dual 8 GB FC-HBA
3 x HP 146GB 6G SAS 10K (Raid 1 + Hot Spare)

SAN:
2 x Qlogic Sanbox 5800 (Multipathing)

Storage:
1 x Netapp FAS3240 FAS3240 with Expanded I/O
24 x 600 GB SAS HDD (2 Hot Spares)

Benchmark hardware

Benchmark Hardware Setup

Software:

Red Hat Enterprise Linux 6.1 (64 Bit)
MySQL 5.5.17 Community Edition (x86_64) RPM-Paket

MySQL 5.5 Konfiguration (auszugsweise)

Der Test:
Als Benchmark-Werkzeug kam wie immer der OLTP-Test von sysbench zum Einsatz. Der OLTP Test wurde jeweils mit aktivierten/deaktivierten Intel Hyper Threading im SIMPLE- als auch einmal im COMPLEX-Mode ausgeführt. Bei jedem Durchlauf wurden dabei folgende Schritte ausgeführt:

1. Anlegen einer Tabelle mit 6000000 Einträgen, was einer Datenmenge von 1,4 GB entspricht
2. Simple/Complex-OLTP-Benchmark mit $num_threads ausführen, wobei $num_threads für die Anzahl der gleichzeitigen Threads steht.
3. Nach jedem Durchlauf wird die Tabelle gelöscht und $num_threads um 25 Threads erhöht.

Das sieht dann wie folgt aus:

Das Testergebnis:
Nachdem der Benchmark-Lauf für den SIMPLE-OLTP-Test abgeschlossen hatten, erhielten wir folgende Ergebnisse:

Benchmark MySQL 5.5 HT OLTP Simple Results

Benchmark MySQL 5.5 HT OLTP Simple Results


Beim SIMPLE-OLTP-Test schnitt somit die MySQL Instanz mit aktviertem Intel Hyper Threading deutlich schlechter ab, als die Instanz ohne Intel Hyper Threading. Im schlechtesten Fall wurden ~7300 Transaktionen, im besten Fall ~3400 weniger durchgesetzt. Grafisch aufbereitet, stellt sich dies wie folgt dar:
Benchmark MySQL 5.5 HT OLTP Simple Graph

Benchmark MySQL 5.5 HT OLTP Simple Graph

Für den COMPLEX-OLTP-Test erhielten wir etwas andere Ergebnisse:

Benchmark MySQL 5.5 HT OLTP Complex Results

Benchmark MySQL 5.5 HT OLTP Complex Results

In der Tat konnte hier MySQL 5.5 mit Hyper Threading punkten und setzte im Schnitt 41 Transkaktionen/s mehr durch. Gerade bei einer geringen Anzahl gleichzeitiger Threads (1-100) konnte eine Steigerung um ~68% bis ~29% erreicht werden. Der dazugehörige Graph sieht wie folgt aus:

Benchmark MySQL 5.5 HT OLTP Complex Graph

Benchmark MySQL 5.5 HT OLTP Complex Graph


Fazit:
Es ist schwer anhand dieser Testergebnisse eine generelle Empfehlung zu geben, ob man Intel Hyper Threading für einen dedizierten MySQL 5.5 Server aktivieren oder deaktivieren sollte.
Generell tendiere ich ja noch immer zum Deaktivieren, da ja die typischen MySQL-Web-Anwendungen mit vielen parallelen Threads und meist “simpleren” SQL-Statements arbeiten. Unter Umständen lohnt sich aber auch das Aktivieren von Intel Hyper Threading, gerade bei einer geringenen Thread-Anzahl, wie zum Beispiel der skriptbasierten Verarbeitung von Massendaten mit komplexen SQL-Statements.

Wie immer interessieren mich Eure Erfahrungen/Anmerkungen zu diesem Thema.

Gelesen: Effective MySQL – Backup and Recovery

October 10th, 2012

Seit langem kam ich mal wieder dazu ein Buch von dem Stapel “Ungelesen” zu nehmen und auf den Stapel “Gelesen” abzulegen. Dabei handelte es sich um das Buch “Backup and Recovery” von Ronald Bradford aus der “Effective MySQL” Serie. Und was soll ich sagen? Klasse Buch!!! Jeder der ein Buch zu diesem Thema sucht, sei dies ans Herz gelegt. Klare Empfehlung!

Hier noch kurz die Fakten:

Titel:Effective MySQL: Backup and Recovery
Autor:Ronald Bradford
Sprache:Englisch
Seiten232
ISBN:978-0071788571
Persönliche Wertung:9 von 10 Punkte
Preis:circa 17-20 €

Workshop: Sybase ASE Errorlog rotieren – Teil 1

October 6th, 2012

Das Errorlog des Sybase Adaptive Server Enterprise (ASE) enthält alle wichtigen Informationen des Datenbank-Servers. Dies beinhaltet alle Startup-Meldungen, Tuning-Hinweise und System-Warnungen, sowie Laufzeitfehler, Stacktraces und individuelle Ausgaben. Somit ist es nicht verwunderlich, dass die Logdatei mit der Zeit wächst und gerade bei eingeschalteten Trace-Levels schnell mehrere 100 MB oder sogar einige GB groß werden kann.
In diesem Workshop soll gezeigt werden, wie das ASE Errorlog im laufenden Betrieb rotiert werden kann.

Als Erstes muss ermittelt werden, wo sich das aktuelle ASE Errorlog befindet. Standardmäßig befindet sich unter: $SYBASE/ASE-15_0/install/SERVERNAME.log
Um sicher zu gehen kann man dies aber auch in einer isql-Session auslesen. Dafür sollte man sich mit dem Benutzer ‘sa’ an der Datenbank anmelden:

“CORRINO” steht hier für den ASE-Servernamen und ist entsprechend anzupassen.
Danach kann man die Variable @@errorlog auslesen. Sie beinhaltet den kompletten Pfad zum ASE Errorlog.

Der ASE bietet derzeit keinen direkten Befehl zum Rotieren des Errorlogs, dafür aber die Stored Procedure “sp_errorlog” zum dynamischen Ändern des Pfades. Die Syntax ist wie folgt:

sp_errorlog “change log“, “new_path“ [,{“jslog true“ | “jslog false“}]

– “new_path” gibt den neuen Pfad zum Errorlog an
– “jslog true“ | “jslog false“ gibt an, ob der Log des Jobscheduler ebenso angepasst werden soll.

Damit haben wir schon alles, was wir zum Rotieren des Errorlogs benötigen. Wir gehen nun wie folgt vor:

1. Das Errorlog auf ein temporäres Log umstellen. (Dabei ist zu beachten, dass der Betriebssystem-Benutzer, unter dem der ASE läuft, Schreibberechtigung in dem Verzeichnis hat.) Man führt nun im isql folgenden Befehl aus:

2. Kontrolle des Dateisystems und der temporären ASE Errorlog Datei:

3. Umbenennen und zippen der alten Errorlog Datei:

4. Ändern des Errorlog-Pfades auf den ursprünglichen Wert:

5. Kontrollieren des Dateisystems und der neuen Errorlog-Datei:

6. Löschen der temporären Errorlog-Datei:

Fazit: Das ASE Errorlog wurde nun rotiert und gezippt ohne den ASE neu zu starten. Das ganze lässt sich sicher auch gut skripten und mit Betriebssystem-Mitteln wie logrote oder cron kombinieren.

Mehr Informationen zur Stored Procedure “sp_errorlog” findet man im Sybase Infocenter.

Nachtrag: Verwendet man die Stored Procedure sp_errorlog um den Pfad der Errorlog Datei generell umzustellen, muss man anschließend die RUNSERVER Datei anpassen, in der Pfad zum ASE Errorlog vermerkt ist. Ansonsten wird der ASE nicht wieder starten! In diesem POST wurde diese Anpassung nicht vorgenommen, da wir nur temporär auf ein neues Errorlog umgestellt und anschließend wieder den originalen Pfad verwendet haben.