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 …

Das MySQL 5.5 auf Servern mit vielen CPU-Cores mehr Transaktionen als MySQL 5.1 durchsetzt, kann man vielen Benchmarks im Internet entnehmen. Allerdings werden bei diesem Benchmarks meist Server mit 32, 48 oder sogar 64 CPU-Cores eingesetzt, die nur in großen und sehr großen Unternehmen Verwendung finden. In kleinen und mittelständigen Unternehmen werden aber im Normalfall eher Single- oder Dual-CPU-Sockel Server verwendet, die mit 4-16 CPU-Cores aufwarten können. Welchen Leistungszuwachs kann bei dieser Server-Klasse erwartet werden? Diese Frage soll der folgende Benchmark klären.

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)

Um die Leistung des MySQL-Clusters besser einschätzen zu können, haben wir einige Tests und Versuche unternommen. Die Ergebnisse haben mich so beindruckt, dass ich das Benchmark-Szenario gerne zeigen möchte.

Die Ausgangssituation:
Hardware:
4 Daten-Knoten:
SunFire X4140 Server
2 x AMD 2.6 GHz CPU, Opteron 2435 6-Core
32 GB DDR2 ECC registered RAM (667 MHz)
4 x HDD 146 GB SAS 1000rpm (RAID 10)
4 x Gigabit Netzwerk

2 SQL-Knoten:
SunFire X4140 Server
1 x AMD 2.6 GHz CPU, Opteron 2435 6-Core
8 GB DDR2 ECC registered RAM (667 MHz)
4 x HDD 146 GB SAS 1000rpm (RAID 10)
4 x Gigabit Netzwerk

2 Management-Knoten:
SunFire X2200 M2
1 x 3.0 GHz AMD Dual-Core Opteron Model 2222
4 GB DDR2 ECC registered RAM (667 MHz)
2 x HDD 250 GB SATA 7200rpm (RAID 1)
4 x Gigabit Netzwerk

…

Sun hat eine Box, die hat 4 CPU-Chips drin, jeder Chip hat 8 Cores und jeder Core hat 8 Threads, die in etwa das sind, was man anderswo als Core abrechnet, minus 7/8 FPU. Das macht effektiv eine Kiste in mit 256 Cores.

Jeder Core Thread selbst ist im Vergleich zu Intel-Hardware jedoch recht langsam, er bringt etwa ein Drittel bis ein Fünftel der Leistung eines Intel-Cores, außer in Benchmarks, wo die Dinger viel schicker poliert werden. Dennoch ist das wegen der großen Anzahl der Threads eine ganze Menge Bumms in einer kleinen Box mit ohne viel Strom.

Sun hat nun auch eine recht populäre Open Source Datenbank von der Sun es gerne hätte, wenn die auf so einem …

Ich habe ein wenig mit iozone gespielt. Erstes Opfer war eine NetApp FAS3040 with 4096MB RAM and 512MB NVRAM. Angeschlossen waren 14 Disks mit 10k RPM, mit 4Gbit Fibre Channel auf device-mapper-multipath so, daß die beiden primary Paths das I/O machen und die beiden sekundären Pfade im wesentlichen Idle bleiben.

Gefahren hab ich gegen das Ding ein iozone und zwar

• iozone -f iozonefile -o -O -i0 -i2 -s4g -r16k
• iozone -T -t 8 -F iozonefile{0..7} -o -O -i0 -i2 -s1g -r16k
• iozone -T -t 32 -F iozonefile{0..31} -o -O -i0 -i2 -s512m -r16k

und das wiederum gegen ein ext3 und gegen ein xfs.
"Ein paar Benchmarks zum kalibrieren" vollständig lesen

Ein MSA-30 Array mit 14 Platten. Liebes Tagebuch!

Heute bin ich gegen eine HP 585 und zwei MSA 30 angetreten und ich bin mir nicht ganz sicher, wer gewonnen hat. Aber laß mich von vorne erzählen.

Wie Du weißt, liebes Tagebuch, berechnet sich die Anzahl der Zugriffe, die man von einer einzelnen Platte pro Sekunde erwarten kann, wie folgt: 1000ms/(Average Seek Time in ms + Rotational Delay in ms + Transfer Time in ms). Die Average Seek Time kann bei einer guten Platte schon mal 4 ms klein sein, bei schlechten Platten auch mal 8ms groß.

Die Rotational Delay ist bei 18000 rpm bei 300 Umdrehungen pro Sekunde, als 600 Halbdrehungen pro Sekunde oder 1/600 Sekunde = 1.6ms. Bei Laptop-Platten mit 6000 rpm ist sie dreimal größer, also 5ms. Die Transfer Time kann man für den Rest der Betrachtungen auch getrost vergessen. Somit haben wir eine Access Time von insgesamt 5ms bis 12ms rauf. Das übersetzt sich zu …