Performance Probleme

[Johannes S]

Noatime ist bei mir auch default, das bringt natürlich beim lesen eine Menge.

Wird die atime nicht für die cutoff-Tine bei der garbage vollection benötigt oder übersehe ich etwas?

 

[Falk R.]

Die Garbage Collection prüft ob ob ein Chunk noch referenziert ist. Das löschen des letzten Chunks, was ja getrackt wird, ist ja kein lesen sondern auch ein schreiben. Atime ist ja access Time (lesen)

 

[Impact]

Soweit ich weiß setzt PBS das ohnehin explizit. Ich selbst nutze meist entweder relatime oder lazytime.
Relevant:
- https://forum.proxmox.com/threads/z...fect-on-garbage-collection.76590/#post-451830
- https://forum.proxmox.com/threads/pbs-datastore-on-zfs-dataset-without-atime.116383/#post-604652

 

[Nerion]

Kurzes Update.
Habe jetzt einen Server mit 12x NVMe auf ZFS aufgebaut mit Raidz2 und erste Tests sind sehr positiv.

 

[Nerion]

Ich möchte hier noch ein finales Update geben. Nachdem wir nun alle PBS auf ZFS umgestellt haben, erreichen wir gigantische Backupzeiten und Datenübertragungsraten. Für alle die vor dem gleichen Problem stehen. Einfach auf ZFS umstellen, und das Problem ist gelöst.

Nochmals danke an alle, die hier im Thread geholfen haben.

 

[6equj5]

Habe mit ZFS keine Erfahrung. Hast da einen Best Practise Guide irgendwo? Muss ich da noch was einstellen?

z.B.

• compression=lz4
• atime=off
• recordsize=1M
• xattr=sa

Für PBS mach ich hier compression=off denn der PBS komprimiert ja seine chunks schon. Und doppelt gemoppelt bringt da m.E. nix.

Default ist recordsize=128k, Mann und Frau gehen heute zu recordsize=64k über.

Haben Mann oder Frau auch eine Begründung dafür? M.E. spielen in der heutigen Welt kleine Dateien keine Rolle mehr.

find /path/to/pbs-repo -type f -print0 | xargs -0 ls -l | awk '{ n=int(log($5)/log(2)); if (n<10) { n=10; } size[n]++ } END { for (i in size) printf("%d %d\n", 2^i, size[i]) }' | sort -n | awk 'function human(x) { x[1]/=1024; if (x[1]>=1024) { x[2]++; human(x) } } { a[1]=$1; a[2]=0; human(a); printf("%3d%s: %6d\n", a[1],substr("kMGTEPYZ",a[2]+1,1),$2) }'

Das liefert bei mir:

Also der weitaus größte Teil der Dateien auch vom PBS liegt bei 1M oder größer. Daher steht bei mir die recordsize bei 1M.

 

[Impact]

ARC wird aber auch komprimiert und ich denke dass du keine Performancegewinne messen kannst.

 

[IsThisThingOn]

Für PBS mach ich hier compression=off denn der PBS komprimiert ja seine chunks schon. Und doppelt gemoppelt bringt da m.E. nix.

Das ist IMHO falsch.

Angenommen dein recordsize ist 1M. Ein chunk kann von 4MB auf 1.1M komprimiert werden von PBS.
Nun müssen zwei 1M records angelegt werden, sprich 2M storage mit compression off.
Mit LZO wären es nur 1.1M gewesen.

Gibt eigentlich fast nie einen Grund, LZO bei ZFS nicht aktiv zu haben.

 

[Tarakesh]

Das ist IMHO falsch.

Angenommen dein recordsize ist 1M. Ein chunk kann von 4MB auf 1.1M komprimiert werden von PBS.
Nun müssen zwei 1M records angelegt werden, sprich 2M storage mit compression off.
Mit LZO wären es nur 1.1M gewesen.

Gibt eigentlich fast nie einen Grund, LZO bei ZFS nicht aktiv zu haben.

Tatsäch so nicht korrekt.
ZFS nutzt immer die kleinste Recordsize die benötigt wird BIS HOCH zum eingestellten maximum egal ob kompression an ist oder nicht.
In dem fall wären es also 1x1MB + 1x128k oder 256k je nach dem obs noch in den 128k reinpasst.

 

[IsThisThingOn]

ZFS nutzt immer die kleinste Recordsize die benötigt wird BIS HOCH zum eingestellten maximum

Einverstanden

In dem fall wären es also 1x1MB + 1x128k oder 256k je nach dem obs noch in den 128k reinpasst.

Das glaube ich hingegen nicht. AFAIK ist die record size zwar generell wie du richtig erwähnt hast eine max Variable, ABER die record size kann für ein einzelnes File nicht variabel sein.
Ein File als 1MB + 16k record zu speichern ist also AFAIK nicht möglich.
Es müssen zwei 1MB records sein.