tl;dr - Mein ZFS RAIDZ2-Array liest mit 7,5+ GB/s und schreibt mit 2,0+ GB/s, wenn ich bs=128Kmit a oder höher angebe dd. OS X geht von 1K aus (gemäß stat -f %k .) und mein gesamtes Array liegt bei ~300 MB/s; ddbietet die gleiche Leistung mit bs=1k. Sogar ein Array bs=4kbietet 1,1 GB/s mit dd.
Was kann ich tun, um die allgemeine E/A auf mindestens 1 GB/s zu verbessern?
--
Einzelheiten:
Ich verwende ein 16-Laufwerke SATA3 RAIDZ2 OpenZFS auf OSX (v1.31r2) Dateisystem (v5000) über Thunderbolt 2 (zwei Areca 8050T2) auf einem 12-Core 64 GB Mac Pro.
Das ZFS-Dateisystem wurde mit ashift=12(Advanced Format HDDs mit 4096-Byte-Blöcken) und einem erstellt recordsize=128k.
Ich sehe Übertragungsraten von etwa 300 MB/s vom Array in OS X und vom Terminal unter Verwendung der Standardbefehle (beachten Sie, dass die zu kopierende Datei 10 GB zufällige Daten umfasst):
Normale Kopie:
Titanic:lb-bu admin$ time cp big-test.data /dev/null
real 0m23.730s
user 0m0.005s
sys 0m12.123s
≈ 424 MB/s
--
ddmit bs=1k:
Titanic:lb-bu admin$ time dd if=./big-test.data of=/dev/null bs=1024
9841180+0 records in
9841180+0 records out
10077368320 bytes transferred in 32.572506 secs (309382653 bytes/sec)
real 0m32.575s
user 0m1.880s
sys 0m30.695s
≈ 309 MB/s
--
ddmitbs=4k
Titanic:lb-bu admin$ time dd if=./big-test.data of=/dev/null bs=4096
2460295+0 records in
2460295+0 records out
10077368320 bytes transferred in 8.686014 secs (1160183301 bytes/sec)
real 0m8.688s
user 0m0.460s
sys 0m8.228s
≈1,16 GB/s
--
ddmit bs=2m:
Titanic:lb-bu admin$ time dd if=./big-test.data of=/dev/null bs=2m
4805+1 records in
4805+1 records out
10077368320 bytes transferred in 1.162891 secs (8665788130 bytes/sec)
real 0m1.165s
user 0m0.003s
sys 0m1.162s
≈8,67 GB/s
--
OS X's read of the boot drive optimal I/O block size (1TB SSD, HFS+):
Titanic:lb-bu admin$ stat -f %k /
4096
--
OS X's read of the array's optimal I/O block size (16-drives RAIDZ2, ZFS):
Titanic:lb-bu admin$ stat -f %k .
1024
--
Ich habe neben dem Dateisystem auch ein ZFS-Volume im Pool erstellt und als HFS+ formatiert. Ich habe die gleiche Leistung wie oben erzielt.
Ich laufe ~20-30x unter dem Optimum! Was übersehe ich? Irgendwelche Ideen?
--
Update: Hohe Geschwindigkeiten wurden bei I/O zwischengespeichert (danke @yoonix). Geschwindigkeiten von ≈300 MB/s scheinen für diese Hardware immer noch zu langsam.
@qasdfdsaq: Die CPU-Auslastung während der E/A ist vernachlässigbar (alle Kerne < 5 %).
zfs erhält die gesamte Ausgabe:
NAME PROPERTY VALUE SOURCE
lb-bu type filesystem -
lb-bu creation Tue Sep 30 16:41 2014 -
lb-bu used 36.8T -
lb-bu available 10.0T -
lb-bu referenced 138M -
lb-bu compressratio 1.00x -
lb-bu mounted yes -
lb-bu quota none default
lb-bu reservation none default
lb-bu recordsize 128K default
lb-bu mountpoint /Volumes/lb-bu local
lb-bu sharenfs off default
lb-bu checksum on default
lb-bu compression lz4 local
lb-bu atime on default
lb-bu devices on default
lb-bu exec on default
lb-bu setuid on default
lb-bu readonly off default
lb-bu zoned off default
lb-bu snapdir hidden default
lb-bu aclmode discard default
lb-bu aclinherit restricted default
lb-bu canmount on default
lb-bu xattr on default
lb-bu copies 1 default
lb-bu version 5 -
lb-bu utf8only on -
lb-bu normalization formD -
lb-bu casesensitivity insensitive -
lb-bu vscan off default
lb-bu nbmand off default
lb-bu sharesmb off default
lb-bu refquota none default
lb-bu refreservation none default
lb-bu primarycache all default
lb-bu secondarycache all default
lb-bu usedbysnapshots 0 -
lb-bu usedbydataset 138M -
lb-bu usedbychildren 36.8T -
lb-bu usedbyrefreservation 0 -
lb-bu logbias latency default
lb-bu dedup off default
lb-bu mlslabel none default
lb-bu sync standard default
lb-bu refcompressratio 1.01x -
lb-bu written 138M -
lb-bu logicalused 36.8T -
lb-bu logicalreferenced 137M -
lb-bu snapdev hidden default
lb-bu com.apple.browse on default
lb-bu com.apple.ignoreowner off default
lb-bu com.apple.mimic_hfs off default
lb-bu redundant_metadata all default
lb-bu overlay off default
Antwort1
Sie haben das nicht gepostet, zpool statusaber Sie deuten in dem Post an, dass sich alle 16 Festplatten in einem einzigen vdev in RAIDZ2 befinden. Obwohl dies eine gute, sichere Konfiguration ist, müssen Sie verstehen, dass RAIDZ nicht in erster Linie auf Geschwindigkeit ausgelegt ist. Es ist so konzipiert, dass es nahezu kugelsicher ist. RAIDZ2 ist analog zu RAID6, aber die Variante hat Funktionen, die es langsamer und sicherer machen.
Sehendieser nette Artikelfür alle Einzelheiten, aber diese beiden Zitate sollten Ihnen helfen, das Problem zu erkennen (Hervorhebung von mir):
Beim Schreiben auf RAID-Z-vdevs wird jeder Dateisystemblock in einen eigenen Streifen über (potenziell) alle Geräte des RAID-Z-vdevs aufgeteilt. Das bedeutet, dass jeder Schreib-E/A warten muss, bis alle Festplatten im RAID-Z-vdev fertig geschrieben sind. Aus der Sicht einer einzelnen Anwendung, die auf den Abschluss ihres E/A wartet,Sie erhalten die IOPS-Schreibleistung der langsamsten Festplatte im RAID-Z-vdev.
Beim Lesen von RAID-Z-vdevs gelten die gleichen Regeln, da der Prozess im Wesentlichen umgekehrt ist (keine Round-Robin-Abkürzung wie beim Spiegeln): Bessere Bandbreite, wenn Sie Glück haben (und auf die gleiche Weise lesen, wie Sie geschrieben haben)und die IOPS-Leseleistung einer einzelnen Festplatte in den meisten wichtigen Fällen.
Tatsächlich haben Sie 16 Laufwerke mittlerer Geschwindigkeit und warten bei jedem Schreibvorgang, bis sich alle 16 Laufwerke beim Controller gemeldet und „fertig“ gemeldet haben, bevor der nächste Schreibvorgang beginnt. Bei 16 Festplatten müssen Sie effektiv immer auf eine nahezu vollständige Festplattenrotation warten, bevor Sie einen der Schreibvorgänge durchführen können. Sie werden also durch die Physik und die Art und Weise aufgehalten, wie ZFS Daten festlegt.
Das Schreiben einzelner Prozesse/Threads ist für ZFS im Allgemeinen nicht optimal. Das gleichzeitige Ausführen mehrerer kleiner Lese-/Schreibaufgaben für Daten könnte zu besseren IOPS-Zahlen führen, aber ich denke, die Physik von ZFS ist Ihr Hauptproblem.
Wenn Sie bereit sind, Speicherplatz zu opfern, wäre die Spiegelung wahrscheinlich schneller. Sie könnten auch eine geringfügig bessere Leistung von ZFS erzielen, indem Sie im Pool 2 RAIDZ2-vdevs mit 8 Festplatten erstellen, anstatt 1 RAIDZ2-vdev mit 16 Festplatten. Auch das kostet nutzbaren Speicherplatz, kann aber dazu beitragen, dass die Commits schneller erfolgen.
Leider habe ich keine guten Nachrichten für Sie.