ZFS/NFSv4: mit RAIDZ1 unterirdische Performance: 3 MB/s!

[Eisenfaust]

Vorab:

- ja, ich habe bereits nach einer Lösung gegrugelt (ZFSTuningGuideWiki)
- je, ich habe bereits diverse vfs.zfs.XXX MIBs durchprobiert

Problem: ich betreibe zwei Server, (A) ein relativ "kleines" Interim-Storage-System mit 16 GB RAM und einer 2-Kern Ivy-Bridge CPU sowie einem RAIDZ1 bestehend aus 3 mal 3 TB Platten. (B) Der zweite Server ist eine etwas ältere 4-Kern CPU (Q6600) mit 8 GB RAM. An dieser MAschine werden 5 Platten a 3 TB in einem RAIDZ1 betrieben.

Auf beiden Systemen habe ich FreeBSD 10 installiert (FreeBSD 9.1-PRE, das vorher installiert war, hatte die gleichen Probleme!). Die "Pools" tragen diverse Dateisysteme, die ich per NFSv4 an Linux- und FreeBSD-Hosts exportiere.

Durch die unter den "Tuning Tricks" angegebenen Verfahren konnte ich auf Maschine (B) immerhin "Burst" Transferleistungen von 45 - max 50 MB/s erreichen.

Wende ich die selben Parameter auf Host (A) an, der über mehr RAM und die modernere Architektur verfügt, bleibt die Transferleistung bei sage und schreibe 3 MB/s maximal.

Die Rechner sind über GBit LAN angebunden/gswitcht. Mit diversen Tools kann man eine Bandbreite von gut 90 MB/s bescheinigen.

Nun, die Bandbreite von knappen 50 MB/s "Burst" finde ich nun nicht berauschend, zumal wir divesre Linux/CentOS Server betreiben, die ebenfalls Arrays via NFSv4 exportieren und ich mit diesen Maschinen durchaus 70 - 75 MB/s erreichen kann - kontinuierlich! Unter FreeBSD/ZFSv28 kommt es zu diesen "Bursts", wie sie vielfach beschrieben werden, und nur dann wird die maximale Bandbreite erreicht, zwischen diesen Bursts ist alles "ruhig".

Warum trotz der gleichen Tuningoptionen auf der besseren Hardware, aber dem kleineren RAIDZ1, die Leistung auf unterirdischen 3 MB/s bleibt - wohlgemerkt, Bursts, zwischen solchen tut sich nichts, so daß ich nach dem Ende eines Transferzykluses auf nett 1,3 bis max. 3 MB/s komme - ist mir ein Rätsel und verlangt im Moment von mir starke Nerven, nicht doch mal Linux einzusetzen.

Hat jemand Erfahrungen mit ZFS in dieser Hinsicht gemacht?

Aus diversen Foren und eben dem "offiziellen" ZFS Tuning Wiki (wo man offenbar selber nicht so recht weiß, was ZFS eigentlich macht, wenn ich diese ARC Diskussion verfolge), habe ich folgende Parameter verwendet:

/boot/loader.conf:
# ZFS
vfs.zfs.l2arc_noprefetch=1 # see wiki (*)
vfs.zfs.l2arc_write_max=209715200 (*)
vfs.zfs.l2arc_write_boost=335544320 (*)
vfs.zfs.cache_flush_disable=1 # NFSv4 Problemloesung

(die mit (*) markierten MIBs habe ich permutiert, mit wenig Erfolg, die hier gezeigten Werte sind die letzten verwendeten Parameter).

/etc/sysctl.conf:

# ZFS
vfs.zfs.write_limit_override=1073741824 # 1GB

[mark05]

hi

also , grundsaetzlich habe ich die erfahrung gemacht das das ganze tuning
nicht noetig ist wenn genug ram vorhanden ist.

wenn nfs stark genutzt wird ,sollte man darueber nachdenken
zil auf externe platten ( ssd ) zu legen , genauso fuer den read ein cache lw.

wie wurde gemessen ?

mit bonnie direkt auf der maschine oder via lan ?

ist die locale maschine , falls via lan gemessen wurde , ueberhaupt in der
lage mehr als 50 MB/s zuschreiben.

hat der der der das nfs zuverfuegung stellt , noch andere , ev. io intensive, aufgaben ?

holger

[Columbo0815]

Ich meine mich zu erinnern dass kürzlich 2 Personen im irc genau das Thema hatten. ZFS und NFSv4 mit grauseliger Performance. Yamagi war eine betroffene Person. Ich bin mir fast sicher, dass er sich zu Wort meldet :-D

Mehr kann ich leider nicht dazu beitragen.. :-P

[Yamagi]

Ich bin gerade ein wenig in Eile, aber einmal kurz zusammengefasst:

- Damit NFS4 korrekt auf ZFS läuft, müssen alle Datasets zwischen dem Root und dem exportierten Dateisystem ebenfalls exportiert sein. Das steht leider noch nicht in der Doku, Rick sagte aber, dass er an einer Aktualisierung der Manpages arbeitet. Wenn also /usr/home exportiert werden soll und ein eigenes Dataset ist, müssen auch / und /usr exportiert werden. Alternativ kann man /usr/home als NFS4-Root setzen. Tut man es nicht, geschehen seltsame Dinge wie plötzlich verschwindende Dateien.

- Das der NFS4-Mount sich bei Schreiboperationen aufhing, war ein weiterer Hardwarebug der guten Attansic L1 NIC. Das Ding gehört zwar zu den besseren Billig-NICs, aber ich habe dennoch aufgehört zu zählen, wie viele Fehler der Chip hat. Leider kann ich keine andere NIC einbauen, da ich keinen Platz habe. Wie dem auch sei, der Bug ist in 10-CURRENT r242348 per treiberseitigem Workaround gefixt. Die Revision kann problemlos auf 9.2-RC3 angewandt werden.

- Zum ZFS hat mark05 schon alles wichtige gesagt. Man sollte nicht tunen, denn die Standardwerte sind schon gut gesetzt. Um ZFS performant über Netzwerkdateisysteme nutzen zu können, ist ein schnelles Log-Device (ZIL-Device) in Form einer SSD zwingend notwendig. Zum Beispiel hat meine Testmaschine (Phenom II X4 940, eine Platte) ohne ZIL maximal ~30MB/s durchgesetzt, mit ZIL flutschen da ~92MB/s durch.

[Eisenfaust]

Moin.

Zuvorderst Danke für die Antworten.

@mark05: "Gemessen" wird und wurde mit der systat-Anzeige sowie handgestoppte Zeiten, wenn anderes nicht möglich ist. Die Experimente unter FreeBSD sind mit ZFS-exportiertem Dateisystem sowie mit einem auf UFS2-basierendem Dateisystem gemacht worden.

RAM: 16 GB RAM (oder 8 GB RAM) werden selbst von den Entwicklern als ausreichend gesehen. Eine meiner Workstations verfügt über 32GB RAM - mehr haben leider nur unsere Linux Systeme (96 und 128 GB).

@Yamagi: Merci. Nun, die Sache mit dem ZIL ist mir bekannt - leider hat mein Labor-Server keinen SATA-Port mehr am primären SATA-Controller Chip frei! Ich habe zwar eine sekundäre SATA Karte in dem System, aber ich habe meine Bedenken bezüglich Stabilitat et cetera. Für die andere Maschine, die mit dem kleineren RAID, ziehe ich diese Überlegnung allerdings jetzt ernstahft in Erwägung, denn zwischen 30 - 50 MB/s und fast 100 MB/s liegt doch schon ein Unterschied ;-).

Diese NFSv4-Sache werde ich jetzt mal angehen! ich habe / als root exportiert, so wie in der Doku angegeben. Allerdings sind meine Pools auf /pool/XXXX gebunden, was Deinem erwähnten Beispiel schon verdächtig nahe kommt.

Zu den Standardwerten möchte ich noch was sagen: Eben genau MIT diesen Standardwerten erhalte ich ja die genannte schlechte Leistung und 16 GB RAM halte ich nun nicht für so wenig, daß ein kleines, aus nur drei Platten bestehendes RAIDZ1, sofort an die Systemgrenzen stößt. Primär geht es hier um eine Optimierung der NFSv4 Leistung, nicht das ZFS Dateisystem in direkter Anbindung an den Host.

[pit234a]

Kann Linux inzwischen ZFS?
Oder würdest du das anders versuchen, also auch alle aufgelaufenen Daten erst mal zwischenlagern um dann in einen "neuen Pool" unter Linux zu kopieren?

Ich frage das aus persönlichem Interesse, nicht, weil ich da eine Lösung des Problems erkennen könnte.
Wenn ein Umstieg auf Linux einfach wäre, würde ich das an deiner Stelle aber in jedem Fall testen, denn die gewonnen Erkenntnisse könnten hilfreich sein.
Den Stand von "ZFS-kompatiblen" OpenSource-Systemen habe ich auch aus dem Blick verloren, aber statt Linux wäre ein solches dann vielleicht erste Wahl, für einen entsprechenden Test. Früher gab es mal OpenSolaris und ich lese nun von OpenIndiana oder so etwas, habe aber nie wirklich hingeschaut.

[Crest]

Die Lösung ist einfach: NFSv4 braucht für jede COMMIT Message ein fsync() und Clients senden sie häufig. Also muss fsync() schnell sein. 150 IOPS pro Platte reichen da nicht. Kaum ist das ZIL auf SSDs hat man schnelles NFSv4 mit korrekter Semantik.

[mark05]

Zitat von pit234a

Kann Linux inzwischen ZFS?
Oder würdest du das anders versuchen, also auch alle aufgelaufenen Daten erst mal zwischenlagern um dann in einen "neuen Pool" unter Linux zu kopieren?

Ich frage das aus persönlichem Interesse, nicht, weil ich da eine Lösung des Problems erkennen könnte.
Wenn ein Umstieg auf Linux einfach wäre, würde ich das an deiner Stelle aber in jedem Fall testen, denn die gewonnen Erkenntnisse könnten hilfreich sein.
Den Stand von "ZFS-kompatiblen" OpenSource-Systemen habe ich auch aus dem Blick verloren, aber statt Linux wäre ein solches dann vielleicht erste Wahl, für einen entsprechenden Test. Früher gab es mal OpenSolaris und ich lese nun von OpenIndiana oder so etwas, habe aber nie wirklich hingeschaut.

linux wird nie richtig zfs koennen da die lizenzen nicht kompatibel sind .

die ansaetze die es gibt sind via fuse und neu schreiben , somit zz keine alternative
da langsam und nicht stabil.

holger

[Lord_x]

Zitat von mark05

linux wird nie richtig zfs koennen da die lizenzen nicht kompatibel sind .
die ansaetze die es gibt sind via fuse und neu schreiben , somit zz keine alternative
da langsam und nicht stabil.
holger

Sorry stimmt nicht! Linux hat eine sehr gute Kernel- Unterstützung von ZFS!
Das Problem ist die Lizenz sonst wäre das schon lange im Kernel...

http://zfsonlinux.org/

Fakt ist einfach, dass Oracle wieder mal die A.... sind! Sitzen auf "btrfs" und "zfs" aber bekommen beides einfach nicht richtig hin. (Wo bleibt der Code der neueren Version von ZFS?) Vermutlich wird dieser nicht mehr erscheinen. FreeBSD und die Jungs von zfsonlinux.org haben ja schon einige Sachen an ZFS zusammen geändert...

[mark05]

Zitat von Lord_x

Sorry stimmt nicht! Linux hat eine sehr gute Kernel- Unterstützung von ZFS!
Das Problem ist die Lizenz sonst wäre das schon lange im Kernel...

http://zfsonlinux.org/

Fakt ist einfach, dass Oracle wieder mal die A.... sind! Sitzen auf "btrfs" und "zfs" aber bekommen beides einfach nicht richtig hin. (Wo bleibt der Code der neueren Version von ZFS?) Vermutlich wird dieser nicht mehr erscheinen. FreeBSD und die Jungs von zfsonlinux.org haben ja schon einige Sachen an ZFS zusammen geändert...

sorry das ist keine alternative fuer eine nserver oder nas betrieb.

wen ich als admin oder anwender erstmal irgenwelche patches einspielen muss
und dann den kernel bauen ( und beten das alles klappt , ne danke bastellbude linux )

holger

[Lord_x]

Zitat von mark05

wen ich als admin oder anwender erstmal irgenwelche patches einspielen muss
und dann den kernel bauen

Du musst gar nichts patchen oder einen Kernel bauen!

Es gibt ein PPA für Ubuntu und Debian sogar mit DKMS Support. Kommt ein neuer Kernel, so wird automatisch das ZFS Modul für den Kernel neu erstellt und nach einem reboot merkst du gar nichts... Das ist wie beim Nvidia- Treiber.

Die Wahrheit ist, dass es sehr gut funktioniert. Verglichen habe ich das aber noch nie mit FreeBSD.
Ich persönlich bin von FreeBSD überzeugt weil es für mich Vorteile gegenüber Linux hat. Auch wenn ich mit der Syntax gegenüber den GNU Tools doch noch so meine Schwierigkeiten habe...

[mark05]

Zitat von Lord_x

Du musst gar nichts patchen oder einen Kernel bauen!

Es gibt ein PPA für Ubuntu und Debian sogar mit DKMS Support. Kommt ein neuer Kernel, so wird automatisch das ZFS Modul für den Kernel neu erstellt und nach einem reboot merkst du gar nichts... Das ist wie beim Nvidia- Treiber.

Die Wahrheit ist, dass es sehr gut funktioniert. Verglichen habe ich das aber noch nie mit FreeBSD.
Ich persönlich bin von FreeBSD überzeugt weil es für mich Vorteile gegenüber Linux hat. Auch wenn ich mit der Syntax gegenüber den GNU Tools doch noch so meine Schwierigkeiten habe...

j genau , wie nvidia da sehen ich das bei jedem kernel update bei meinem vdr
wie gut und stabil das laeuft .

nein danke bei einem storage.

holger

[Yamagi]

Nun bitte mal zurück zum Thema.