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 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)
... # InnoDB Section innodb_file_per_table innodb_buffer_pool_size = 4G innodb_buffer_pool_instances = 2 innodb_additional_mem_pool_size = 32M innodb_log_file_size = 256M innodb_log_buffer_size = 64M innodb_flush_log_at_trx_commit = 1 innodb_lock_wait_timeout = 50 innodb_open_files = 1024 innodb_file_format = Barracuda innodb_flush_method = O_DIRECT innodb_read_io_threads = 8 innodb_write_io_threads = 8 innodb_io_capacity = 500 innodb_max_dirty_pages_pct = 60 innodb_purge_threads = 1
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:
# create table sysbench --test=oltp --db-driver=mysql --oltp-table-size=6000000 --mysql-user=root prepare # run Benchmark sysbench --num-threads=$num_threads --max-requests=30000 --test=oltp --db-driver=mysql --mysql-user=root --oltp-test-mode=complex/simple run # drop table $SYSBENCH --test=oltp --db-driver=mysql --mysql-user=root cleanup
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
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
Für den COMPLEX-OLTP-Test erhielten wir etwas andere Ergebnisse:
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
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.