Gesucht: Einstieg in ZFS
- Ersteller berni51
- Erstellt am
bananenBrot
Well-Known Member
Nebenbei: hat jemand schon mal Metadaten im ARC gecached (zfs set primarycache=metadata) und irgend eine Performanceverbesserung festgestellt?
Ich habe echt nen Haufen Mini Dateien in meinem Pool und hab das mal angeschaltet um "ls"se und rsyncs zu beschleunigen aber ich konnte bisher nirgends eine Performanceverbesserung feststellen.
Ich habe echt nen Haufen Mini Dateien in meinem Pool und hab das mal angeschaltet um "ls"se und rsyncs zu beschleunigen aber ich konnte bisher nirgends eine Performanceverbesserung feststellen.
Kannst du auch nicht, denn default ist
primarycache=all, was metadata bereits mit abschmatzt.WENN, dann musst du
none mit metadata vergleichen.Entsprechend verhält es sich mit
secondarycache=all, aber nur wenn man ein cache-device hat.
primarycache=metadata ist vor allem für VMs interessant. Genauer gesagt für die Datasets oder zvols, auf denen die Images liegen. Da der Gast seinen eigenen Dateisystemcache implementiert und daher die Nutzdaten selbst cacht, ist es für den Host ausreichend, nur die Metdaten im Cache zu halten. Ansonsten würde man Daten doppelt cachen und das ist Verschwendung.Das ist eher für die Abstimmung der Cache-Größe relevant. Der default ist 'all', also metadaten + nutzdaten. 'metadata' läßt die nutzdaten nicht im ARC, und 'none' läßt gar nichts im ARC.
Das hat damit zu tun, dass es nur einen ARC gibt für alle Pools/Datasets/Filesysteme gemeinsam. Und idealerweise sollte ein Cache gerade so groß sein, dass er Platz für die regelmäßig genutzten Daten enthält - und das kann da schwierig werden.
Nehmen wir ein praktisches Beispiel: du hast einen schwung daten die regelmäßig genutzt werden, und die sind normalerweise im ARC. Dann hast du aber auch noch ein Archivlaufwerk mit einer Riesenmenge an Daten, die weder schnell noch oft gebraucht werden. Wenn jetzt der tägliche Backup (oder sowas) über das Archivlaufwerk geht, dann pressiert das ja nicht, aber die kommen trotzdem alle erstmal in den ARC, und quetschen dabei die tatsächlich ständig genutzten Daten raus (und die müssen danach wieder neu reingeladen werden). Um zB sowas zu vermeiden gibt es die 'metadata' Option pro dataset.
*cache='none' wäre die radikalere Variante, aber das kann recht ekelhaft werden: es wird dann wirklich nicht im ARC gespeichert, trotzdem muss alles gelesene erstmal in den ARC, und der Effekt kann dann fallweise sein, dass bei 128K recordsize für einen einzelnen Sektor diese 128K reingeladen werden, gleich wieder weggeschmissen werden, für den nächsten Sektor wieder reingeladen werden usw. - macht also meistens keinen Spass.
bananenBrot
Well-Known Member
Ah das wusste ich nicht. Werden bei =all auch Metadaten weggeworfen, wenn neue Daten in den ARC wandern?
Dann wäre =metadata ja doch hier sinnvoll, da es sich nur um ein Archivsystem handelt.
Ich wollte eigentlich noch mit SSDs als Special Device für Metadaten experimentieren aber wenn die Metadaten eh alle im ARC sind sollte das keinen Unterschied machen. (die sind doch alle im ARC, oder? Der Server hat 128GB RAM aber halt auch viele Dateien drauf...)
Edit: Ich sehe gerade:
Dann wäre =metadata ja doch hier sinnvoll, da es sich nur um ein Archivsystem handelt.
Ich wollte eigentlich noch mit SSDs als Special Device für Metadaten experimentieren aber wenn die Metadaten eh alle im ARC sind sollte das keinen Unterschied machen. (die sind doch alle im ARC, oder? Der Server hat 128GB RAM aber halt auch viele Dateien drauf...)
Edit: Ich sehe gerade:
Sind das bytes?
KobRheTilla
used register
Wenn du möglichst viel Metadaten im ARC haben möchtest, musst du ebenso vfs.zfs.arc_meta_limit erhöhen. Standardmäßig ist dies 1/4 von arc_max.
Rob
Ja, wäre sonst auch unsinnig.
sysutils/zfs-stats könnte dir beim Testen behilflich sein.
Bevor man da SSDs kauft, maximiert man lieber den RAM. Ist oft teurer, bringt aber mehr.
ARC ist der Level1-Cache, weil besser/schneller/höher/weiter...du weißt schon.
L2ARC wäre dann eben die nächstkleinere Baustelle und da nimmt man ssd/nvme.
Kann man machen, wenn man eh schon sowas rumliegen hat, aber prio sollte mehr RAM haben.
Genau das steuert arc_meta_limit. Damit wird nicht festgelegt wieviel metadaten in den ARC hineindürfen (weil ja eh immer alles erstmal in den ARC muss und dann mindestens solange drinbleibt wie es aktiv im Kernel referenziert ist) sondern nur wenns ans rauswerfen geht, was bevorzugt rausgeworfen wird.
arc_meta_limit muss man also vergrößern wenn man sehr viele Verzeichnisse hat und wenigstens die metadatan im cache halten will.
Wenn umgekehrt auf kleinen Systemen der ARC bei einem 'find' mit metadaten überläuft und das System crasht (kann jedenfalls mit FreeBSD Rel <= 12 vorkommen), dann nützt es kaum wenn man arc_meta_limit verkleinert (weil der 'find' die metadaten aktiv referenziert und sie nicht rausgeworfen werden können), sondern dann muss man kern.maxvnodes reduzieren.
jepp.
Zuletzt bearbeitet:
Das stimmt im Grundsatz, kommt aber auf den Usecase an. Wenn ich zB eine Datenbank hab, dann muss die aktive Datenmenge auch ganz in den ARC passen, sonst gibts nur ein reihum-rausgeschubse und keine Performance. (Und wenn ich dafür genug memory hab, dann muss ich eigentlich nicht den ARC nehmen, sondern kann die Datenbank selber cachen lassen, die weiß ja besser was sie braucht).
Wenn soviel memory nicht praktikabel ist, dann ist ein gut abgestimmter L2ARC eine sehr hübsche Variante die u.U. Faktor 10 schneller macht.
Ein Cache will dimensioniert werden - einfach nur ram kaufen soviel ins Board passt ist nicht unbedingt die wirtschaftlichste Lösung, wenn man seine aktive Datenmenge nicht weiß. Für ein normales Enduser-System spielt das alles keine Rolle, aber für einen Server macht es immer noch Sinn, seinen Usecase zu kennen.