ZFS

    Servus.


    Vielleicht kann mir jemand von euch bei der Beschleunigung meines ersten richtigen ZFS Systems helfen. Die Lese/Schreibwerte bewegen sich derzeit im data-Pool bei rund 50MB/s und im rpoom bei ca. 100MB/s.


    Ich verwende in meinem System derzeit folgende Konfiguration:


    rpool:

    - 2x 120GB Mirror für OS und VMs


    data:

    - 4x WD RED 2TB im raidz1

    - 8GB part auf einer 960Evo für ZIL

    - rund 248GB part auf einer 960Evo für L2ARC


    CPU: Pentium G4600

    RAM: 16GB 2400MHz


    Leider erlebe ich es auch sehr oft, dass der IO-Wait bei rund 70-80% hängt, wenn ich auf dem Server mal eine ZIP entpacke.


    Eventuell habt ihr da ja ein paar Ideen.


    lg.

    ZFS, und vor allem RaidZ sind RAM Fresser aus der Hölle.

    16GB Ram sind viel viel zu wenig für das was Du da aufgebaut hast.


    Du könntest es mit einem Mirror Setup probieren. Eventuell hilfts.


    Aber Dein Hauptproblem ist zu wenig RAM. Im Standardsetup schnappt sich ZFS für den Lesecache 50% des RAMs, sofern so viel verfügbar ist. Sprich 8GB. Allerspätestens wenn man mehr als 8GB auf einmal verarbeitet schießt der IO Wait in die Höhe.


    Checke auch mal ob deduplication und compression deaktiviert ist.

    Auch atime/realatime kann man in reinen Datenspeicher Volumes deaktivieren.

    Deduplication und replication ist deaktiviert.

    Auch habe ich bereits den RAM Cache etwas begrenzt, deshalb denke ich nicht, dass dies das Problem sein wird.


    Zumal ZFS doch dank L2ARC nicht im RAM Cachen sollte, oder?


    lg.

    Mein Setup daheim sieht wie folgt aus:

    Das der Pool "raidz" heißt, ist historisch. Es ist ein Verbund aus zwei Mirrors je 2x 6TB WD Red Pro die zu einem Pool zusammengefasst sind. Es stehen also 12TB Speicher zur Verfügung. Zusätzlich hängen noch 2 SSDs im Verbund auf der sich jeweils ein ZiL und ein L2ARC befinden.


    ZiL ist 32GB (mirror) groß, L2ARC ist 2x 200GB groß. Bei mir darf ZFS 16GB von 64GB RAM als L1ARC nutzen.


    Hier mal ein kleiner Benchmark mit 4GB Dateigröße:


    Der gleiche Benchmark mit 17GB Dateigröße:


    Für mich sieht es so aus, als ob die Performance radikal einbricht, wenn mehr Daten verarbeitet werden, als es RAM gibt. Schließlich bin ich weit unter dem, was mein Cache maximal abbilden kann. (Disclaimer: Es laufen noch mehrere VMs auf der Maschine, Benchmark also nur semi-repräsentativ)


    Da es so viele unterschiedliche Meinungen zu ZFS im Web gibt, kann ich Dir leider keine verbindliche Aussage geben. Aber ich tippe drauf, dass es an zu wenig RAM oder am RaidZ liegt, dass es bei Dir zu langsam ist.


    Ich würde es im ersten Schritt mit einem Mirror Setup probieren, wenn das nicht hilft die VMs ausschalten und ZFS mehr RAM zuweisen.


    Hätte ich genug Hardware, hätte ich schon lange mal ein LVM Setup ausprobiert. Das müsste auf einem so "kleinen" System (auf Kosten der Funktionalität) eine bessere Performance liefern.

    Ich hab mir mal dein Skript gecloned und damit auch gebenchmarkt (ganz am Anfang, als der Host noch leer war). Da waren die Lesewerte auch um die 600-800MB/s, weshalb ich eigentlich dachte alles richtig konfiguriert zu haben.

    Sobald ich jedoch live entsprechende Daten verschoben habe, brach immer alles ein.


    Auch kann ich mir nicht vorstellen, dass ZFS im RAM cached, da ja dies volles Risiko bedeutet, wenn mal der Strom weg ist oder sehe ich das falsch?



    lg.

    Mir fehlen leider die Messwerte von meinem leeren System. Auf die Idee Benchmarks zu machen bin ich leider erst gekommen, als die meisten VMs schon eingerichtet waren.


    Zum Thema RAM + Strom weg + Datenverlust: Da gibt es, je nach dem wo man liest und welches Datum das Paper hat, krasse Unterschiede bei den Aussagen. Ich hab schon gelesen "da gehen x Sekunden Transaktionen verloren", aber auch "ZFS schafft es das zu restoren". Hängt auch von der Option "sync" in den Volume Einstellungen ab.


    Hast Du ein wichtiges System, ist also in jedem Fall (egal ob ZFS oder nicht) eine kleine USV ratsam, die das System beim Stromausfall kontrolliert herunterfährt.


    Fakt ist, dass es genau wie in anderen Dateisystem auch, einen Schreibcache im RAM gibt. Ansonsten würde ja alles synchron weggeschrieben werden und es wäre total langsam. Das ZIL wird übrigens auch nur verwendet, um synchrone Schreiboperationen schneller abzuarbeiten und die dann später auf die Platten zu schreiben. Bei asynchronen Operationen ist es mehr oder weniger egal ob man ein ZIL hat oder nicht. Deswegen kann es durchaus Anwendungsfälle geben, wo man mit ZIL überhaupt gar keinen Unterschied messen kann.


    Übrigens kann es genau so zu einem gewissen Verlust an Schreibtransaktionen kommen, wenn das ZIL crasht. Deswegen habe ich das auf 2 SSDs gemirrored.


    Unterm Strich sind meine Probleme mit ZFS: Entweder nicht ausreichend oder mit großen Widersprüchen beschriebene Funktionen/Funktionsweisen, teilweise Unterschiede zwischen der Linux- und der BSD/Oracle-Implementierung von ZFS. Das macht das ganze zu einem großen Abenteuer wo man sehr viel ausprobieren muss.


    Wie gesagt, hätte ich die Hardware hätte ich schon lange LVM bzw LVM-thin ausprobiert.

    Wofür ZIL gut ist und dass diverse Operationen durchaus durch den RAM gehen ist mir bewusst. Jedoch soll ja der ZIL genau diesen Datenverlust verhindern, da ja nicht im RAM, sondern im ZIL 5 Sekunden cached bevor geschrieben wird (keine Ahnung ob der Wert richtig ist).


    Defacto kann ich lediglich viele Nachteile in der Performance zu meiner vorherigen Synology mit btrfs oder mdadm erkennen.

    Irgendwie fühlt sich ZFS on Linux für mich so an, als würde es alles unnötig verkomplizieren und verlangsamen.


    Zu den Benchmarks: Diese wurden gerade mit 6 laufenden VMs erstellt. Die Benchmarks vom leeren System hab ich nicht mehr.


    Wohl ist es jedoch meiner Recherche nach so, dass raidz maximal so schnell ist, wie die langsamste Platte im Verbund. Inwiefern das der Wahrheit entspricht ist die Frage, mach jedoch trotzdem Sinn. Wobei da wieder die Frage entsteht, wie ich 600-800 Mbit/s schreibend mit dem leeren System und deinem Benchmark geschafft habe (dass da irgendwo ein Cache im Spiel war ist klar).


    Ich werde mir wohl demnächst überlegen das Daten-Volume auf einen HWRC auszulagern. Eventuell sehe ich mir btrfs mal an, je nachdem ob RAID5 dort bereits stable ist.


    lg. und danke für deine Eindrücke :)

    Ein Bekannter von mir, welcher einen etwas größeren Fuhrpark hat, hat mit ZFS ein 50TB Volume aufgebaut. Die Maschine hat allerdings auch ein Doppel-CPU-Sockel Board und ist mit 128GB RAM ausgestattet. Das soll (hab wieder keine Benchmarks, muss evtl mal fragen) selbst mit deduplication richtig gut laufen. Das bestärkt mich in meinem Eindruck, dass mein System einfach zu klein für ZFS ist oder irgendwas ganz entscheidendes falsch ist bzw fehlt.


    Ich würde zu gerne mal mit einem echten ZFS-Admin über das ganze quatschen. Leider ist mir noch keiner übern weg gelaufen. In meinem Bekanntenkreis haben die meisten mit eingekauften Storage Systemen bekannter Hersteller zu tun die immer etwas eigenes nutzen.

    Zitat von A:H

    Vielleicht kann mir jemand von euch bei der Beschleunigung meines ersten richtigen ZFS Systems helfen. Die Lese/Schreibwerte bewegen sich derzeit im data-Pool bei rund 50MB/s und im rpoom bei ca. 100MB/s.

    Hallo,


    Welches Betriebssystem/welche ZFS-Version wird denn verwendet? (Für Linux empfiehlt sich, falls noch nicht geschehen, ein Blick auf https://github.com/zfsonlinux/zfs/wiki/Getting-Started)


    Ein potentieller Grund wäre, daß der Speicherplatz temporär(!) einmal bis zur Neige ausgenutzt wurde, was m.W. bei ZFS unabhängig vom Pool-Aufbau nur durch ein Neuaufsetzen heilbar ist. Um dies vom Anfang an zu verhindern, kann man entweder an bestimmten Einstellungen "schrauben" oder man erstellt sich einfach ein dataset wie folgt ("xx" sollte hierbei 15-20% des Gesamtplatzes einnehmen):

    Code
    zfs create -o canmount=off -o setuid=off -o exec=off tank/RESERVED
zfs set reservation=xxG tank/RESERVED


    Daneben ist zu verifizieren, daß die Samsung-SSD nicht das Problem ist (laut Berichten bricht die Zugriffszeit massiv ein, wenn sie voll belegt ist). Die verwendete Partitionsgröße für L2ARC halte ich für deutlich überdimensioniert, sofern Statistiken nicht das Gegenteil beweisen (vgl. https://github.com/mmatuska/zfs-stats/ o.ä.); ich empfehle hier eine Neuaufsetzung mit 25-50% manuellem Overprovisioning, was auch der Lebensdauer entgegenkommt.


    Nicht erwähnt, aber wichtig: Ein regelmäßiges Scrubbing via cronjob sollte gewährleistet werden (alle 1/2/4 Wochen).



    VServer IOPS Comparison Sheet: https://docs.google.com/spreadsheets/d/1w38zM0Bwbd4VdDCQoi1buo2I-zpwg8e0wVzFGSPh3iE/edit?usp=sharing

    Herzlichen Dank nochmals für den Tipp.

    Mit dem neuen Proxmox Update wurde auch die ZFS Version aktualisiert.

    Ich bilde mir hier eine deutliche Leistungssteigerung ein. Ebenso wurde der RAM auf 32GB erhöht.


    Ich denke, das sollte die Probleme erstmal eindämmen. Falls sich meine Beobachtungen etwas konkretisieren oder wieder in die entgegengesetzte Richtung umschlagen, werde ich mich melden.


    lg.

    Uh, die neue ZFS Version ist beeindruckend (im Vergleich zu vorher):



    Mal abwarten wie das ist, wenn die Uptime wieder >30 Tage ist und sich die Caches gefüllt haben. Hatte gestern von Jessie auf Stretch und von Proxmox 4 auf Proxmox 5 aktualisiert.