Wird die atime nicht für die cutoff-Tine bei der garbage vollection benötigt oder übersehe ich etwas?
Performance Probleme
- Thread starter Nerion
- Start date
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)
Soweit ich weiß setzt PBS das ohnehin explizit. Ich selbst nutze meist entweder
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
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
Last edited:
Kurzes Update.
Habe jetzt einen Server mit 12x NVMe auf ZFS aufgebaut mit Raidz2 und erste Tests sind sehr positiv.
Habe jetzt einen Server mit 12x NVMe auf ZFS aufgebaut mit Raidz2 und erste Tests sind sehr positiv.
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.
Nochmals danke an alle, die hier im Thread geholfen haben.
Für PBS mach ich hier compression=off denn der PBS komprimiert ja seine chunks schon. Und doppelt gemoppelt bringt da m.E. nix.
Haben Mann oder Frau auch eine Begründung dafür? M.E. spielen in der heutigen Welt kleine Dateien keine Rolle mehr.
Code:
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) }'
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.
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, LZ4 bei ZFS nicht aktiv zu haben.
Last edited:
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.
Einverstanden
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.
ZFS kann m.W. kein LZO und der Default ist LZ4. Vermutlich ist das aber egal.
Und ebenfalls ist es - bei PBS auf einem NAS wie hier - tatsächlich ziemlich egal, ob nun comp. on oder off. Ich erziele beim Schreiben randomisierter Files von 2 MB Größe, wie sie bei PBS typisch sind, gegen 400 MB/s.
Und ja, mit comp. off ist da rein optisch kein Unterschied.
Es ist aber schon so, daß es beim Space fast nix bringt. Hab comp derzeit on und es gibt im PBS-Repo einen Faktor 1.19x - bei VM-Disks liegt dies so von 1.5 bis 1.9x. Der wirkliche Vorteil vom PBS besteht in der Dedup der Chunks. Hab in einem Repo 15x und im anderen 30x.
Ich meine, ich hätte irgendwo gelesen, der letzte Record wäre dann 0-padded.
Aber auch hier ist m.E. gar nicht die Frage, ob nun 1.1 M oder 2x 1M übertragen werden... Weil es in jedem Fall zwei I/O-Vorgänge sind (für ZFS, bei 1M recordsize). Und der Flaschenhals, scheint es mir, ist eher die Anzahl der I/Os und nicht unbedingt die Länge. Deine Argumentation war ja:
Es sind aber in jedem Fall zwei Records, die ZFS verarbeitet. Und die werden auch noch bei RaidZ über mehrere Disks verteilt.
Sorry, natürlich lz4.
Denke ich auch. Das führt dann zu einem "richtigen" 1M record + 1M record der nur zu 10% aus Daten und zu 90% aus Nullen besteht.
Daraus resultiert ein 2M write ohne Kompression. Mit lz4 wäre es selbst bei nicht komprimierbaren Daten nur 1.1M gewesen, weil der zweite record die nullen komprimiert werden.
Übertragen ist dann glaube ich nochmal was anderes
Das könnte sein. Flaschenhals könnte halt sehr vieles hier sein.
@Nerion Was het der Support gemeint? Und wie sieht es aus mit VMs, die bereits mal gesichert wurden? Hast du da einen Output? Weil, wenn sich die VMs mit sagen wir 10GB/s lokal hashen lassen oder vielleicht sogar mit dem snapshot mode gearbeitet wird, sind die 1.5GB/s vermutlich nicht ganz so tragisch.