Author Archive for Bernd Erk

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.

Nagios 3.0.5 released

Published by Bernd Erk on 05.11.2008 in Nagios, Nagios 3 and Security. 0 Comments

Trotz der Präsidentschaftswahl am gestrigen Dienstag war Ethan fleissig und hat Nagios 3.0.5 veröffentlicht. Laut Changelog bringt die neue Version vor allem Security-Bugfixes und einige Erläuterungen zu diesem Thema in der Dokumentation. Da die Schwachstelle in der cmd.cgi einem Angreifer erlauben würde, beliebigen Code auf dem Nagios System auszuführen, ist ein Update dringend angeraten.

Wie immer steht die aktuelle Version auf Sourceforge zum Download bereit.

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.

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”.

Nagios Projekt bei der XCOM AG

Published by Bernd Erk on 09.10.2008 in Kunden & Projekte and Nagios. 0 Comments

Wir freuen uns, mit der XCOM AG einen neuen Kunden im Bereich Open Source Systems Management gewonnen zu haben.

Seit 1988 engagiert sich die Firma XCOM mit ihren Mitarbeiter für Kunden aus dem Banken- und Finanzsektor. Heute zählt die XCOM AG zu den führenden Anbietern für eBusiness-, eCommerce-, eBrokerage und eBanking-Lösungen in Deutschland.

Im Projekt werden wir unseren Kunden bei der Einführung von Nagios und der Implementierung unseres Nagios Portals unterstützen um eine problemlose Migration der bestehenden Umgebung sicherzustellen. Durch das große vorhandene Know-how auf Kundenseite werden wir einige Extensions im Portal gemeinsam weiterentwickeln und dann der Community zur Verfügung stellen.

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’

« Older Entries