Login
Login-Name Passwort


 
Newsletter
Werbung

Mo, 14. Juni 2010, 17:00

Netzwerk-Dateisysteme im Vergleich

Die Autoren von remotefs erheben den Anspruch, ein schnelles Netzwerk-Dateisystem geschaffen zu haben. Diese Behauptung soll hier belegt werden.

Einleitung

Um Dateisysteme zu vergleichen, sind verschiedene Aspekte zu berücksichtigen. Neben der reinen Funktionalität (POSIX-Rechte, ACL, Unterstützung für Links usw.) ist die Geschwindigkeit auch ein Aspekt, der betrachtet werden muss.

Die erste Frage ist, wie die Performance objektiv beurteilt werden kann. Es existieren Suiten, die die Durchführung von synthetischen Tests erlauben. Ob diese Tests auch immer geeignete Ergebnisse liefern, ist fraglich, zumal vorwiegend die Übertragungsrate für Dateien ermittelt wird. Das Auflisten aller Dateien, inklusive deren Eingenschaften (Eigentümer, Größe,...), die sich in einem Verzeichnis befinden, wird nie durchgeführt. Laut manchen Autoren sind alle bekannten Testsuiten für Netzwerkdateisysteme mehr oder weniger fehlerhaft. Zudem können durch geeigneten Wahl der Parameter die Ergebnisse zur Gunsten des einen oder anderen Systems beeinflusst werden.

Neben solchen Tests sollten auch einfache Tests wie das Auflisten des Inhaltes eines Verzeichnisses oder das Lesen der EXIF-Daten aller Bilder, die im Verzeichnis gespeichert sind, erfolgen. Hier kann eher die gefühlte Geschwindigkeit des Netzwerk-Dateisystems ermittelt werden.

Um gute Performance auf leistungsschwacher Hardware zu erreichen, des heißt auf Hardware, die eine geringe CPU-Leistung und wenig RAM aufweist, kann das Mittel »Caching«, d.h. Daten für den hypothetischen Fall, dass sie gebraucht werden, im Speicher halten, nicht die Lösung sein.

Der Hauptansatz von remotefs ist eine optimierte Netzwerk- und Hardware-Einbindung. Für spezielle Fälle werden Client-seitig manche Daten gehalten, dies aber nur für sehr kurze Zeit. Wenn z.B. der Inhalt eines Verzeichnisses ausgelesen wird, wie beim Absetzen des Kommandos ls -l oder beim Darstellen der Dateien in einem Dateimanager, werden Daten auf Verdacht gesammelt und übertragen. Damit können Wartezeiten drastisch verkürzt werden.

Postmark

Postmark ist ein synthetischer Test, welcher versucht, entsprechend der zu erwartenden Belastung bei einem News- oder Mail-Server die Performance zu messen.

Sek. Transaktionen/s KB/s
Dauer Create read append delete read write
glusterfs 49 125 50 51 280 290.30 357.19
cifs 47 125 48 69 264 307.05 377.80
remotefs 26 250 97 104 560 550.57 677.43
remotefs 2 25 250 98 101 560 570.34 701.63
nfs 19 500 129 133 560 760.31 935.50

Die Defaultwerte für den Test wurden, bis auf den Anzahl von Dateien, die von 500 auf 5000 erhöht wurde, verwendet.

The base number of files is 500
Transactions: 5000
Files range between 500 bytes and 9.77 kilobytes in size
Block sizes are: read=512 bytes, write=512 bytes
Biases are: read/append=5, create/delete=5
Using Unix buffered file I/O
Random number generator seed is 42

Da NFS intensives Caching auf der Client-Seite verwendet, wurden zwei Tests mit remotefs durchgeführt. Bei der Zeile remotefs 2 wurde Kernel-Caching eingeschaltet.

Cifs und glusterfs weisen die schechtesten Werte auf. Remotefs gewinnt geringfügig an Performance durch Einschalten des Kernel-Caching und ist nicht so gut wie NFS.

Da die Dateigröße auch eine Rolle spielt, wurde anstelle der Anzahl der Dateien die Dateigröße um den Faktor 100 erhöht.

Sek. Transaktionen/s MB/s
Dauer Create read append delete read write
nfs 163 2 1 1 164 4.03 12.02
remotefs 177 3 1 1 246 4.31 12.84
remotefs 2 161 3 1 1 492 4.55 13.56

Remotefs schneidet hier besser als NFS ab.

Bonnie++

Bonnie++ misst einerseits die Transferrate, anderseits den Anzahl von Dateien, die angelegt oder entfernt werden. Die Ergebnisse wurden auf zwei Tabellen verteilt. Da der Server 128 MB RAM besitzt, wurde, um Caching-Effekte auf der Server-Seite zu eliminieren, bonnie++ mit den Parametern -r128 -s256 aufgerufen.

Sequential Output Sequential Input Random Seeks
Size:Chunk Size Per Char Block Rewrite Per Char Block
K/sec % CPU K/sec % CPU /sec % CPU K/sec % CPU K/sec % CPU / sec % CPU
cifs 256M 7300 33 8567 7 8080 4 10798 31 +++++ +++ 210.1 1
nfs 256M 12187 30 13312 2 15109 3 59638 98 +++++ +++ 3035.4 2
glusterfs 256M 12303 31 13851 2 15198 3 60737 99 +++++ +++ 2856.9 3
remotefs 256M 17685 43 18487 4 9348 3 20582 54 20061 2 571 1
remotefs 2 256M 18241 45 18650 4 19583 5 59261 99 +++++ +++ 8437.5 4

Die Transferrate, die angezeigt wird, ist zum Teil zweifelhaft, alles oder fast alles erfolgt auf den Client. Manche Werte sind sehr hoch, bezeichnend ist auch, dass die CPU-Leistung des Clients fast zu 100% ausgenutzt wird.

Auch hier ist remotefs zweimal zu finden. Wie beim Postmark Test wurden FUSE-Optimierungs-Optionen eingeschaltet. Daraus ist ersichtlich, dass internes Caching eine große Rolle spielt.

Erstaunlicherweise sind bei diesem Test NFS und glusterfs gleich gut. Dies entspricht nicht den Ergebnissen des vorgehenden Tests. Die Rahmenbedingungen sind auch ganz anders.

Remotefs ist scheinbar (remotefs 2) besser als NFS, welches bei den Tests zuvor Klassenprimus war.

Num File Sequential Create Random Create
Create Read Delete Create Read Delete
/ sec % CPU / sec % CPU / sec % CPU / sec % CPU / sec % CPU / sec % CPU
cifs 16 165 2 918 3 330 2 163 2 1204 3 344 2
nfs 16 411 4 2690 12 488 5 415 4 3177 13 479 4
glusterfs 16 399 4 2740 12 477 4 404 5 3172 13 469 4
remotefs 16 363 2 2806 2 599 1 369 2 2275 2 571 1
remotefs 2 16 377 2 2911 2 621 1 368 1 2026 2 553 1

Die Ergebnisse dieser Tabelle entsprechen wie zuvor nicht den Erkenntnissen des Postmark-Tests. NFS und glusterfs weisen recht ähnliche Werte auf, cifs ist weit abgeschlagen.

Kommentare (Insgesamt: 28 || Alle anzeigen || Kommentieren )
Re: Waah (jjsa, Di, 22. Juni 2010)
Re: Waah (Incredible, Mo, 21. Juni 2010)
Waah (Incredible, Mo, 21. Juni 2010)
Re: Warum keine Hardware aus dem 21.Jhd? (jjsa, Sa, 19. Juni 2010)
Re[6]: Netzwerk Filesysteme unter Unix = Epic Fail (jjsa, Sa, 19. Juni 2010)
Pro-Linux
Pro-Linux @Facebook
Neue Nachrichten
Werbung