Zentrum für Informationsdienste und Hochleistungsrechnen (ZIH) Leistungsanalyse von Rechnersystemen Auf Ein-/Ausgabe spezialisierte Benchmarks Zellescher Weg 12 Willers-Bau A109 Tel. +49 351-463 - 32424 (michael.kluge@tu-dresden.de) Gliederung Motivation I/O Hardware I/O & Betriebssystem Charakterisierung von I/O Benchmarks für Ein/-Ausgabe Definition der zu messenden Parameter Typische Messungen Spezielle Benchmarks Analyse von Benchmark-Ergebnissen 1
Motivation Systeme wachsen Transfer Speicher <-> Platten Anzahl der Komponenten steigt -> mehr Einflüsse Plattenspeicher liegt heute im TB/PB Bereich Bandbreiten jenseits von 100GB/s sind möglich (ASCI Purple) Design eines HPC-Rechners muss I/O-Subsystem enthalten I/O - Hardware (1) Platten aufgeteilt in Blöcke, Spuren und Sektoren (Zylinder) konstante Winkelgeschwindigkeit Speicherkapazität heute mehr als ½ TB Umdrehungen pro Minute 5400-15000 Interface (IDE, SCSI, ATA, SATA, FC, ) Lebenszeit zwischen 500.000 und 1 Mio. Stunden verfügbar direkt, auch via USB, FireWire etc. durch Raid-Controller SAN 2
I/O - Hardware (2) Betriebssystem (Linux) & I/O read() Systemaufruf vfs_read() VFS file->f_op->read() Dateisystem submit_bio() q->reuest_fn() Block-Schicht I/O-Scheduler Gerätetreiber 3
Charakterisierung von I/O nach Anwendung Rohzugriff auf Platten ungepuffert open (IO_DIRECT), close read/write gepuffert fopen,fclose fread/fwrite darauf aufbauende Standards in Bibliotheken MPI-I/O (parallel) NetCDF (network common data form) HDF5 (Hierarchical Data Format Version 5) Charakterisierung von I/O nach Art der Aufrufe I/O - Operationen pro Sekunde: open, close stat unlink nach Größe: 1 Byte oder große Abschnitte nach Zugriffsmustern: auf die Datei aus dem Hauptspeicher wiederholtes Schreiben/Lesen nach Ziel der I/O-Operation Platten, Tapes 4
Rechnung zum buffer cache Beispiel: Linux kann 8 GB freien Hauptspeicher pro Knoten für den Cache-Puffer nutzen die reale Bandbreite des I/O Subsystems beträgt 0,1 GB/s die Bandbreite, die man sieht, wenn man nur in den Cache-Puffer schreibt, beträgt 100 GB/s Ein Prozess schreibt große Datenblöcke auf das I/O-Subsystem gemessen wird die Bandbreite in GB/s Frage: Wie viele Daten muss ich minimal auf das I/O Subsystem schreiben, damit das Ergebnis des Benchmarks nicht mehr als 1% von der realen Bandbreite entfernt ist? I/O Benchmarks Definition der zu messenden Parameter Hardware Betriebssystem Dateisystem Gepuffert/Ungepuffert Nutzung von Hauptspeicher Art des Zugriffs auf I/O-Routinen Parallelität Zugriffsmuster Wiederholungen 5
Typische Messungen nach Zielen Messung der Metadatenrate wie viele Dateien können N clients in einem Verzeichnis pro Sekunde anlegen wie viele Dateien können N clients in N Verzeichnissen pro Sekunde anlegen das selbe noch mal mit dem Anlegen von Verzeichnissen Messung des CPU-Overheads des Dateisystems Schreiben/Lesen von kleinen Puffern auf/von Platte Schreiben/Lesen mit verschiedenen Zugriffsmustern Messung der maximal verfügbaren Bandbreite Schreiben/Lesen großer Datenblöcke mit einem oder mehreren Task evtl. 1:1 Mapping zwischen Tasks und Anzahl der CPU's oder Anzahl der Netzwerkschnittstellen anstreben Beispiel - Messung der Metadatenrate SGI Altix 3700 - Dateisystem CXFS Operationen/Sekunde 350 300 250 200 150 100 50 0 1 2 4 8 16 32 #Prozesse create unlink 6
Beispiel - Messung der Metadatenrate SGI Altix 3700 - Dateisystem XFS Operationen/Sekunde 3500 3000 2500 2000 1500 1000 500 0 1 2 4 8 16 32 #Prozesse create unlink Beispiel - Messung der Metadatenrate AMD Opteron Cluster - Dateisystem Lustre 2000 Operationen/Sekunde 1500 1000 500 0 1 2 4 6 8 12 16 24 32 64 #Prozesse create unlink 7
Beispiel - Messung der Bandbreite SGI Altix 3700 - Dateisystem CXFS (Mai 2006) Durchsatz in MB/s 1400 1200 1000 800 600 400 200 0 Bandbreite 1 4 8 32 #Prozesse Beispiel - Messung der Bandbreite AMD Opteron Cluster - Dateisystem Lustre 3000 Durchsatz in MB/s 2500 2000 1500 1000 500 0 Bandbreite 1 3 8 16 32 128 160 200 #Prozesse 8
Standard - I/O Benchmarks Desktop-Umgebung Bonnie++ iozone postmark fsbench HPC-Umgebung ior (ASCI) b_eff_io (HLRS) SPEC SFS97 (NFS) Bonnie++ basiert auf bonnie Ziel: Performanceanalyse in Richtung Datenbanken oder Mailserver C++ Code fester Satz von Tests sequentieller Output von 1 Byte großen Blöcken sequentieller Output von größeren Blöcken Lesen eines Teils der Datei, invalideren des Hauptspeichers und zurück schreiben sequentieller Input von 1 Byte und größeren Blöcken zufälliges Lesen von Blöcken und in 10% der Fälle zurück schreiben von neuen Daten welche Anzahl von Dateien kann pro Sekunde erstellt/gelöscht werden Ergebnisse als *.cvs Dateien 9
iozone mehre Test-Szenarien: Lesen/Schreiben, zweites Lesen und Schreiben, mit Strides Lesen und Schreiben, zufälliges Lesen, pread(), mmap(), asynchrones I/O Unterstützung von Multi-Prozessorsystemen Ausgabe als Excel-Dateien C Code ior (ASCI Purple) auf Kommandozeile viele Optionen kein festes Set an Tests durch Script steuerbar C und Python Code testet auch: MPI I/O HDF5 parallele netcdf 10
b_eff_io (HLRS Stuttgart) Entwurf einer Art "Linpack für I/O" Messung verschiedener Lasten: Zeit bis gesamter Hauptspeicher einmal auf Platte geschrieben ist Verhalten bei verschiedenen Anzahl Prozessen/CPU verschiedene Zugriffsmuster Zugriff auf individuelle und geteilte Daten Ausgabe: Eine gewichtete Zahl über alle Messungen alle Teilresultate Benchmark Report Spezielle Benchmarks Abnahmetests in Dresden auf 1 oder 2 Dateisysteme werden Datenblöcke von 512MB geschrieben auf den Knoten werden 7/8 des verfügbaren Hauptspeichers allokiert es wird etwa das doppelte des Hauptspeichers auf Platte geschrieben spiobench es werden in der Summe von allen Prozessen immer 128GB geschrieben Blockgröße fest bei 192KB Ausführung auf 16-512 Prozessoren 11
I/O Setup SGI Altix 3700 - Dresden Winter 2005 Warum Abfallen der Kurve bei 512MB Blockgröße? GB/s 1,6 1,4 1,2 1 0,8 0,6 0,4 0,2 0 3,9GB/500MB 3,5GB/500MB 3,5GB/110MB 1 2 4 8 16 32 64 112 128 #processes 12
spiobench @ Indiana University - BigRed I/O Setup 40 x Chassis IBM Blade Center (4 x 1GigE uplink per Chassis) each has 14 IBM JS21 Blades (1 GigE I/O uplink per Blade) each Blade has 2 DualCore IBM PPC 970 processors, 8 GB main memory per Blade 1 2 40 160 Gbit/s 32 Gbit/s Force 10 E 600 GigE Switch 1 2 16 16 x IBM pseries GPFS Server (2 x 1GigE Uplink per Server) 266 TB Storage spiobench @ Indiana University - first write 1200 1000 800 MB/s 600 400 proc/blade 4 200 proc/blade 1-2 0 16 32 48 64 128 256 384 512 #processes 13
spiobench @ Indiana University - second write 1000000 100000 10000 MB/s 1000 100 proc/blade 4 10 proc/blade 1-2 1 16 32 48 64 128 256 384 512 #processes Hinweise bei I/O-Messungen Bei Vergleich von Messergebnissen muss das ganze System betrachtet werden. nur dedizierte Messungen sagen wirklich etwas aus mehrmals messen vorher überlegen Warum messe ich? -oder besser- Was will ich eigentlich messen? Welche Einflussparameter gibt es, auf die ich achten muss? Zum Erreichen maximaler I/O-Performance auf parallelen Systemen Ausgewogenheit im System Ein-/Ausschalten von zusätzlichen Caches evtl. frisch formatiertes Dateisystem verwenden Tuning im Linux-Kernel immer wesentlich mehr Schreiben, als der größte Cache gross ist 14
Analyse von I/O-Messungen Betrachtung der verwendeten Hardware Platten (Typ, Anzahl, Anordnung) Verbindungsnetzwerk und -technologien (FC, SCSI, ) Rechner-Hardware Anzahl CPUs Speicher Analyse des Betriebssystems und Messprogramms Tasks pro CPU Blockgrößen Zugriffsmuster auf Hauptspeicher Wiederholungen von Messungen 15