"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, …

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)

…

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 …

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 …

Wer dies und dies gelesen hat, versteht mehr.

InnoDB ist eine Storage Engine, die mit Hilfe von MVCC Transaktionen implementiert. Transaktionen zu implementieren bedeutet, daß man in der Lage ist, mehrere Änderungen zusammenzufassen und als eine Einheit als gültig zu markieren oder zurück zu nehmen. Damit das Ganze trotzdem schnell ist, muß man ein wenig herumtricksen.

Angenommen, wir wollen eine Spalte in einer Zeile in der Tabelle t ändern:

UPDATE t SET x=17 WHERE id=3

Dann muß InnoDB das zunächst einmal in eine Zeilennummer in einer Speicherseite übersetzen: InnoDB speichert Daten in Seiten von 16 …

MongoDB 2.0 ist draußen, und implementiert eine Reihe interessanter neuer Dinge, die ich anderswo gerne hätte, insbesondere im Bereich Replica Sets.

Postgres hat das Release 9.1 draußen. Die versprochene synchrone Replikation ist jetzt verfügbar, sie ist grob vergleichbar mit der Semisynchronen Replikation in MySQL 5.5. Ein wesentlicher Unterschied ist, daß man bei Postgres einzelne, bestimmte Server als synchrone Slaves benennen kann, während MySQL …

"Kris, kannst Du bitte mal gucken?"

Seit heute morgen, 10:00 Uhr, wächst das Undo Log immer weiter an.

Immer wenn InnoDB Daten schreibt wird die alte Version einer Zeile aus der Tabelle in das Undo-Log verschoben, also physikalisch von der ibd-Datei der Tabelle in die ibdata1 im Datadir von MySQL. In der Tabelle wird in der veränderten Zeile ein Zeiger von der neuen Version auf die alte Version der Zeile im Undo-Log installiert, der Roll(back)-Pointer. Die alte Version im Undo-Log zeigt mit ihrem eigenen Roll-Pointer auf eine noch ältere Version derselben Zeile und so weiter - es entsteht für jede Zeile in der Datenbank eine lineare Liste von Versionen in die Vergangenheit einer Row.

Der InnoDB Purge Thread hat die Aufgabe, das Undo Log zu verkürzen. Wenn er das nicht tut, dann sieht das so aus wie oben im Graphen gezeigt. Dafür kann es zwei Gründe geben: Purge Lag - also mehr Writes als der Purge Thread …

Ich brauche einmal Hilfe. Von Euch. Ich verstehe nämlich ein Konzept nicht. Es geht um den Begriff "Schemaless", der im Zusammenhang mit einigen NoSQL-Datenbanken verwendet wird.

Ich kann verstehen, daß für einige Leute ein ALTER TABLE wie in MySQL ein Problem ist, weil es Tabellen während der Schemaänderung lockt. Da ALTER TABLE in vielen Fällen die Daten zur Durchführung der Änderung umkopieren muß, kann dieses Lock entsprechend lange bestehen bleiben, wenn die Daten nur hinreichend groß sind.

Ich kann nicht verstehen, wieso Leute glauben, daß "Schemaless" da eine Hilfe wäre oder wieso Leute glauben, daß es so etwas wie "Schemaless" überhaupt gibt.

Daten in Datenbanken existieren ja in der Regel nicht im luftleeren Raum, sondern sie werden von Code genutzt. Dieser Code macht Annahmen über die Attribute, die in einer Tabelle (oder was immer Euer NoSQL als Tabellenäquivalent verwendet) existieren …

Anbei eine kleine Idee für alle, die verteilte Datenhaltung haben, und dazu eine architektonisch recht einfache Synchronisation brauchen. Manchmal kommt aus diversen Gründen ein Replikationsmechanismus nicht in Frage. Dafür nun die folgende Idee. Wir nutzen dabei aus, dass MySQL bei zusammengesetzten Indizes einen AUTO_INCREMENT-Wert pro distinktem Schlüsselpräfix zählt. Das heißt ganz konkret: Wir legen einen [...]