In der Juni-Ausgabe des IT-Administrator dreht sich alles um den Schwerpunkt 'Monitoring & Dokumentation'. So zeigen wir Ihnen, wie die Netzwerküberwachung in ... (mehr)

Die Auswertung zählt

Sind die verschiedenen Analyzer-Programme mit ihrer Arbeit fertig, stellt sich die Frage, was mit den ganzen Informationen geschieht. Ein erster Blick sollte sich dabei auf die Schreiboperationen der einzelnen Prozesse richten. Im Fall von MPI-Anwendungen ist es oft überraschend, dass sich die Lese- und Schreiboperationen auf einen Prozess konzentrieren. Bei anderen MPI-Projekten verteilen sich die I/O-Lasten auf eine fixe Anzahl von Prozessen, die aber immer noch kleiner ist als die gesamte Anzahl. Ein solches I/O-Muster herauszuarbeiten ist bereits sehr hilfreich, denn so ist es etwa in der Regel nicht ratsam, NFS zu verwenden, wenn viele Prozesse auf vielen Knoten darauf schreiben. Weitere nützliche Informationen, die sich nun ablesen lassen, sind etwa:

- die Anforderungen für den Durchsatz (Lesen und Schreiben)

- Anforderungen für IOPS (Lesen, Schreiben und gesamt)

- Größe der Lese- und Schreib-Requests (also die Verteilung der Größen)

- Zeit, die für I/O verbraucht wurde (gegenüber der Gesamtzeit)

- Informationen über Seek-Operationen

Die Analyse eines konkreten Beispiels soll dies veranschaulichen. Dazu sind in der Tabelle "Anzahl der Aufrufe von I/O-Funktionen" die Ergebnisse von acht Prozessen aufgeführt. Die Ergebnisse des MPI-Prozesses mit dem höchsten Anteil an I/O sind in der Datei zu finden, die der letzten Spalte der Tabelle entspricht. Trotzdem entfällt auf den Prozess nur 1,15 Prozent der gesamten Laufzeit. Das bedeutet, durch die Optimierung des I/O ließe sich bei der Gesamtlaufzeit nur eine Verbesserung von maximal 1,15 Prozent erzielen.

Auch bei der Anzahl von Aufrufen der Funktionen und liegt der Prozess vorne. Wie die Tabelle und Bild 1 zeigen, hat aber auch der Prozess file_18590 einen großen I/O-Anteil. Um herauszufinden, ob der eine oder der andere Prozess die Ein-/Ausgabeoperationen dominiert, hilft ein Blick auf Bild 2. Dort sind die Menge der geschriebenen Daten der einzelnen Prozesse und deren Durchschnitt abgebildet. Der Löwenanteil entfällt mit 1,75 GByte von 3 GByte demnach auf .

Die Tabelle "Größe der Schreib-Requests" gibt nun Aufschluss über die Größe der einzelnen Schreib-Requests. Die meisten bewegen sich zwischen 1 und 8 KByte, wobei der weitaus größte Teil 1 Kbyte oder kleiner ist. Die Anwendung setzt also eine eher große Menge sehr kleiner Schreib-Requests ab. Ähnlich fällt auch das Ergebnis der im Kasten "Schreibstatistik" abgedruckten Zusammenfassung aus, die der MPI Strace Analyzer ausgibt: Die Anwendung hat etwas mehr als 3 GByte Daten geschrieben, wobei die durchschnittliche Größe der Schreib-Requests sich um 10 KByte bewegt.

MPI Strace Analyzer-Ausgabe "IOPS-Statistik"

= 2058.75

Die gleiche Analyse lässt sich auch mit der Funktion durchführen. Die Größe der Requests variiert dabei zwischen 1 und 10 Mbyte. Bei genauerer Betrachtung stellt sich heraus, dass ein Teil der Schreib-Requests sich durch das Laden der Shared Libraries ergeben.

Der letzte Teil der Ausgabe des MPI Strace Analyzer, der im Kasten "IOPS-Statistik" wiedergegeben ist, zeigt, dass die Spitzenwerte für die Schreib-IOPS (Peak Write IOPS) bei 2.444 liegen. Das ist ziemlich viel für eine SAS- oder SATA-Festplatte mit 7.200 Umdrehungen. Die Lese-IOPS sind demgegenüber mit 153 relativ niedrig. Die große Zahl der Schreib- und Gesamt-IOPS resultiert daraus, dass es eben sehr viele sehr kleine Schreiboperationen gibt. Um dem gerecht zu werden, wären recht viele Festplatten ideal. Aber Sie sollten wie angedeutet nicht vergessen, dass Sie dadurch an der Gesamtlaufzeit nur wenig ändern können. Besser wäre es hier vermutlich, dem Cluster einen neuen Knoten hinzuzufügen.

Fazit

Storage für verteilte Anwendungen auszulegen, ist eine anspruchsvolle Aufgabe. Der erste Schritt dabei besteht in der Analyse der Anforderungen, das bedeutet insbesondere der Ein-/Ausgabe-Profile der wichtigsten Applikationen. Hierzu gibt es eine Reihe kleiner Tools – tiefere Einblicke erlaubt beispielsweise Strace, das im Detail aufschlüsselt, welche Daten ein Prozess liest und schreibt. Bei der Analyse der Strace-Logs hilft ein kleines Skript namens Strace Analyzer.

(of/ln)

Link-Codes

[1] Sysstat:: http://sebastien.godard.pagesperso-orange.fr/

[2] Iotop:: http://guichaz.free.fr/iotop/

[3] Collectl:: http://collectl.sourceforge.net/

[4] Collectd:: http://collectd.org/index.shtml/

[5] Blktrace:: http://www.cse.unsw.edu.au/~aaronc/iosched/doc/blktrace.html/

[6] Seekwatcher:: https://oss.oracle.com/~mason/seekwatcher/

[7] Strace Analyzer:: http://clusterbuffer.wordpress.com/strace-analyzer/

[8] MPI Strace Analyzer:: http://clusterbuffer.wordpress.com/strace-analyzer/mpi-strace-analyzer/

Ähnliche Artikel

comments powered by Disqus
Mehr zum Thema

Strace hilft Fehler finden

Wenn ein Programm partout nicht starten will, aber keine vernünftige Fehlermeldung ausgibt, hilft Strace bei der Suche nach den Ursachen.

Artikel der Woche

Eigene Registry für Docker-Images

Wer selber Docker-Images herstellt, braucht auch eine eigene Registry. Diese gibt es ebenfalls als Docker-Image, aber nur mit eingeschränkter Funktionalität. Mit einem Auth-Server wird daraus ein brauchbares Repository für Images. (mehr)
Einmal pro Woche aktuelle News, kostenlose Artikel und nützliche ADMIN-Tipps.
Ich habe die Datenschutzerklärung gelesen und bin einverstanden.

Konfigurationsmanagement

Ich konfiguriere meine Server

  • von Hand
  • mit eigenen Skripts
  • mit Puppet
  • mit Ansible
  • mit Saltstack
  • mit Chef
  • mit CFengine
  • mit dem Nix-System
  • mit Containern
  • mit anderer Konfigurationsmanagement-Software

Google+

Ausgabe /2019