Archive for the 'Serien' Category

Linux Monitoring - iostat

Published by Bernd Erk on 20.11.2008 in Linux and Serien. 0 Comments

Im Gegensatz zum im letzten Post behandelten Kommando vmstat, dessen Schwerpunkte das Memory Monitoring ist, gibt iostat Auskunft über den CPU-Status und die Input/Output Statistiken der angeschlossen Blockdevices.

Ähnlich wie bei vmstat ist iostat durch einen optionalen Intervall und der gewünschten Wiederholungsanzahl zu parametrisieren. Auch die Tatsache, dass es sich bei der ersten Ausgabe um einen kumulierten Wert seit Systemstart und bei den Weiteren um die Werte innerhalb des angegebenen Intervalls, lässt eine gewisse Ähnlichkeit erkennen.

Wie der Screenshot erkennen lässt gibt iostat ausführliche Infos über die Auslastung der angeschlossenen Devices. Somit zum einen einseitig belastete Disks zu identifizieren, zum anderen gibt die Statistik Aufschluss über das grundsätzliche Read/Write verhalten des entsprechenden Servers. Ohne Angabe von Parametern erfolgt die Ausgabe der übertragenen Daten in Blöcken. Die Optionen (-m) oder (-k) geben die entsprechenden Informationen in Mega- und Kilobyte.

Wichtig ist die Unterscheidung von await und svctm. Während await (average wait) sowohl die IO-Zeit innerhalb der Queue und die Servicetime listet, gibt svctm nur die Servicetime aus. Ist de svctm (Millisekunden) auffällig hoch, könnte dies auf ein technisches Problem im Plattensubsystem oder andere Verbindungsschwierigkeiten hindeuten, während eine hohe Gesamtlaufzeit (bei schneller Servicetime auf einen IO-Overload des entsprechenden Devices hindeutet.

Linux Monitoring - vmstat

Published by Bernd Erk on 13.11.2008 in Linux and Serien. 0 Comments

Den letzten Post zum Thema Linux Monitoring haben wir dem Unix/Linux Klassiker top gewidmet. Er liefert bereits eine Vielzahl an Informationen zur Speicherverwaltung von Prozessen und der allgemeinen Systemauslastung. Etwas detailliertere Auskunft über die Auslastung des virtuellen Speichers gibt vmstat.

Bei Ausführung ohne Parameter gibt vmstat die Durchschnittswerte seit dem letzten Systemstart aus. Um vernünftige Echtzeitwerte zu bekommen sollte vmstat mit einem Delay von mindestens 5 Sekunden gestartet (vmstat 5) werden. Die Ausgabe teilt sich in folgende Bereiche:

  • procs
  • memory
  • swap
  • io
  • system
  • cpu
Die Manpage von vmstat gibt detailliert Auskunft über die Einzelwerte. Die wichtigsten Informationen sind in den Spalten r (running procs) sowie si und so  (swapped in and out). 

Die Zahl der running processes sollte die Zahl der verfügbaren Prozessoren nur kurzfristig übersteigen, da sich die stark CPU gebundenen Prozesse sonst stark verlangsamen. Gleiches gilt für überhöhte Swapping-Aktivität, welche das System innerhalb von Minuten zum erliegen bringen kann.Interessant ist auch die Option (-d) welche einem read/write/io Details für einzelne RAM und Blockdevices auflistet.

Linux Monitoring - top

Published by Bernd Erk on 06.11.2008 in Linux and Serien. 2 Comments

In der MySQL-Performance-Serie haben wir uns ja bereits ausführlich mit den Möglichkeiten beschäftigt, einen MySQL-Server zu beschleunigen. Das grundlegende Speicherverhalten eines Linux-Systems ist jedoch für alle darauf laufenden Anwendung von größter Wichtigkeit. Die gängigen Distribution liefern nahezu alle notwendigen Werkzeuge mit, um einen Blick hinter die Kulissen zu werfen.

In den nächsten Wochen werden wir auf einige dieser Kommandos etwas näher eingehen und versuchen einen Überblick über Einsatz und Interpretation zu geben.

Als erstes Kommando, wollen wir in diesem Post top unter die Lupe nehmen. Wahrscheinlich gibt es keinen Linux Administrator, der dieses Kommando nicht kennt, jedoch wird es meist nur dafür verwendet, den CPU intensivsten Prozess schnellstmöglich ausfindig zu machen. Durch die interaktiven Konfigurationsmöglickeiten bietet Top aber vielmehr Möglichkeiten. Bei laufendem top kommt man über die Taste “h” zur Hilfe für die Interactive Commands. Dort besteht Konfigurationsmöglichkeit zur Sortierung, Anzeige und auch Beeinflussung bestimmter Prozesse durch Veränderung der Prozesspriorität (renice). Auch die Ergebnisfilterung auf Userbasis ist hier möglich und kann bei Bedarf auch gespeichert werden. Lediglich das dedizierte Monitoring einzelner Prozesse Bedarf den Neustart mit Angabe (-p) der zu überwachenden Prozesse. Übrigens gibt es auch einen Batchmode, welcher mit der Option (-b) aktiviert wird und eine leichte Protokollierung der Ausgabe ermöglicht.

Für längerfristigen Analysen ist jedoch sar die bessere Alternative auf die wir demnächst auch im Blog eingehen werden.

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.

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 5: Key-Buffer

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

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.

« Older Entries