Die Laufzeit von Queries werden auch durch den Optimizer bestimmt.
Dazu werden auch Statistiken genutzt, die wir uns in dem folgenden Blog näher anschauen:

ORDIX Blog

"Kris, bitte schau Dir mal unsere Datenbank an. Wir haben hier einen Generator für unsere Materialized Views, und auf einer Datenbank von 6 GB Größe werden 40 GB Speicher gefüllt und wir kommen sogar ins Swappen."

Na, das ist mal interessant. The fragliche Kiste hat 48 GB RAM, und in der Tat kaum 6 GB Daten.

CODE:mysql> select 

 -> sum(data_length+index_length)/1024/1024/1024 as gb 

 -> from tables 

 -> where table_schema not in ('information_schema', 'performance_schema', 'mysql');

+----------------+

| gb             |

+----------------+

| 5.832778930664 |

+----------------+

1 row in set (0.00 sec)

Aber in "top" sieht das so aus, …

Mein Kollege Dennis Kaarsemaker hat jetzt einen Artikel zu dem Replication Load Monitor von Booking.com gebloggt. Der Monitor basiert auf Arbeiten von Mark Leith.

Möge er Euch allen nützen.

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)

…

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 …

MySQL hat bisher nicht den besten Ruf was die Performance von Stored Procedures angeht. Bereits 2008 war dies ein Thema in einem Blogeintrag[1]. Darin wurde die Fibonacci Formel[2] mit einer Stored Function nachgebildet. Das Ergebnis war: PHP ist mit einer ähnlichen Funktion 10x schneller als die MySQL Stored Function. Hat MySQL inzwischen nachbessern können? UPDATE 03.05.2011

In Hotspots in MySQL finden hatte ich noch mit Maatkit herumgespielt, um die Hotspots zu finden, die meinen Master behelligen. Das hat auch leidlich gut funktioniert, nur ist Maatkit leider viel zu langsam, um das bei größeren Datenmengen und längeren Beobachtungszeiträumen sinnvoll zu machen.

Ich habe meinen Ansatz also noch einmal revidiert. Ich sammle meine Daten immer noch an einem SPAN-Port, aber inzwischen mit tcpflow, das mir die Daten schön in Dateien pro Connection sammelt. Diese Dateien müssen nun protokollanalysiert werden, da ein einfaches "strings" leider keine sinnvoll weiterverarbeitbaren Informationen ergibt.

Also habe ich mir einen sehr simplen MySQL Protokollanalysator geschrieben, basierend auf den Informationen …