Zentrum für Informationsdienste und Hochleistungsrechnen (ZIH) Leistungsanalyse von Rechnersystemen I/O Subsysteme und auf Ein-/Ausgabe spezialisierte Benchmarks Zellescher Weg 12 Willers-Bau A109 Tel. +49 351-463 - 32424 (michael.kluge@tu-dresden.de) Zentrum für Informationsdienste und Hochleistungsrechnen (ZIH) Summary of Previous Lecture Zellescher Weg 12 Willers-Bau A109 Tel. +49 351-463 - 32424 (michael.kluge@tu-dresden.de)
Summary of Previous Lecture: Part I Monitoring Techniques Tool to observe the activities on a system Terminology: Event, Trace, Overhead, Domain, Input Rate, Resolution, Input Width System implementation levels: Software, Hardware, Firmware, Hybrid Trigger mechanisms: Event-driven, timer-driven Data display: On-line, batch/post-mortem Interval timers Most fundamental measuring tool, based on counting clock pulses Execution time, forms basis for sampling Hardware, software Time rollover Summary of Previous Lecture: Part II Program Execution Monitors: PC Sampling Basic Block Counting Indirect Strategies Tracing Instrumentation Manual (source based) Software Exceptions Emulation Binary Library Compiler Tools and their formats
Zentrum für Informationsdienste und Hochleistungsrechnen (ZIH) Leistungsanalyse von Rechnersystemen I/O Subsysteme und 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
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 (erstmals mit 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
I/O - Hardware (2) Betriebssystem (Linux) & I/O read() Systemaufruf vfs_read() VFS file->f_op->read() Dateisystem submit_bio() Block-Schicht I/O-Scheduler q->reuest_fn() Gerätetreiber
Effekte von Betriebssystempuffern auf I/O 800 700 600 throughput in MB/s 500 400 300 200 Limit 100 0 0 500 1000 1500 2000 2500 3000 3500 4000 4500 total file size written in MB Charakterisierung von I/O nach Anwendung roh-zugriff auf Platten unbuffered open (IO_DIRECT), close read/write buffered 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 Performance großes I/O vs. kleines I/O small vs. large I/O blocks for a 1GB file written to fasfs 1000 100 throughput in MB/s 10 1 0.1 1 10 100 1000 10000 100000 1000000 0.01 block size in byte
Rechnung zum buffer cache Beispiel: Linux kann 8 GB freien Hauptspeicher auf einem Knoten für den buffer cache nutzen die reale Bandbreite des I/O Subsystems beträgt 0,1 GB/s die Bandbreite, die man sieht, wenn man nur in den buffer cache schreibt, beträgt 10 GB/s Ein Prozess schreibt grosse 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 10% 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
Typische Messungen nach Zielen Messung der Metadatenrate wieviele Dateien können N clients in einem Verzeichnis pro Sekunde anlegen wieviele Dateien können N clients in N Verzeichnissen pro Sekunde anlegen das selbe nochmal 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
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 1.4 (2006) 2000 Operationen/Sekunde 1500 1000 500 0 1 2 4 6 8 12 16 24 32 64 #Prozesse create unlink
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
HRSK Filesysteme 2008 - Bandbreite Wie viele Bytes bekommt man pro Sekunde auf die Platten Je mehr, desto besser Alle Zahlen sind für einen einzelnen Rechner, der 10 GB in großen Blöcken schreibt PC mars 1 stripe 2 stripes 16 stripes 48 stripes /fastfs - 3 GB/s 250 MB/s 406 MB/s 369 MB/s 267 MB/s /work - 3 GB/s 169 MB/s 213 MB/s 354 MB/s - /tmp 58 MB/s 1) 50 MB/s 60 MB/s - - - /scratch 20 MB/s 2) 400 MB/s 60 MB/s - - - 1) new disk (SATA at average performance) 2) old disk (IDE) HRSK filesystems - bandwidth Wie viele Bytes bekommt man pro Sekunde auf die Platten Je mehr, desto besser Alle Zahlen sind für den gesamten Rechner PC mars 1 stripe 2 stripes 16 stripes 48 stripes /fastfs - 10 GB/s 4 GB/s 4 GB/s 4 GB/s 4 GB/s /work - 10 GB/s 4 GB/s 4 GB/s 4 GB/s - /tmp 58 MB/s 200 MB/s 43 GB/s *) - - - /scratch 20 MB/s 1,6 GB/s 43 GB/s *) - - - *) 728 Knoten * 60 MB/s pro lokaler Platte
HRSK file systems - I/O Operationen pro Sekunde Gemessen als: Wieviel Dateien kann man pro Sekunden anlegen/löschen? Je mehr, desto besser PC mars 1 stripe 2 stripes 16 stripes 48 stripes /fastfs - 50 4086 3869 627 60 /work - 50 3128 3279 654 48 /tmp 28961 3132 5563 - - - /scratch 1364 1048 5563 - - - Paralleles I/O Bandbreite auf mars I/O with different block sizes and processes 10000.0 throughput in MB/s 1000.0 100.0 10.0 1.0 0.1 1 4 16 64 1 10 100 1000 10000 100000 1000000 0.0 block size in byte
Paralleles I/O Parallele Effizienz parallel efficiency for writing with parallel processes 1.20 parallel efficiency 1.10 1.00 0.90 0.80 0.70 0.60 0.50 0.40 0.30 4 16 64 0.20 0.10 0.00 1 10 100 1000 10000 100000 1000000 block size in bytes 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 grossen Blöcken sequentieller Output von größeren Blöcken Lesen eines Teils der Datei, invalidieren des Hauptspeichers und zurückschreiben sequentieller Input von 1 Byte und größeren Blöcken zufälliges Lesen von Blöcken und in 10% der Fälle zurückschreiben von neuen Daten wieviele Anzahl von Dateien könen pro Sekunde erstellt/gelöscht werden Ergebnisse als *.cvs Dateien 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 keine festes Set an Tests duch Script steuerbar C und Python Code testet auch: MPI I/O HDF5 parallele netcdf 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 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 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 200 0 proc/blade 4 proc/blade 1-2 16 32 48 64 128 256 384 512 #processes spiobench @ Indiana University - second write 1000000 100000 MB/s 10000 1000 100 10 1 proc/blade 4 proc/blade 1-2 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 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 Messprogrammes Tasks pro CPU Blockgrößen Zugriffsmuster auf Hauptspeicher Wiederholungen von Messungen