[Sammelthread] ZFS Stammtisch

[gea]

Seither sind Dateioperationen bei kleinen Dateinen wirklich lahm geworden.

Mainstream ist Linux oder Windows.
Die kleinen Spezialisten wie BSD, OSX oder Solaris/Illumos sind in ihren Spezialgebieten oft besser/schneller/einfacher/flexibler. Performancemäßig sehe ich immer noch Solaris>BSD>Linux.

Beitrag automatisch zusammengeführt: 28.06.2024

Ich hab den Kram schon am Laufen
ein paar Postings weiter oben sollten die wichtigsten Infos bereitliegen.

Z1 Pool bestehend aus 4x7x68tb (micron ion 5210 //qlc ssd, plp, kein slc pseudo).
Fuellstand > 80%, wird allmaehlich langsam der Pool.
Das Ganze laeuft jetzt schon seit bald 4 Jahren stressfrei, aber es wird halt langsam...

Wie bekomm ich das wieder ans Fliegen?
Wie wuerde ne Erweiterung aussehen? Kann der bestehende Z1 Pool einfach vergoeßert werden?

Die erste Maßnahme wäre sicher Füllrate verringern/Pool vergrößern. Open-ZFS 2.2.3 bietet ja Expansion 4x auf 5x Z1. Dann könnte man ein special vdev mirror aus Optane 1600 hinzufügen um Zugriff auf Metadaten und Small io zu verbessern. Optane ist nochmal ein anderes Kaliber als SSD.

 

[pwnbert]

Wie wuerde ne Erweiterung aussehen? Kann der bestehende Z1 Pool einfach vergoeßert werden?

Neuerdings geht das wohl.
Ist halt ein schlechter Zeitpunkt zum SSD kaufen.

Kingston DC600M Data Center Series Mixed-Use SSD - 1DWPD 7.68TB ab € 666,38 (2024) | Preisvergleich Geizhals Österreich

✔ Preisvergleich für Kingston DC600M Data Center Series Mixed-Use SSD - 1DWPD 7.68TB ✔ Bewertungen ✔ Produktinfo ⇒ Kapazität: 7.68TB (entspricht ca. 7152.56GiB bzw. 6.98TiB, weiterführende Informationen hierzu ) • Baufor… ✔ Solid State Drives (SSD) ✔ Testberichte ✔ Günstig kaufen

geizhals.at

Wobei die gar nicht soo viel teurer geworden ist und wohl ganz gut sein sollte.

 

[mrpasc]

@mrpasc Problem 1 trifft nicht zu, da Enterprise QLCs (Micron ION 5210) ohne komischen Cache und PLP.

Die ION 5210 ist von Micron als „Capacity Tier“ aka Festplatten Ersatz hauptsächlich für vSAN gemacht worden. Für eine QLC „recht ordentlich“, aber bleibt QLC. Die Spezifikation für z.B. random 4K Write von 4500 IOPs für die 7,68TB Variante ist ja um Faktor 5-10 kleiner als die von TLC Enterprise Satas wie Samsung PM883 oder Micron 5200/300/400 Pro.

 

[gea]

Um das einzuordenen.
Eine mechanische Festplatte hat ca 100 raw iops, die besten SAS SSD ca 250000 iops und eine Intel Optane 500000.

 

[p4n0]

Hi,
Das ist mir durchaus bewusst. Das Gespann lief bisher ja auch fuer meine Beduerfnisse total zufriedenstellend und unauffaellig.

Jetzt lahmt es halt allmaehlich

Bei solchen Projekten muss man halt auch immer die Anforderungen und den Geldbeutel im Auge behalten. Besser und schneller geht immer. Aber dann steht dann schnell mal das Doppelte aufm Kassenzettel.

 

[HansBohne]

Spannend.

Warum ist mein "apps" Pool so fragmentiert? Dort liegen meine VMs und eben die "Apps" (also diese TrueCharts Container Dinger etc.). Irgen dein temp. Share hab ich dort auch noch, primär zum benchen/testen.

Naja wenn man damit auch "Datenträger" bencht hat man sicher temporär einen grossen Füllstand - evtl ist auch ein Snapshot da der dann Benchmarkfiles im Hintergund vorrätig hält etc.

Nun sobald Fragmentierung mal begonnen hat wird das glaube ich schwer wieder einfach geradezuziehen. Ich kopier dann einfach KOMPLETT um, aber geht halt nur wenn man genug Platz hat.

Das war ja schon in einem anderen Thread oder hier Thema wenn das Problem vor allem ein Verzeichnis z.B. Bilder MP3s sind etc kann man auch Serverseitig als evtl Fix die Verzeichnisstruktur in den Cache einlesen indem man beim Start und periodisch ein "find" drüber laufen lässt - automatisch per Script natürlich und mit "nice" xD Das sollte auch keine so negativen Auswirkungen haben.

Ich selber habe wenig solche Kleinfiles, aber bei einem Bekannten habe ich das mal so eingerichtet der viel mit tausenden von Fotos arbeitet. Das klappt glaub richtig gut.

 

[pwnbert]

Snapshot

Gibts davon (noch) nicht. 🙈

Benchmarkfiles

Hmja, hab testen wollen, was mein Z1 Pool so kann, dafür hab ich natürlich was (potentiell) schnelleres gebraucht. Potentiell weil ich mir nicht sicher bin, ob die Micron 7400 pro echt schneller ist, mit ihren 7.5W im "power saving mode"... Scheiß Teil. Größter Fehlkauf.

Ich kopier dann einfach KOMPLETT um, aber geht halt nur wenn man genug Platz hat.

Wenn ich eine Sicherung davon erstelle und dann wiederherstelle, nehm in die Fragmentierung dann mit?

Das war ja schon in einem anderen Thread oder hier Thema wenn das Problem vor allem ein Verzeichnis z.B. Bilder MP3s sind etc kann man auch Serverseitig als evtl Fix die Verzeichnisstruktur in den Cache einlesen indem man beim Start und periodisch ein "find" drüber laufen lässt - automatisch per Script natürlich und mit "nice" xD Das sollte auch keine so negativen Auswirkungen haben.

Hab ich gestern gemacht, bin mir aber nicht sicher, ob das so funktioniert hat, wie man sich das vorstellt. Ist erstaunlich schnell durchgelaufen der "find"... wobei ich mir natürlich schwer tu festzustellen, obs nun am ZFS Cache oder am SMB Protokoll liegt. Ich meine zwar, dass es ZFS seitig ist, weil ich denke, dass es eher am "Zugriffszustand" des NAS liegt und weniger am Client-Rechner. Aber wer weiss, vielleicht trügt das auch.

Bin gespannt, ob ich irgendwas vom L2Arc mit secondarycache=metadata und vom SLOG/ZIL merke... zweites höchstwahrscheinlich nicht.


Ab welcher "Kennzahl" wird die Fragmentierung eigentlich problematisch?

 

[HansBohne]

Ne die Fragmentierung geht natürlich weg wenn man alles wkkopiert, löscht, neu zurückkopiert.

Naja denke aber so 20% - wichtiger aber als "schlechtes" Zeichen wäre wenn die Fragmentierung stetig grösser wird

 

[pwnbert]

Aber ich kann die Apps ja nicht einfach kopieren... oder... kann ich? Ich kann den Datenträger dem TrueNAS ja nicht einfach wegnehmen, zumindest da, wo das App pool drauf liegt... mmh?

 

[gea]

Das Problem ist nicht die Fragmentierung an sich, die hat man auch wenn man Daten umkopiert sondern der Füllgrad. Wird der Pool voll wird es immer schwieriger Bereiche zu finden in denen ein kompletter neuer CoW Datenblock z.B. 128K bis 1M am Stück reinpasst. Auch werden viele SSD neben ZFS mit dem Füllgrad auch langsamer. Ich würde mich daher nicht so um das Symptom Fragmentierung kümmern sondern um Füllgrad denn das ist die Ursache für langsames Lesen/Schreiben. Zielführender wären weitere gleiche SSD oder wenn die zu teuer sind, entweder ein zusätzlicher günstiger Plattenpool (Mirror) für unkritische Daten/Backup oder ein Hybridpool SSD+HD mit Special vdev für small io z.B. Dateien bis 128K . Mit Lesechache oder Umkopieren wird man die Performance nicht nennenswert verbessern.

 

[p4n0]

Was limitiert meine Pool Performance denn genau?
Ich habe mir die Auslastung von meinem Nas genauer angeschaut und kann zumindest auf den Graphen keinen Engpass feststellen.

Ist es am Ende des Tages die CPU Leistung (Singlecore?) oder was wird zum Bottleneck ab einem gewissen Fuellstand ?

Ist das hier evtl fuer schlechte Performance verantwortlich?
(Also fehlendes l2arc device?)

 

[gea]

Nein, lediglich die sinkende Anzahl großer freier Bereiche bremst.
ZFS muss ja bei jeder Datenänderung wegen CopyonWrite alles neu schreiben, kann nichts updaten.

Bei SSD kommt dazu dass teilbelegte Pages nur nach read/update/delete beschrieben werden können. Auch da braucht man viele große freie Bereiche damit das schnell bleibt. Wann war das letzte Trim bzw ist Autotrim an?

 

[p4n0]

Vielleicht bloede Frage aber wie bekomme ich das heraus?
smartctl ?

 

[gea]

Trim muss ZFS machen, Abfrage z.B.
zfs get autotrim

 

[p4n0]

root@nas[~]# zfs get autotrim
bad property list: invalid property 'autotrim'


root@nas[~]# uname -a
Linux nas 6.6.29-production+truenas #1 SMP PREEMPT_DYNAMIC Wed May 29 15:05:57 UTC 2024 x86_64 GNU/Linux
root@nas[~]# zfs version
zfs-2.2.4-1
zfs-kmod-2.2.4-1

Das ist ein TrueNas Scale System.. Doch wieder back to the roots?
Wie gesagt, mit dem BSDoi'den lief's gefuehlsmaeßig schneller...


:/

 

[gea]

mein Fehler, autotrim ist kein Dateisystem sondern ein Pool Property
zpool get autotrim

Für mich selber gilt nach wie vor mit ZFS
Solaris/Illumos > BSD > Linux

Linux und Windows sind halt die Mainstream Optionen

 

[p4n0]

root@nas[~]# zpool get autotrim
NAME PROPERTY VALUE SOURCE
boot-pool autotrim off default
flash autotrim off default

allright, hier haben wir wohl das erste problem
Gutes Gespuer!

Wie bekomme ich das nun an ohne das mir iwas um die Ohren fliegt? ^^

 

[mrpasc]

Ist doch ein TrueNAS? Da kannste das über die GUI aktivieren, irgendwo bei den Pool-Optionen.

 

[pwnbert]

Solaris/Illumos > BSD > Linux

Das ist bestimmt so - aber hilft ja nix.
Wenn man halbwegs zivil bleiben will, und nicht so richtig einschlägig vom Fach ist (also Hobbist und/oder mit nur "grundlegender" IT Ausbildung/Erfahrung), wirds dadurch ja nicht einfacher.
Meine BSD Berührungen waren zwar sehr positiv, hat mir gut gefallen, ich habs dann aber aufgrund der "Sinnlosigkeit der Übung" wieder bleiben lassen. Für mein "recht normales" Anforderungsprofil, hätte ich mir damit keinen Gefallen getan, weder softwareseitig, noch hardwareseitiog - bissl Mainstream "muss" dann halt leider manchmal sein.

Ist das hier evtl fuer schlechte Performance verantwortlich?
(Also fehlendes l2arc device?)

Eher nicht. Und bevor du auf die Idee kommst, ein L2arc device zu erwerben, erweiter lieber deinen Pool.

Neugierig wie ich bin, gleich mal probiert:
admin@nas[~]$ sudo zpool get autotrim
NAME PROPERTY VALUE SOURCE
apps autotrim on local
boot-pool autotrim off default
870evo autotrim on local
hdd-z1 autotrim off default

Apps is eine SSD, die Evo natürlich auch... passt so also.
Bei den HDDs im Z1 ebenso.
=> boot-pool ist eine pm893 240g sata... da sollte es eigentlich on sein... ist das egal?
=> ... und die L2ARC/SLOG fehlt mir da. Müsste es doch trotzdem geben, oder?


PS: Weil die Leute immer irgend einen günstigen USB-Stick etc. als Boot-Drive nehmen wollen...
Die pm893 sagt mir bei smartctl foilgendes:
241 Total_LBAs_Written 0x0032 099 099 000 Old_age Always - 5162827429 ... das sind wenn ich mich nicht irre (durch ~2.000.000) etwa 2,5 TBW...
9 Power_On_Hours 0x0032 098 098 000 Old_age Always - 5537 ... ist jetzt nicht so, als wär die SSD alt.
12 Power_Cycle_Count 0x0032 099 099 000 Old_age Always - 38

 

[p4n0]

root@nas[~]# zpool get autotrim flash
NAME PROPERTY VALUE SOURCE
flash autotrim on local



Vielen lieben Dank an alle!

 

[pwnbert]

Hilft aber nicht fürs boot-pool und die cache/zil SSD...

edit: zu langsam

 

[p4n0]

Hilft aber nicht fürs boot-pool und die cache/zil SSD...

Das ist mir ja eh egal. Mir gehts nur um den Pool, der relativ lahm ist.. zumindest gefuehlsmaeßig.
Mal schauen ob Trim das jetzt in Ordnung bringt.
Erweitern werd ich dann iwann mal im Laufe des Jahres.

 

[pwnbert]

... dir isses vielleicht egal... aber mir?

Ich muss jetzt mal schauen, wie man den l2arc persistent bekommt, falls ers nicht schon ist.

edit:
Voller Erfolg, der L2arc bis jetzt:

 

[p4n0]

Wielang kann ich ca. rechnen dass der TRIM dauert?
Alle SSDs roedeln nun auf 100% Auslastung. Damit ich n Gespuer dafuer hab ob da noch alles i.O. ist...

 

[LuxSkywalker]

mann kann auch jederzeit

zpool trim POOL

manuell ausführen

autotrim ON gab bei meinem FreeBSD NAS zeitweise Performanceprobleme wenn autotrim aktiv war und ich was auf dem entsprechenden Pool gemacht habe

so führe ich das nur per cron 1x die Woche nachts aus

 

[gea]

Trim ist keine Funktion um SSD schneller zu machen sondern ein notwendiges Übel damit die nicht immer langsamer werden vor allem wenn sie voller werden. Die guten Enterprise SSD DWPD 3+ haben eine sehr große interne Reservierung damit die Trim nicht so brauchen. So eine Reservierung kann man auch bei günstigeren SSD machen damit die konstanter ihre Performance halten z.B. per HPA oder ungenutzte Partition nach sicherem Löschen.

Trim kostet Performance. Autotrim ist set und forget und prima wenn Performance kein so großes Problem ist, ansonst ist manuelles Trim nachts oder am WE besser, Trim ist auch nicht so unkritisch. Es gab auch Berichte über Datenverlust bei Trim. Das waren aber keine Enterprise Modelle sondern "billige" Desktop Modelle.

Beitrag automatisch zusammengeführt: 29.06.2024

... dir isses vielleicht egal... aber mir?

Ich muss jetzt mal schauen, wie man den l2arc persistent bekommt, falls ers nicht schon ist.

edit:
Voller Erfolg, der L2arc bis jetzt:

L2Arc ist immer persistent.

aber mit ausreichend RAM: Hitrate=0% oder niedrig.
Das heißt alle Cache Treffer kommen aus dem schnelleren Arc, das L2Arc ist dann überflüssig, außer bei häufigen Reboots

 

[p4n0]

Trim ist jedenfalls durchgelaufen, Performance immernoch relativ lahm.
Hat also nicht wirklich was geaendert. Trotzdem ne gute Erkenntnis gewonnen.

Die Erweiterung kommt also iwann im Laufe des Jahres

 

[HansBohne]

Erweitern hilft immer denke ich am besten - ab 75% Auslastung verdopple ich immer mindestens - bei HDDs geht das preislich relativ problemlos, bei ssds ist das natürlich aktuell noch etwas teurer.

Grundsätzliche Probleme bleiben sicher immer wie dass bei sehr vielen kleinen Dateien halt einfach das Verhältnis "Verwaltungsdaten" zu "Nutzdaten" schlecht ist, das kann man auch nicht durch Cache und Co ändern, das ja ein grundsätzliches Problem. Wenn bei gaaaanz vielen kleinen Dateien z,.b. das 70% "Verwaltungsdaten" sind und 30% Nutzdaten ist das auch im Cache sicher grob so.

 

[p4n0]

Kann ich eventuell mit der Blocksize spielen um das Ganze performanter zu gestalten?
Bin folgende Punkte am ueberlegen:
Große, statische Daten (Bilder und so Zeug) auf spinning Rust und der restliche Kleinschiss, der mich ankotzt wenns lahm ist bleibt auf dem SSD Pool?

SSD Erweiterung reißt halt direkt n 4k großes Loch in die Schatulle. Hab ich eigentlich nicht so Bock drauf...

 

[HansBohne]

Ich meine dass wenn man (auch die einfachste super schnelle) Compression an hat hat man effektiv eine variable Blocksize. Egal was Du machst an dem Verhältnis ändert sich halt nichts - kleine Files sind immer lahmer als grosse

Ich bin gerade beim testen von 10 Gbit auf 40 Gbit Netzwerk (weil mein Internetanschluss bald von aktuell 10/10 Gbit auf 25/25 Gbit aufgerüstet wird) da erreiche ich mit grossen Dateien
~ 2100 MByte / sec mit sehr kleinen Testdatenfiles manchmal gerade mal 100 Mbyte / sec.

Glaube auch nicht dass es da generell eine Lösung gibt. Das der gleiche Effekt wie im realen Leben Bürokratie = die Datenverwaltung des FS ist halt der Bremsklotz.