MySQL Performance Serie – Teil 1: Hardware

This entry is part 1 of 11 in the series MySQL Performance Serie

Der erste Artikel unserer angekündigten Performance-Serie widmet sich dem Thema Hardware. Meistens ist zum Zeitpunkt der “auftretenden Langsamkeit” die Hardwareschlacht schon längst geschlagen und der Server eingebaut, jedoch gibt es auch nachträglich gute Potentiale den Zugriff durch Auf- und Umrüstung zu beschleunigen.

Priorität 1 hat bei den meisten Systemen unangefochten das Thema Hauptspeicher. Die Aufrüstung ist aus Kostensicht meist überschaubar und bringt bei korrekter Verwendung des zusätzlichen Speichers, in der Regel das beste Optimierungsergebnis. Stichwort an dieser Stelle ist der Query Cache, der ausgelieferte Ergebnismengen speichert und somit einen erneutem Aufruf aus dem Speicher bedienen kann und damit den Zugriff auf das langsame Plattensubsystem verhindert.

Trotz eines gut angepassten Hauptspeichers lässt sich das Lesen und vor allem das Schreiben auf Platte natürlich nicht gänzlich eliminieren. Da Platten-IO noch immer physikalische Arbeit ist, gilt noch immer die Faustregel: mehr Spindeln -> bessere Performance. Wer die Möglichkeit hat, auf ein RAID 0 (aus Sicherheitsgründen meist 10) zuzugreifen, dem sei dies empfohlen. Ansonsten ist vor allem wichtig, dass sich nicht ewig viele System auf dem selben Plattentopf tümmeln, da MySQL seine IO Ressourcen ungern mit anderen Anwendungen teilt und den Benutzer dann mit mieser Abfrageperformance straft.

Neben einer halbwegs schnellen CPU, ist vor allem die Verwendung eines 64-Bit-Systems ein absolutes muss um den eingebauten Hauptspeicher auch ausnützen zu können. Andernfalls bleibt alles über 4 GB ungenutzt rumliegen.

Unser nächste Teil widmet sich dem Thema Storage Engines.

Bernd Erk

Autor: Bernd Erk

Bernd ist einer der Geschäftsführer der NETWAYS Gruppe und verantwortet das Tagesgeschäft. Da er in einem früheren Leben mit Java und Oracle Datenbanken gearbeitet hat, kümmert er sich immer noch gerne um das Thema Reporting - sowohl bei NETWAYS, als auch im Icinga Team. In seiner knappen Freizeit streitet er sich mit seinem Sohn, wer das iPad gerade benutzen darf und widmet sich der Weiterverbreitung der gehobenen fränkischen Schaschlik-Kultur.

MySQL Performance Serie – Teil 2: Storage-Engine

This entry is part 2 of 11 in the series MySQL Performance Serie

Das Herz der Datenbank ist, neben dem eigentlichen MySQL-Daemon, die verwendete Storage-Engine. Im Gegensatz zu vielen kommerziellen Datenbanken wie Oracle und DB2 ist diese bei MySQL entkoppelt vom eigentlichen Serverprozess.

Diese Architekturfeinheit bietet dem Anwender die Möglichkeit innerhalb eines Servers mehrer Engines mit unterschiedlichen Features zu verwenden und abhängig von seinen Bedürfnissen auszuwählen. Hier eine Liste der aktuell existierenden Engines:

  • MyISAM Storage Engine
  • InnoDB Storage Engine
  • MERGE Storage Engine
  • MEMORY (HEAP) Storage Engine
  • BDB (BerkeleyDB) Storage Engine (ab 5.1.12 nicht mehr unterstützt)
  • EXAMPLE Storage Engine
  • FEDERATED Storage Engine
  • ARCHIVE Storage Engine
  • CSV Storage Engine
  • BLACKHOLE Storage Engine

Auf die Feinheiten der einzelnen Engines einzugehen würde den Rahmen dieses Beitrags sprengen, jedoch ist der Unterschied zwischen den beiden meist verwendeten Engines MyISAM und InnoDB kurz zu beleuchten: InnoDB ist wie auch die BDB-Engine eine transaktionssichere Datenbank, welche beim parallelen Zugriff mehrerer Benutzer besser geeignet ist, da sie mit Hilfe von Row-Level-Locking und ACID-Transaktion die Datenkonsistenz sicherstellt und trotzdem gutes Antwortzeitverhalten liefert. Da MyISAM auf solche Features verzichtet und großzügig auch mal eine ganze Tabelle blockiert, ist sie für diese Anforderung ungeeignet, bietet aber wiederum im seriellen Zugriff, wie z.B. beim Reporting oder anderen Analyseverfahren eine meist bessere Leseperformance.

Da MySQL einen Mischbetrieb erlaubt kann man natürlich seine Tabellen den individuelle Bedürfnissen anpassen.

Im nächsten Teil geht es um den MySQL-Proxy.

Bernd Erk

Autor: Bernd Erk

Bernd ist einer der Geschäftsführer der NETWAYS Gruppe und verantwortet das Tagesgeschäft. Da er in einem früheren Leben mit Java und Oracle Datenbanken gearbeitet hat, kümmert er sich immer noch gerne um das Thema Reporting - sowohl bei NETWAYS, als auch im Icinga Team. In seiner knappen Freizeit streitet er sich mit seinem Sohn, wer das iPad gerade benutzen darf und widmet sich der Weiterverbreitung der gehobenen fränkischen Schaschlik-Kultur.

MySQL Performance Serie – Teil 3: MySQL-Proxy

This entry is part 3 of 11 in the series MySQL Performance Serie

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.

Bernd Erk

Autor: Bernd Erk

Bernd ist einer der Geschäftsführer der NETWAYS Gruppe und verantwortet das Tagesgeschäft. Da er in einem früheren Leben mit Java und Oracle Datenbanken gearbeitet hat, kümmert er sich immer noch gerne um das Thema Reporting - sowohl bei NETWAYS, als auch im Icinga Team. In seiner knappen Freizeit streitet er sich mit seinem Sohn, wer das iPad gerade benutzen darf und widmet sich der Weiterverbreitung der gehobenen fränkischen Schaschlik-Kultur.

MySQL Performance Serie – Teil 4: Query-Cache

This entry is part 4 of 11 in the series MySQL Performance Serie

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.

Bernd Erk

Autor: Bernd Erk

Bernd ist einer der Geschäftsführer der NETWAYS Gruppe und verantwortet das Tagesgeschäft. Da er in einem früheren Leben mit Java und Oracle Datenbanken gearbeitet hat, kümmert er sich immer noch gerne um das Thema Reporting - sowohl bei NETWAYS, als auch im Icinga Team. In seiner knappen Freizeit streitet er sich mit seinem Sohn, wer das iPad gerade benutzen darf und widmet sich der Weiterverbreitung der gehobenen fränkischen Schaschlik-Kultur.

MySQL Performance Serie – Teil 5: Key-Buffer

This entry is part 5 of 11 in the series MySQL Performance Serie

Bei Verwendung der MyISAM-Storage Engine macht die Datenbank vom sogenannten Key-Buffer-Cache gebrauch. In diesem Cache werden die meist frequentierten Index-Blöcke, ähnlich wie beim Query-Cache, abgelegt um den langsameren Zugriff auf das Plattensubsystem zu vermeiden. Bei Nutzung von MyISAM ist die Verwendung dieses Speicherbereichs ein absolutus muss.

Desto näher die Key-Hit-Ratio an 100% ist, desto besser die Effektivität und daraus folgend die Performance. Mit folgender Formel lässt sich die Key-Hit-Ratio ermitteln:

  • 100 – (key_reads * 100 / key_read_requests)

Die Werte können mit dem Befehl “show global status” ermittelt werden. Besonders interessant ist noch die Möglichkeit hochfrequentierte Blöcke manuell in den Key-Buffer zu laden. Dieses sogenannte Index Preloading gibt dem Administrator eine gute Möglichkeit die Wirksamkeit zu ermitteln.

Schwerkpunkt des nächsten Teils ist das Thema Slow-Queries.

Bernd Erk

Autor: Bernd Erk

Bernd ist einer der Geschäftsführer der NETWAYS Gruppe und verantwortet das Tagesgeschäft. Da er in einem früheren Leben mit Java und Oracle Datenbanken gearbeitet hat, kümmert er sich immer noch gerne um das Thema Reporting - sowohl bei NETWAYS, als auch im Icinga Team. In seiner knappen Freizeit streitet er sich mit seinem Sohn, wer das iPad gerade benutzen darf und widmet sich der Weiterverbreitung der gehobenen fränkischen Schaschlik-Kultur.