RaidZ2 Perfomance-Test mit und ohne ZIL / L2ARC

M

m4rkus

Well-Known Member
Hallo,

ich habe meinen Server auf FreeBSD migriert und bin gerade dabei den ZFS-Datenpool zu erstellen und zu testen.

Dazu habe ich 6 x 3 TB Festplatten hergenommen und mittels gnop (4k) zu einem RaidZ2 zusammengeführt.
Bevor ich ZIL und L2ARC hinzufüge (jeweils zusätzliche Partitionen der System-SSDs) habe ich mal versucht mit bonnie++ einen Benchmark zu erstellen.

Bei der Einrichtung bin ich folgendermaßen vorgegangen:
Anlegen fester Partitionsgrößen (teilweise unterscheiden sich die ja je nach Festplatte)
gpart create -s GPT da0
gpart create -s GPT da1
gpart create -s GPT da2
gpart create -s GPT da3
gpart create -s GPT da4
gpart create -s GPT da5
gpart add -b 2048 -s 5860333168 -t freebsd-zfs -l data00 da0
gpart add -b 2048 -s 5860333168 -t freebsd-zfs -l data01 da1
gpart add -b 2048 -s 5860333168 -t freebsd-zfs -l data02 da2
gpart add -b 2048 -s 5860333168 -t freebsd-zfs -l data03 da3
gpart add -b 2048 -s 5860333168 -t freebsd-zfs -l data04 da4
gpart add -b 2048 -s 5860333168 -t freebsd-zfs -l data05 da5

4k-Thematik
gnop create -S 4096 /dev/gpt/data00
gnop create -S 4096 /dev/gpt/data01
gnop create -S 4096 /dev/gpt/data02
gnop create -S 4096 /dev/gpt/data03
gnop create -S 4096 /dev/gpt/data04
gnop create -S 4096 /dev/gpt/data05
zpool create zdata raidz2 /dev/gpt/data00.nop /dev/gpt/data01.nop /dev/gpt/data02.nop /dev/gpt/data03.nop /dev/gpt/data04.nop /dev/gpt/data05.nop
zpool export zdata
gnop destroy /dev/gpt/data00.nop /dev/gpt/data01.nop /dev/gpt/data02.nop /dev/gpt/data03.nop /dev/gpt/data04.nop /dev/gpt/data05.nop
zpool import zdata
zdb -C zdata | grep ashift => Hier steht 12!

Leider werde ich nicht ganz schlau aus den Werten.
Bildschirmfoto 2014-01-02 um 14.12.36.webp

Ist die Lese- und Schreibgeschwindigkeit jetzt so ca. 450-500 MB/s?
Ist es problematisch, dass die CPU-Belastung teilweise so hoch ist?

Ich habe einen Core i7 2600k, 32 GB RAM und einen auf den IT-Mode geflasheden IBM 1015.

Danke und Gruß
Markus

PS: Die Messergebnisse nach Hinzufügen der Caches reiche ich natürlich nach - wollte erstmal hören, ob ich bei der Erstellung evtl. etwas falsch gemacht habe...1
 
Vorweg sei gesagt, dass du durch die ZIL nur im Falle vieler synchroner Schreibaufträge einen Unterschied sehen wirst. Ob bonnie++ die produziert, weiß ich nicht. Der L2ARC benötigt einige Zeit warmzulaufen, was unter Umständen im Benchmark ebenfalls nicht zu sehen. Warten wir mal ab, was die Ergebnisse so sagen.

Das Setup sieht gut aus. Ab 10.0 wird der gnop-Trick nicht mehr notwendig sein, da dort endlich 4k korrekt erkannt und behandelt wird. Allerdings natürlich so lange, wie die Festplatte sich entweder als 4k-Laufwerk identifiziert (ich hoffe, dass nach dem Ende von Windows XP im April mehr Hersteller damit beginnen) oder der Kernel einen entsprechenden Quirk besitzt. Da der Kernel ganze Serien erkennt und entsprechend behandelt, sollte das in den meisten Fällen kein Problem sein.

Du erreicht im sequentiellen Schreiben ~500MB/s und im sequentiellen Überschreiben ~260MB/s. Sequentiell Lesen erreicht ~550MB/s. Die zufälligen Zugriffszeiten sind mit ~200ms typisch für ein RAID eher im unteren Bereich. Das spiegelt sich auch beim sequentiellen und zufälligen von Dateien wieder. Das ist halt die Crux mit RAIDs. Sie müssen mechanische Platten koordinieren, was deren miese Zugriffszeiten potenziert. Daher in meinen Augen alles okay.

Die CPU-Leistung ist so eine Sache. Generell misst bonnie++ meines Wissens die Gesamtauslastung des Systems. Da sind also sein eigener Verbrauch und der Interrupt-Overhead des Controllers mit drin. Daher ist keine generelle Aussage möglich. Allerdings ist RAIDZ2 nun einmal eine Software-RAID-Lösung, die alle Berechnungen auf der CPU ausführen muss. Das braucht schon etwas Futter. Wenn die CPU langsam ist, kann man dort in Extremsituationen wie Benchmarks auch schon mal >50% Last sehen.
 
Die Zugriffszeitem im realen Betrieb hoffe ich ja mit den SSD-Caches verbessern zu können, die CPU wird denke ich dann erstmal reichen.

Danke für die ausführliche Antwort - ich werde dann mal die SSD-Partitionen hinzfügen und einfach mal testen.

Gruß
Markus
 
Die Doku meint dazu:
Before explaining each of the numbers, it should be noted that the columns below labeled %CPU may be misleading on multiprocessor systems. This percentage is computed by taking the total CPU time reported for the operation, and dividing that by the total elapsed time. On a multi-CPU system, it is very likely that application code and filesystem code may be executing on different systems. On the final test (random seeks), the parent process creates four child processes to perform the seeks in parallel; if there are multiple CPUs it is nearly certain that all will be involved. Thus, these numbers should be taken as a general indicator of the efficiency of the operation relative to the speed of a unit unit CPU. Taken literally, this could make a machine with 10 50-horsepower CPUs appear less efficient than one with one 100-horsepower CPU.
Zum Vergrößern anklicken....
 
Du könntest auf das "raidz2" verzichten, wenn du den ZPOOL so anlegst:
Code: 
zpool create -f test raidz1 /data/zfs1.img /data/zfs2.img /data/zfs3.img raidz1 /data/zfs4.img /data/zfs5.img /data/zfs6.img
Sollte dann etwa so aussehen:
Code: 
root@vh6 /data # zpool status test
  pool: test
 state: ONLINE
  scan: none requested
config: 

        NAME                STATE     READ WRITE CKSUM
        test                ONLINE       0     0     0
          raidz1-0          ONLINE       0     0     0
            /data/zfs1.img  ONLINE       0     0     0
            /data/zfs2.img  ONLINE       0     0     0
            /data/zfs3.img  ONLINE       0     0     0
          raidz1-1          ONLINE       0     0     0
            /data/zfs4.img  ONLINE       0     0     0
            /data/zfs5.img  ONLINE       0     0     0
            /data/zfs6.img  ONLINE       0     0     0
Nachteil: Wenn es dir hier die HDs "zfs5" und "zfs6" zerscheppert, hast du ein Problem, da du nur 1 redundante HD im "raidz" hat aber dafür ist es vielleicht schneller. Zumindest ein rebuild geht viel schneller, da er nur das "raidz1-X" neu aufbauen muss.
 
Da habe ich zu Beginn auch drüber nachgedacht.
Ich wollte den Ausfall von zwei Festplatten abgedeckt haben. Die geplante Erweiterung in der "Zukunft" sieht dann so aus, dass ich 6 weitere Festplatten mit 3 TB (die dann hoffentlich günstiger sind) in ähnlicher Weise hinzufüge, wie in deinem Beispiel.

Gruß
Markus
 
Hey, ich habe da mal ein Korn Shell Script gefunden, dass zum ZIL Statistiken ausgibt...

Viel Spass damit - ich konnte damit anschaulich sehen, das über NFS massiv das ZIl genutzt wird und damit Performance verlorengeht...

Viele Grüße, Norbert
 

Anhänge

In wieweit geht denn die Performance verloren? Ich dachte als schneller SSD-Schreibcache sollte das schneller gehen...

Gruß
Markus
 
Ich glaube, er meinte es anders herum: Ohne Log-Device liegt die ZIL im Pool selbst und da NFS sie massiv nutzt, geht in dem Fall Performance verloren.
 
Nun, ja, teilweise... Ich habe das unter Solaris mal getestet, mit separaten log devices auf 2 Festplatten. Dabei wurden ca. 25000 "Klein"-Dateien angelegt (mit ein paar Bytes) und sofort danach alle gelöscht. Das geht lokal auf einem Server weit mehr als 100 mal schneller. Remote dauert das ganze dann Minuten. Und da habe ich das zilstat.ksh Script mal genutzt und gesehen, dass remote enorm viel ins ZIL geschrieben worden ist. Ich denke, wenn ich SSD fürs ZIL nutzen würde, wäre das ganze wohl schneller, bezweifle, dass es aber nahe an die Performance kommt, als wenn es lokal auf dem Server gemacht wird. Klaro ist alles übers Netzt langsamer als lokal ;-)

Viele Grüße, Norbert
 
Mmh. Was wären denn Tests, die interessant sind?
Den von Norbert angesprochenen Fall mit x0000 kleinen Dateien habe ich nicht. Den bonnie+-Auszug fand ich ganz aufschlussreich.

Ansonsten muss ich jetzt die Tage mal schauen, wie sich die Performance so verhält, wenn ich anfange die File-Server-Funktionalität, ein paar Jails, sowie ein paar VMs (Virtualbox) starte.
iSCSI wollte ich dann auch noch testen.

Gruß
Markus
 
Hey,

Für mich ist das schon interessant, das mit den vielen Dateien... Denn Software, die hier im Umfeld der Bioinformatik genutzt wird, hat manchmal die Tendenz, haufenweise kleine Dateien zu erzeugen... Ich hatte Fälle, wo Leute innerhalb von kurzer Zeit hunderttausende Dateien produziert hatten...

Grüße, Norbert

PS: falls es Dich interessiert, ich hatte testweise folgendes Script laufen lassen
 

Anhänge

Ich schau mal, dass ich das Teste, wenn ich das NAS per NFS an meinen übrigen Rechnern habe.

Gruß
Markus
 
Du musst dich einloggen oder registrieren, um hier zu antworten.
Zurück
Oben