Tag Archive for 'MySQL'

mysqlslap - Datenbanklast erzeugen

Published by Bernd Erk on 31.10.2008 in MySQL. 0 Comments

Seit der Version 5.1.4 bringt MySQL das Tool mysqlslap mit. Wörtlich übersetzt würde dies dann folgendes bedeuten:

MySQL eine klatschen

Und genau das macht das Tool auch. Mit mysqlslap kann man die Datenbank so richtig unter Last bringen und zum einen Bottlenecks finden oder auch bereits vollzogene Tuningarbeit auf Tauglichkeit prüfen. Über eine Vielzahl von Parametern kann der Aufruf, die Art und Anzahl der Statements als auch der für die Analyse notwendige Debug-Ouptut beeinflusst werden. Die Kenntnis über das Nutzungsprofil der Datenbank ist zwar Voraussetzung für die richtige Konfiguration der Datenbank, jedoch kann das Tool Out-of-the-Box diverse Nutzungsprofile “abspielen”.

Oft fehlt es auch den Entwicklern an adäquaten Werkzeugen um ihre aktuelle Version hinsichtlich Query-Performance zu testen und die Auslastung des Datenbank-Servers, mit bereits in der MySQL-Serie erwähnten Tools wie InnoTop und MyTop, zu beobachten.

MySQL Performance Serie - Zusammenfassung

Published by Bernd Erk on 29.10.2008 in MySQL and Serien. 1 Comment

Wie im letzten Post dieser Serie bereits versprochen, haben wir alle Themen der MySQL Performance Serie nochmals zusammengefasst um einen Überblick über alle erläuterten Themen zu geben.

Durch Feedback und Fragen unserer Leser ist die Serie dann doch etwas größer ausgefallen als erwartet, aber das kann eigentlich ja nur gut sein ;-)

Nochmals vielen Dank an alle für das zahlreiche Feedback und das Interesse an dieser Serie.

MySQL Performance Serie - Teil 10: Überblick behalten

Published by Bernd Erk on 22.10.2008 in MySQL and Serien. 0 Comments

In vielen Teilen der Blog-Serie sind wir auf Möglichkeiten eingegangen, Probleme zu identifizieren und deren Ursache zu analysieren und zu eliminieren. Im täglichen Betrieb fehlt es jedoch meist an der Zeit Statusvariablen zu filtern, Ausführungspläne einzelner Statements zu durchforsten oder aktuelle Datenbankverbindungen zu tracen.

Eine große Erleichterung bieten hier Werkzeuge wie MyTop und InnoTop. Beide geben in einem topähnlichen Stil den aktuellen Status der Datenbank wieder und bieten Aufschluss über die aktuell laufenden Prozesse. InnoTop, der Name verrät es bereits, ist stärker auf die Parameter der InnoDB-Engine spezialisiert, welche sich in der Konsole auch mit dem Befehl “show engine innodb status” auswerten lassen.

Besonderes Merkmal von InnoTop ist die Möglichkeit sich auf mehrere Server gleichzeitig zu verbinden und diese zu Gruppen zusammenzufassen. So kann man auch in einer geclusterten Umgebung gut den Überblick behalten.

Vorerst ist dies der letzten Teil unserer Performance-Serie rund um MySQL, aber weitere Serien werden folgen. In den nächsten Tage wird es noch eine Zusammenfassung der einzelnen Artikel zum Abschluss geben.

SOLR und MySQL-Proxy bei Tradoria

Published by Peter Putz on 16.10.2008 in Kunden & Projekte. 0 Comments

Nachdem wir ja aktuell auf die Möglichkeiten von MySQL eingehen hier gleich mal ein Praxisbeispiel für den MySQL-Proxy.

Mit unserem Kunden Tradoria GmbH haben wir den Proxy eingerichtet um die zunehmenden Anfragen auf mehrere Datenbankserver zu verteilen. So kann die Performance des Datenbank-Clusters noch effizienter ausgenutzt werden.

Außerdem wurde ein weiterer Server eingerichtet um mit einem SOLR System die Suchanfragen zu optimieren. Durch die virtualisierte Umgebung konnte so ohne zusätzlichen Hardwareaufwand ein unabhängiger Server aufgesetzt werden, der bei Bedarf gut portierbar und skalierbar ist.

Erste Ergebnisse sind für beide Systeme positiv ausgefallen, so dass mit diesen Optimierungsmaßnahmen  das Weihnachtsgeschäft kommen kann.

MySQL Performance Serie - Teil 9: Verwendung von Indizes

Published by Bernd Erk on 15.10.2008 in MySQL and Serien. 0 Comments

Fehlende oder falsche Indizes sind ein häufiger Grund für eine schlechte Abfrageperformance. Mit Hilfe des Slow-Query-Logs lassen sich vorhandene Langläufer meist auch gut identifizieren, jedoch kommt dann natürlich die Frage des Warum?

Auskunft über den Query-Execution-Plan und die Verwendung von Indizes gibt der Befehl Explain.

Folgendes Beispiel zeigt die Ausgabe des Befehls

  • EXPLAIN SELECT name, strasse, land FROM adressen WHERE strasse= “hauptstrasse” and name = “Erk” ORDER BY strasse;

select_type: SIMPLE
table: adressen
type: ref
possible_keys: strasse, name
key: strasse
key_len: 150
ref: const
rows: 1229
Extra: Using where; Using filesort

Die Ausgabe des Explain-Befehls gibt Aufschluss über die vorhandenen (possible_keys) und verwendeten (key) Indizes. MySQL verwendet pro Tabelle in einer Query maximal einen Index und zwar den, mit der kleineren Treffermenge.

Im oben genannten Beispiel empfiehlt sich also möglicherweise die Anlage eines mehrspaltigen Indizes. Legt man das Sortierkrierium (in diesem Fall Strasse) noch an die letzte Stelle des Indizes, dann spart man sich zusätzlich noch den teuren Filesort da die Daten bereits sortiert im Index liegen.

Inhalt des nächsten und letzten Artikels dieser Serie ist das Thema “Überblick behalten”.

MySQL Performance Serie - Teil 8: Replikation

Published by Bernd Erk on 08.10.2008 in MySQL and Serien. 0 Comments

MySQL verfügt über einen guten Replikationsmechanismus, der bei korrekter Konfiguration sehr fehlerunanfällig und stabil seinen Dienst verrichtet.

Die Replikation einer Datenbank hat in der Regel eines der folgenden Motive:

  • Lastverteilung: Entweder über Multi-Master-Replikation oder Master-Slave durch gezielte Select-Zuweisung auf die Slave-Datenbanken
  • Ausfallsicherheit: Multi-Master-Replikation als Failover-Datenbank ohne manuellen Zugriff
  • Verwendung einer Slave-DB als Aggregations- und/oder Analysedatenbank.

Neu in der Version 5.1 ist die Mixed-Based Replikation (kurz MBR). Hier erfolgt die Replikation normalerweise Statement basierend und wird nur bei bestimmten Ausnahmen auf Row-Level Replikation umgestellt. In vielen Szenarien resultiert die Verwendung von MBR in einer erheblichen Performancesteigerung.

Ein bekanntes Problem bei der Multi-Master-Replikation ist die automatische Schlüsselvergabe. Die MySQL Parameter auto_increment_increment und auto_increment_offset vermeiden hier doppelte Schlüsselvergabe indem Sie eine Art Schlüsselband pro Replikationsknoten erzeugen.

Continue reading ‘MySQL Performance Serie - Teil 8: Replikation’

MySQL Performance Serie - Teil 7: Table-Partitioning

Published by Bernd Erk on 01.10.2008 in MySQL and Serien. 0 Comments

Mit der Version 5.1 hält Table-Partitioning Einzug in MySQL. Kommerzielle Datenbanken wie z.B. Oracle haben schon seit Jahren dieses Feature implementiert und es wird wirklich Zeit dass MySQL hier nachzieht.

Partitioning zerlegt nach definierbaren Regeln eine physikalische Tabelle in einzelne Teile. Für den Anwender ist dies transparent und er bekommt bei normalen DDL nichts von den vorhandenen Partitionen mit. Die “Zerlegungsregel” kann bei Anlage der Tabelle mitgegeben und einzelne Partionen danach entfernt oder hinzugefügt werden.

Version 5.1 unterstützt MySQL folgende Partitionierungsstrategien:

  • List-Partitioning
  • Range-Partitioning
  • Hash-Partitioning
  • Key-Partitioning

Die Dokumentation gibt detailierten Aufschluss über die vorhandenen Optionen und das passende Einsatzszenario.

Besonders interessant ist noch das sogenannte Partition-Pruning. Hier kann die Datenbank einzelne Partitionen bei einer selektiven Abfrage mit Where-Klausel ausschliessen und somit die zu verarbeitende Menge minimieren.

Replikation ist Inhalt des nächsten Teils.

MySQL Performance Serie - Teil 6: Slow-Query-Log

Published by Bernd Erk on 24.09.2008 in MySQL and Serien. 0 Comments

Vielen MySQL-Benutzern ist der Slow-Query-Log natürlich bekannt und meistens die erste Anlaufstelle um langsame SQL-Queries im System aufzuspüren und in der Einzelanalyse zu optimieren. Interessant sind jedoch die Möglichkeiten die long_query_time, also die Zeit bis zur Ausführung des Statements, zu parametrisieren und die Statements auszugeben, die nicht von einem Index gebrauch machen. Wichtig ist jedoch immer eine längerfristige Beobachtung und Analyse des Systems um Unschärfen oder einmalige “Ausrutscher” zu eliminieren und keine vorzeitigen Schlüsse zu ziehen.

Beim Start des MySQL-Daemons mit dem Parameter “–log-queries-not-using-indexes” werden Statements ohne Verwendung von Indizes ebenfalls protokolliert. Die Anlage des richtigen Indizes ist neben der Aktivierung des Query-Caches meist die einfachste Möglichkeit die Selektionsperformance deutlich zu verbessern.

Zusätzlich kann der Datenbank-Administrator noch seine eigenen Langläufer mit dem Parameter “–log-slow-admin-statements” ausgeben.

Inhalt des nächsten Serienteils ist das Table-Partioning.

MySQL Performance Serie - Teil 4: Query-Cache

Published by Bernd Erk on 10.09.2008 in MySQL and Serien. 0 Comments

Wie bereits im ersten Teil unserer Performance-Serie angesprochen, ist die schnellste Art der Ergebnissermittlung innerhalb der Datenbank der Query-Cache.

Mit dem Befehl “show variables like ‘query%’;” können die aktuellen Einstellungen zum Query-Cache ermittelt werden. Häufig ist der Wert des Parameters query_cache_type zwar auf ON jedoch die eigentliche query_cache_size auf 0 was die Cache quasi ausschaltet. Sobald dem Query-Cache eine gewisse Grösse an Hauptspeicher zugewiesen wird, was aufgrund des dynamischen Speichermanagements auch zur Laufzeit funktioniert, verrichtet er seinen Dienst und liefert bereits selektierte Ergebnismengen aus dem Speicher aus.

Mit dem Befehl “show status like ‘qc%’;” kann der aktuelle Status und die Auslastung des Query-Caches ermittelt werden. Auch der MySQl-Administrator bietet eine grafische Möglichkeit die Hitrate zu analysieren.

Thema des nächsten Teils ist der Key-Buffer.

MySQL Performance Serie - Teil 3: MySQL-Proxy

Published by Bernd Erk on 03.09.2008 in MySQL and Serien. 0 Comments

Zwar gibt es dieses Tool bereits seit längerem, jedoch kommt es aufgrund der Unkenntnis über das genaue Funktionsprinzip und der Befürchtung der Proxy könnte den Datenbank-Verkehr als zusätzliche Komponente lahmlegen, noch eher selten im produktiven Umfeld zum Einsatz.

Der MySQL-Proxy ist eine klassische Middleware-Komponente welcher zwischen MySQL-Client und einer oder auch mehrerer Datenbank angesiedelt ist. Mit Hilfe einer integrierten LUA-Scriptsprache kann der Administrator den ein- und ausgehenden Datenverkehr überwachen und bei Bedarf auch verändern. So können z.B. Select-Statements explizit auf einen Replikat-Slave geroutet werden um den Master-Server zu entlasten.

Aus Performancesicht ist aber besonders das Thema Connection-Pooling und Load-Balancing interessant. Der Proxy kann eingehende Anfragen im Round-Robin-Prinzip an die verfügbaren Server verteilen und hält die Verbindung zwischen den einzelnen Abfragen offen. Oft ist die eigentliche Applikation nicht mit einem Connection-Pool ausgestattet, so dass sich der Einsatz des Proxys durch die Reduzierung der langsamen Verbindungsverwaltung positiv auf die Applikationsperformance auswirken kann.

In den nächsten Teilen werden wir uns einigen Datenbankparametern annehmen.

« Older Entries