Ja das ist normal. Bei ZFS gehen die Daten nicht direkt auf den Pool sondern zunächst in den rambasiertem Schreibcache. Unter Solaris und native ZFS sammelt der 5s kleine langsame Writes und schreibt die dann als eine große schnelle Schreibaktion. Unter Open-ZFS ist die Größe des Schreibcaches abhängig vom RAM, per default 10% RAM max 4GB. Ist der Schreibcache halb voll wird der Inhalt auf Platte geschrieben. 0.5s ist sehr kurz und läßt auf wenig RAM schließen.
Ja das ist normal. Bei ZFS gehen die Daten nicht direkt auf den Pool sondern zunächst in den rambasiertem Schreibcache. Unter Solaris und native ZFS sammelt der 5s kleine langsame Writes und schreibt die dann als eine große schnelle Schreibaktion. Unter Open-ZFS ist die Größe des Schreibcaches abhängig vom RAM, per default 10% RAM max 4GB. Ist der Schreibcache halb voll wird der Inhalt auf Platte geschrieben. 0.5s ist sehr kurz und läßt auf wenig RAM schließen.
toscdesign
Enthusiast
- Mitglied seit
- 17.02.2022
- Beiträge
- 6.023
Danke für die genaue Erklärung 👍
RAM hat das System 16GB
RAM hat das System 16GB
Zum Speicher bei ZFS aus zpool list poolname
Zunächst muss man wissen dass ZFS nicht Terabyte sondern Tebibyte anzeigt. Als Hausnummer sind das ca 10% weniger in der Anzeige. Dazu kommt dass ZFS zunächst die "Rohkapazität" aller Platten zeigt, bei 18 x 18,2T also 327T. Da zwei Platten für Redundanz draufgehen bleiben damit ca 290T nutzbar. Für eine kleine interne Reservierung geht noch minimal was ab,
Davon zieht man den belegten Speicher ab und erhält dann den freien Platz sofern nichts durch Snaps geblockt ist oder durch zvols belegt ist.
Zunächst muss man wissen dass ZFS nicht Terabyte sondern Tebibyte anzeigt. Als Hausnummer sind das ca 10% weniger in der Anzeige. Dazu kommt dass ZFS zunächst die "Rohkapazität" aller Platten zeigt, bei 18 x 18,2T also 327T. Da zwei Platten für Redundanz draufgehen bleiben damit ca 290T nutzbar. Für eine kleine interne Reservierung geht noch minimal was ab,
Davon zieht man den belegten Speicher ab und erhält dann den freien Platz sofern nichts durch Snaps geblockt ist oder durch zvols belegt ist.
Multiverse
Profi
- Mitglied seit
- 27.02.2022
- Beiträge
- 38
Nun, dann mal mit den Angaben, die ich in Dolphin sehe:
Kapazität = 290,8 TB ohne darauf liegende Daten
Summe der darauf liegenden Daten jetzt = 8,5 TB
Kapazität jetzt = 267,9 TB
Selbst mit den von dir genannten 10% lässt es sich einfach nicht erklären!
Bei 16GB kann man 4GB für das OS abziehen, bleiben 1,2 GB für Schreibcache, nutzbar ca 600 KB bei einem User.
toscdesign
Enthusiast
- Mitglied seit
- 17.02.2022
- Beiträge
- 6.023
Sicher?
TrueNAS zeigt mir einen ZFS Cache von 7,7GB an. Wenn der Vorgang abgeschlossen ist geht der wieder auf 0.
Was ich aber auch nicht verstehe ist, das dieser Cache "volläuft". Die Übertragungsrate übers Netzwerk beträgt ca. 110MB/s und die Festplatte schafft ca. 240MB/s.
Somit müsste die Platte immer schneller wegschreiben, als neue Daten kommen. 🤔
TrueNAS zeigt mir einen ZFS Cache von 7,7GB an. Wenn der Vorgang abgeschlossen ist geht der wieder auf 0.
Was ich aber auch nicht verstehe ist, das dieser Cache "volläuft". Die Übertragungsrate übers Netzwerk beträgt ca. 110MB/s und die Festplatte schafft ca. 240MB/s.
Somit müsste die Platte immer schneller wegschreiben, als neue Daten kommen. 🤔
Bei 290T - ca 7,5T Daten sollte ca 282T frei sein. Wenn es keine Snaps gibt muss Speicher von etwas anderem belegt sein, z.B. dump oder swap Volumes.
Multiverse
Profi
- Mitglied seit
- 27.02.2022
- Beiträge
- 38
Kannst du mir ein paar Konsolenbefehle nennen, um der Sache auf die Spur zu kommen?
Swaps habe ich beí den OS-Installationen immer abgelehnt.
Der Pfad ist /storage ...
Neben dem RAM-Schreibcache gibt es den RAM-Lesecache. Der ist ca 70%vom freien RAM alsi ca 7GB. Der läuft voll im Lauf der Zeit.
ps
Eine Platte kann unter Laborbedingungen (Daten am Stück außen lesen/schreiben) 240MB/s. Da ZFS die Daten auf dem Pool gleichmäßig verteilt zählt mehr iops. Da sind Platten mit ca 100 iops lausig schlecht. Ich rechne pro Platte eher mit 100 MB/s. Daten gehen aber immer zuerst in den RAM Cache. Kann die Platte dann den Cacheinhalt nicht so schnell wegschreiben wie neue Daten kommen, bremst das, andernfalls hat man volle Performance auch bei kleinen Daten bei denen eine Festplatte ansonst auch mal auf 10 MB/s einbricht.
Beitrag automatisch zusammengeführt:
zfs list -t volume
FreeNAS hat immer automatisch Swaps angelegt, k.A. ob das immer noch so ist
toscdesign
Enthusiast
- Mitglied seit
- 17.02.2022
- Beiträge
- 6.023
Multiverse
Profi
- Mitglied seit
- 27.02.2022
- Beiträge
- 38
Warum sollte einen das stören. Ohne den Schreibcache hätte man sehr schlechte Schreibperformance,
Um das zu simulieren einfach mal sync auf always stellen. Dann geht jedes write commit sofort auf Platte.
Write Performance geht dann gerne auf 10MB/s bei einer Platte. Dafür gibt es keinen Datenverlust im Schreibcache.
Beitrag automatisch zusammengeführt:
Dann liegt die Differenz zumindest nicht an ZFS. Da ist Nutzkapazität-Snaps-zvols=verfügbar.
Einzig Reservierungen können noch ZFS Platz belegen, https://docs.oracle.com/cd/E38896_01/html/E38889/gazvb.html
toscdesign
Enthusiast
- Mitglied seit
- 17.02.2022
- Beiträge
- 6.023
Interessant, werde ich Mal ausprobieren 🤔👍
Multiverse
Profi
- Mitglied seit
- 27.02.2022
- Beiträge
- 38
Reservierungen habe ich auch keine.
Ich sollte wohl das Storage räumen und neu aufbauen!
Ergänzungsfrage: Ich habe eine Record Size von 4K, kann das die Erklärung sein?
4K!!!!! Warum zum Henker. Das ist vom Speicherbedarf und Performance katastrophal.
Alle ZFS Operationen beziehen sich darauf inkl Prüfsummen und das ist mit so kleinen Blöcken extrem ineffektiv.
Default ist 128k, Gerne geht man auf 512k-1M. Man kann für VMs auch mal auf 32k-64k heruntergehen, niemals auf 4k
ps.
Recsize wirkt bei neuen Writes. Man kann einfach recsize hochsetzen und Daten umkopieren.
4k ist die physical blocksize bei Festplatten, Betriebssystem arbeitet meist mit 8k Blöcken, ZFS mit größeren Blöcken, SSDs mit mehreren MB als Block.
Zuletzt bearbeitet:
Multiverse
Profi
- Mitglied seit
- 27.02.2022
- Beiträge
- 38
Hm, dann stelle ich mal auf 128K um .... Frage mich nur, wie ich die bestehenden Daten korrigiere ...
zfs send | zfs receive oder einfach ein move nach Ändern der recsize
ps
Mich hätte die Performance bei 4k recsize interessiert.
Könnte unterhalb von 1MB/s liegen
Multiverse
Profi
- Mitglied seit
- 27.02.2022
- Beiträge
- 38
Bzgl der Performance kann ich sagen, dass eine USB-Festplatte ohne Einbrüche geleert werden konnte und auch der Download meines Googles Drives mit der VDSL250-Leitung schon seit Tagen bis zum Anschlag läuft (ca. 30 MB / s).
D
Ist aber definitiv ein Fehler recsize=physical HD blocksize zu stellen.
Da hilft wohl der ZFS + Plattencache.
Ist aber definitiv ein Fehler recsize=physical HD blocksize zu stellen.
Multiverse
Profi
- Mitglied seit
- 27.02.2022
- Beiträge
- 38
Lektion gelernt! Nur das mit dem zfs send / receive kapiere ich nicht ...
Der Storage heißt "storage" und hängt in /storage ... Und dann habe ich eben noch gelesen, dass das nichts bringt bei geänderter Blocksize ... Mir schwirrt der Kopf!
zfs send (Replikation)
Recsize wirkt bei Schreiben. Man muss also recsize hochstellen, dann Daten neu schreiben (zfs send oder ein einfaches copy/ move zwischen Dateisystemen tuts auch)
Senden und Empfangen von ZFS-Daten - Oracle Solaris ZFS-Administrationshandbuch
Dieses Handbuch richtet sich an alle Personen, die für die Einrichtung und Administration von ZFS-Dateisystemen von Oracle zuständig sind. Sofern zutreffend, werden Themen für SPARC- und x86-basierte Systeme behandelt.
docs.oracle.com
Recsize wirkt bei Schreiben. Man muss also recsize hochstellen, dann Daten neu schreiben (zfs send oder ein einfaches copy/ move zwischen Dateisystemen tuts auch)
Zuletzt bearbeitet:
ludwinator
Enthusiast
- Mitglied seit
- 28.12.2006
- Beiträge
- 529
Und wenn du schon beim umkopieren bist, denk mal drüber nach, ob das Layout mir Z2 und 18 Platten wirklich nötig ist für dich. Ich würde eher nicht über 12 Disks gehn in einem vdev. Außerdem solltest du LZ4 aktivieren, das bringt garantiert mehr als es kostet.
cu
cu
toscdesign
Enthusiast
- Mitglied seit
- 17.02.2022
- Beiträge
- 6.023
Hier hätte ich noch eine Frage, ich hatte die Tests mit großen Dateien (25GB und mehr) durchgeführt.
Sollten diese nicht in einem Rutsch geschrieben werden? Oder ist das unabhängig von der Dateigröße?
Multiverse
Profi
- Mitglied seit
- 27.02.2022
- Beiträge
- 38
Die Kompression werde ich in der Tat aktivieren, am Layout an sich ändere ich nichts ... Bin mit 8+1 bei den Paritäts-RAIDs schon seit Jahren gut gefahren ...
ZFS schreibt grundsätzlich zuerst in den RAM Schreibcache. Ist der halbvoll geht es in recsize Blöcken (oder bei kleinen Daten in Bruchteilen davon) auf den Pool. Mit LZ4 ist die tatsächliche Blockgröße abhängig von der Komprimierbarkeit. ZFS versucht dabei den Pool gleichmäßig zu füllen. Direkt IO (Schreiben ohne Cache) ist in der Entwicklung. Im ZFS Raid gibt es damit keine echten sequentiellen Transfers. IO Leistung ist damit wichtiger als bei älteren Dateisystemen. Ein single Z2 vdev Plattenpool hat aber nur ca 100 echte iops. Bei mehreren Benutzern oder vielen kleinen Daten ist das sehr wenig.
ps
Neben der geringen io Leistung würde ich wegen der langen Resilverzeit bei einem Plattenausfall 2 x Z2 (sowas wie früher Raid-60, Pool bringt dann 200 iops) oder wenigstens auf Z3 gehen. Für schnelle Sachen gibts ja noch den NVMe Pool.
toscdesign
Enthusiast
- Mitglied seit
- 17.02.2022
- Beiträge
- 6.023
Also wäre aufrüsten auf 32GB RAM sinnvoll?
Zum zweiten Punkt, das ist ein NAS Ersatz, basierend auf einem Odroid H2 bzw. H3. Also sehr klein, energiesparend und nur mit 2 Platten ausrüstbar. Des weiteren mit Offsite Backup auf baugleichen System.
Daher wäre dein Vorschlag ein klein wenig Overkill 😅
Edit: Wahrscheinlich ist es sogar schneller das Offsite Backup auf neue Platten zurückzuspielen als zu resilvern 🤔
Zuletzt bearbeitet:
Bei einer reinen Performance und Effizienzbetrachtung macht ZFS alles falsch. Es fügt an Daten und Metadaten Prüfsummen an und muss damit viel mehr Daten lesen, schreiben und verarbeiten. Da keine Daten auf dem Pool geändert werden sondern wegen Copy on Write immer als neue Blöcke in recsize geschrieben werden, erhöht sich die Datenmenge nochmals beträchtlich. Da Daten über den Pool verteilt werden, gibt es keine echten sequentiellen Transfers sondern viel random io.
Im Gegenzug kann ZFS feststellen ob Daten oder Raid korrekt sind. Bei einem Absturz bei Schreiben bleibt ZFS heile und Copy on Write liefert ganz nebenbei Snaps ohne Overhead. Auch bei vielen Nutzern und vielen kleinen Dateien bleibt die Performance von ZFS recht konstant.
Dass ZFS dennoch sehr schnell ist, liegt neben modernen/schnellen CPUs daran dass fast der komplette RAM als extrem effizienter
Lese-/Schreibcache genutzt wird. Meine Daumenregel lautet:
Ein 64 bit OS mit ZFS braucht etwa 4 GB RAM. Solaris/Illumos etwas weniger da die ZFS Speicherververwaltung noch wie Solaris arbeitet,
BSD und Linux etwas mehr. Dazu kommt noch ein Zuschlag für webbasiertes Management zwischen 512k und 2 GB.
Ca 10% RAM werden als Schreibcache genutzt. Dieser dient ausschließlich dazu kleine Writes z.B. < 128k wann immer möglich zu vermeiden. Da brechen sogar NVMe übel ein.
Ca 70% RAM werden als Lesecache für kleine random reads (Metadaten und kleine Daten aus read last/read most). Große Daten/Files werden nicht gecacht.
Falls man rambasiertes realtime Dedup nutzt, kommt dazu bis zu 5 GB RAM je TB deduplizierte Daten (nicht Poolsize).
Bei 32GB kann man also phi x Daumen rechnen
32-6 GB (OS und Web-ui, BSD/Linux)=26GB frei
Schreibcache 2,6GB, nutzbar 1,3 GB für alle User.
Wenn man keine Writes < 128k möchte, könnte man in diesem Fall 10 User je mit ausreichend Schreibcache bedienen
Lesecache wären dann max ca 18GB. Da landen vor allem Metadaten und kleine/letzte Reads.
Mit wenigen Usern und Dateien liefert das eine Cache hitrate von gerne > 80%.
Bei einem Enterprise Mailserver mit vielen Usern und Millionen Dateien wäre das viel zu wenig Cache.
Die oft genannte Regel 1 GB RAM per TB Pool ist Unsinn sondern es kommt darauf an. Gibt Fälle wo 4 GB RAM gerade noch ok sind, manchmal sind 128 GB sinnvoller.
toscdesign
Enthusiast
- Mitglied seit
- 17.02.2022
- Beiträge
- 6.023
Danke für die sehr ausführliche Erklärung 👍
Da das Gerät max. 3 User gleichzeitig hat im Schnitt 1-2 User, sollte der RAM ausreichen.
Soweit ich das verstanden habe 😅
Also erstmal weiter benutzen, die Performance passt ja soweit 👍
Da das Gerät max. 3 User gleichzeitig hat im Schnitt 1-2 User, sollte der RAM ausreichen.
Soweit ich das verstanden habe 😅
Also erstmal weiter benutzen, die Performance passt ja soweit 👍
shockwave10k
Experte
- Mitglied seit
- 19.03.2014
- Beiträge
- 110
Danke für die ausführliche Erklärung!
Wie spielt jetzt L2ARC und Schreibcache auf einer SSD da rein?
Sollte man L2ARC erst nehmen wenn man nicht mehr RAM ins System bekommt?
ludwinator
Enthusiast
- Mitglied seit
- 28.12.2006
- Beiträge
- 529
Ich habe selbst noch keinen Anwendungsfall gefunden, bei dem der L2ARC messbaren Geschwindigkeitsgewinn gebracht hätte.
Das muss wohl an der erstklassigen ARC Implementierung liegen, daher lautet mein Votum: lieber 8GB mehr Ram als 100GB L2ARC.
Nicht zu vergessen: der Index des L2ARC muss im ARC gehalten werden und verringert den "schnelleren" Cache damit.
Das muss wohl an der erstklassigen ARC Implementierung liegen, daher lautet mein Votum: lieber 8GB mehr Ram als 100GB L2ARC.
Nicht zu vergessen: der Index des L2ARC muss im ARC gehalten werden und verringert den "schnelleren" Cache damit.
