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)

Ich habe heute an dem Problem weiter geforscht und wir haben etabliert, dass die Ursache nicht der Quelltext des betreffenden Diamond-Collectors sein kann.

Auf allen betroffenen Kisten habe ich dann gesehen, daß die entsprechenden Queries gegen Performance-Schema ein

CODE:mysql> select * from performance_schema.threads;

Empty set (0.01 sec)

zurück liefern.

Weitere Untersuchung stellt heraus: P_S ist aber an. Jedoch:

CODE:mysql> select * from performance_schema.setup_instruments;

Empty set (0.03 sec)

mysql> select * from performance_schema.setup_timers;

Empty set (0.01 sec)

mysql> select * from performance_schema.setup_consumers;

Empty set (0.02 sec)

…

Heute erreicht mich eine Mail, in der ein DBA sich über steigende Replication Delay in einer bestimmten Replikationshierarchie beschwert.

Das ist schlecht, denn die betreffende Hierarchie ist wichtig. Also die 'Wenn die nicht geht schlafen Leute unter Brücken'-Art von wichtig.

Die Theorie war, daß die Änderungsrate in dieser Hierarchie so hoch ist, daß die Schreiblast von MySQL Replikation, die ja Single Threaded ist, nicht mehr bewältigt werden kann. Für diese Theorie sprach nach dem ersten Augenschein, daß alle betroffenen Kisten keine lokalen Platten hatten, sondern auf einem Filer lagen, und Filer sterben wegen der hohen Kommunikationslatenz im SAN bei uns in der Regel weit vor lokalen Platten, wenn es um Replikation geht: Filer sind mehr so beim parallelen Schreiben mit mehreren Threads gut.

Wenn dem so wäre, wäre das schon einen Seufzer wert, denn die betreffende Replikationshierarchie war gerade beim …

Hier ist eine wichtige Zahl:

Ein Coredump von einem MySQL auf einer Maschine mit knapp unter 200G Speicher dauert 15 Minuten. Auf SSD. Auf eine Festplatte dauert der gleiche Coredump dann knapp über 30 Minuten.

Warum ist das eine wichtige Zahl?

SSD sind schnell. Linear schreiben sie mehr als 200 MB pro Sekunde weg - ein ziemlich beeindruckendes Tempo, und noch dazu in einer Disziplin, wo sie nicht einmal optimal nutzbar sind. Auch moderne Serverfestplatten sind schnell - beim linearen Schreiben immerhin knapp halb so schnell wie eine SSD, oder 100 MB pro Spindel linear.

Aber moderne Maschinen haben halt auch eine sehr große Menge Speicher. Und 200 GB bei 200MB pro Sekunde sind halt dann eine Viertelstunde pro Full Dump oder Full Scan.

In Eine reiche NoSQL-Anfragesprache macht Ulf Wendel sich …

Der ORACLE INFORMATION INDEPTH NEWSLETTER MySQL Edition Ausgabe September 2012 ist erschienen.

More:
http://www.oracle.com/us/dm/100102648-index-oem-1840795.html

Alexander Aulbach fragt in den Kommentaren zu Load Testing und Benchmarks:

Es wäre mal interessant zu schauen, welchem physikalischen Modell das am ehesten gehorcht.

Guckst Du hier:

Raj Jain, The Art of Computer Systems Performance Analysis: Techniques for Experimental Design, Measurement, Simulation, and Modeling (Wiley and Sons, 1992)

oder hier:

Neil J Gunter, Analyzing Computer System Performance with Perl::PDQ (Springer, Kindle Edition)

Von Neil J Gunter auch:

Neil J Gunter, …

So. Du willst also wissen, was genau die Leistungsgrenzen Deines Systems sind. Und dazu möchtest Du einen Lasttest fahren, um Ergebnisse zu ermitteln.

Die Grundidee Deines Plans sieht so aus:

Du nimmt Deine Kiste und findest eine Methode, um Last zu generieren. Dann wirst Du schon merken, wie weit das geht und wann die Kiste ausgelastet ist.

Der erste Fehler: Den Lastgenerator auf der zu testenden Kiste laufen lassen. Das geht nicht. Unser Ziel ist es ja, die Kiste bis an ihre Lastgrenze zu bringen. Genau genommen wollen wir sie sogar darüber hinaus drücken, und das geht nur genau dann, wenn wir mehr Last erzeugen können, als die zu testende Kiste abarbeiten kann.

Teilen sich der Lastgenerator und die zu testende Anwendung irgendwelche kritischen Ressourcen, gelingt das nicht: Die Ressource, etwa CPU, wird knapp und verlangsamt nicht nur die zu testende Anwendung, sondern auch den Lastgenerator, bis sich das …

Wir generieren eine neue Art von Materialized View mit dem bekannten Generator-Setup:

Materialized View-Generator

Das neue Setup unterscheidet sich in der Logik von denen, die wir bisher verwendet haben, und so kommt es beim Testlauf zu einem ungewöhnlichen und unerwarteten Ereignis:

Um 14:30: Ein Gigabit-Netzwerk mit 125 MB/sec ausgelastet.

Bei einem Probelauf gehen die Alarme los, weil der Gigabit-Netzwerkstrang zur Datenbank mit 125 MB/sec (Ein Gigabit/sec) vollständig ausgelastet ist. Wie man sehen kann, ist die Datenbank zu diesem Zeitpunkt nicht besonders beschäftigt:

Statements/sec - die Datenbank nimmt kaum die Hände aus den Hosentaschen.

Auch auf dem Binlog ist nichts besonderes zu …

"Hey, Kris! Wir haben zwischen 16:20 und 17:20 CEST einen Lasttest durchgeführt und kurz vor 17:00 Uhr einen unerklärlichen Spike und einen Leistungsabfall festgestellt. Kannst Du mal gucken?"

Klar kann ich. Wo ich arbeite machen wir etwas, das wir Testing in Production nennen.

Für Lasttests bedeutet das, daß wir einzelne Systeme im Loadbalancer so lange relativ höher gewichten bis sie Probleme bekommen und umfallen. Zur Kontrolle legen wir mit Apache Siege eine Reihe von Sensor-Requests in das zu testende System, nicht zur Lastgenerierung, sondern um zu sehen, wann die Latenz nach oben geht, also um Sättigung des zu testenden Systems zu bemerken bevor es Fehler zu generieren beginnt.

Wenn wir nahe an den Sättigungspunkt gelangen, erhöhen wir die Last in sehr winzigen Schritten, bis wir tatsächlich Systemversagen zu …

Ein Heise-Artikel faßt die Entwicklungen um die Offenheit von MySQL mal in deutscher Sprache zusammen (bisherige Quellen sind alle in englischer Sprache). Leider war diese Entwicklung schon eine Weile abzusehen...

"Oracle zieht die Daumenschrauben an" vollständig lesen