Verzeichnis mit vielen Dateien langsam...

bsd4me

Well-Known Member
Hallo,

Vielleicht hat jemand eine Idee wo am ZFS zu tunen sein könnte -wenn überhaupt- um Performance mit ZFD zu verbessern. Die Grundlage sind ein 6 Platten raidz2 pool mit 4 TB Platten

zpool status
storage ONLINE 0 0 0
raidz2-0 ONLINE 0 0 0
ada2 ONLINE 0 0 0
ada3 ONLINE 0 0 0
ada4 ONLINE 0 0 0
ada5 ONLINE 0 0 0
ada6 ONLINE 0 0 0
ada7 ONLINE 0 0 0

und "more /boot/loader.conf"
...
vfs.zfs.arc_max="16G"

es geht dabei besodners um Verzeichnisse mit hundertausend oder auch mehr kleinen Dateien. Ich habe leider nicht die Zeit in die Tiefe da abzusteigen :)

Vielen Dank, Norbert
 
die gesamte Verarbeitung... Nun, da auf dem Server natürlich viele Programme/Prozesse laufen wirken sich solche Sachen evtl. auch auf andere aus. man kann z.B. bei starker Nutzung merken dass tools wie samtools um den Faktor 100 und noch mehr langsamer werden...
 
nun, aktuell läuft nix - daher auch keien Auslastung, aber ich konnte in der Vergangenheit schon beobachten, was die Platten am Anschalg waren
 
Du könntest versuchen, einen USB-Stick als ZIL einzurichten, eventuell bringt das was. Dies würde zumindest Schreibzugriffe in bestimmten Szenarien schneller machen.

Rob
 
nun, das ist keine gute Möglichkeit... ich schau später nochmals hier herein, muss unbedignt was anderes noch machen :)
Vielen Dank für die Beiträge - Norbert :)
 
Siehe es mal so: Bei UFS wäre bei 32768 Dateien Schluss gewesen... Ein ZIL könnte helfen und man könnte probieren den Cache auf Metadaten zu beschränken - bei so vielen Dateien macht es eh nur Sinn Inhalte zu cachen, wenn auf immer die gleichen Dateien zugegriffen wird - aber ich würde mal mit einem zfs set atime=off pool/dataset anfangen. Vorausgesetzt natürlich, dass du die atimes nicht braucht, aber eigentlich kann man gut ohne sie leben.
 
atime=off = gute Sache, hab ich auch.

Wenn die Platten durchweg auf Anschlag laufen (was der Flaschenhals an sich ist), dann wäre ZIL und L2ARC nur bedingt sinnvoll. Es würde das Problem nur zeitlich verschieben.

recordsize=1M sowie compression=lz4 (oder absoluter Ausnahmefall bei potenter CPU compression=gzip-7) sollte Plattenzugriffe einsparen. Allerdings erst, wenn die Dateien danach neu geschrieben wurden und je besser sie komprimierbar sind, desto gut. ;)

Wenn das auch nicht zufriedenstellend hilft, brauchst du mehr vdevs oder gleich den Tausch zu SSDs.
 
Vielen lieben Dank :) atime - da muss ich mal schauen... Der Tausch zu SSD ist leider nicht möglich... ich schau mal, was mir helfen wird...
 
https://www.ateamsystems.com/tech-blog/freebsd-partition-alignment-raid-ssd-4k-drive/
-> Per alignment könnte noch was zu holen sein, wenn du das nicht bereits so hast. (Ich selbst habe das noch nicht gebencht, aber es ist logisch)

Wenn nicht, sorum: Du hast zwar gute Redundanz (raidz2), aber ohne Kaltbackup würd ich die Finger davon lassen.
Grobe Schritte wären: eine(!) Platte aus dem Pool offline nehmen, Partition und alignment neu schreiben, zfs replace + resilver abwarten. Das dann mit jeder Platte durchexerzieren.
Nachteil: es ist sehr zeitaufwändig

Edit:
Was genau ist denn langsam?

Das wäre gut zu wissen. Ich dachte erst, es handelt sich um einen Vollast-24/7er. ;)
 
https://www.ateamsystems.com/tech-blog/freebsd-partition-alignment-raid-ssd-4k-drive/
-> Per alignment könnte noch was zu holen sein, wenn du das nicht bereits so hast. (Ich selbst habe das noch nicht gebencht, aber es ist logisch)

Wenn nicht, sorum: Du hast zwar gute Redundanz (raidz2), aber ohne Kaltbackup würd ich die Finger davon lassen.
Grobe Schritte wären: eine(!) Platte aus dem Pool offline nehmen, Partition und alignment neu schreiben, zfs replace + resilver abwarten. Das dann mit jeder Platte durchexerzieren.
Nachteil: es ist sehr zeitaufwändig

Edit:

Das wäre gut zu wissen. Ich dachte erst, es handelt sich um einen Vollast-24/7er. ;)

nun, an sich ist der Server meistens unter Vollast 24/7 :) :)
 
Nur so ins Blaue:

Wieviel RAM hat die Maschine?

Wie voll ist der raidz2 Pool bereits?

Hast du zufällig dedup für den raidz2 aktiv?
 
RAM: 512GB

# df /data
Filesystem 1G-blocks Used Avail Capacity Mounted on
storage 14368 9218 5150 64% /data

dedup ist nicht aktiv...
 
Der ARC-size ist m.W. standardmäßig wenn nichts anderes angegeben wird "RAM-halbe", d.h. in deinem Fall wäre das 256GB.
Läuft auf dem Server noch was anderes, Virtualisierung bzw Apps mit einigermaßen großem RAM-Bedarf?
Wenn nicht, würd ich die Size einfach mal testweise auf RAM-halbe raufsetzen und sehen, was passiert.
Mit dieser großen RAM Ausstattung von 512G solltest du sogar gefahrlos dedup für diesen Pool enablen können, ohne jegliche Performance-Einbußen (früher mal galt 1GB RAM pro 1TB Storage, das deckt das ja locker ab), außer halt direkt nach dem Enable, eine erhöhte CPU-Last, wenn er über die Daten rödelt.


Hast du zfs-stats installiert? Dann könnteste mal den ARC aktuell mit deinen 16GB beobachten, mittels
Bash:
zfs stats -A
bzw mit
Bash:
zfs stats -a
 
man kann z.B. bei starker Nutzung merken dass tools wie samtools um den Faktor 100 und noch mehr langsamer werden...

Ich frage mal anders herum: Sind ggf. auf anderen Systemen die Erfahrungen anders? Man kann jetzt natürlich solange an Settings rumschrauben bis irgendwann mal was fruchtet. Es könnte aber auch einen negativen Effekt haben. Aber Einstellungen wie Recordsize und Kompression gelten nur für neue Dateien, nicht für bestehende.

"Ist langsam" ist halt vielseitig. Ohne zu wissen wie der Zustand des Systems unter Auslastung so ist, ist das alles nur ganz grobes raten. Ich würde empfehlen vielleicht mal ein kleines Monitoring-Tool (z.B. prometheus) einzurichten, damit du mal einen Überblick bekommst, was auf der Kiste eigentlich so passiert ist.

Es steht für mich die Frage im Raum, ob hier einfach die reine Datenrate der Platten am Limit ist, oder ob es eher am Metadaten-Lookup liegt. Ein RAIDZ2 kann zwar schnell sein, aber zaubern kann es auch nicht.
 
ZFS ist prinzipiell ganz gut mit vielen kleinen Datein. Generelle Tips sind also schwierig. Am besten du beschreibst mal:

A) Deinen Workload auf der Maschine und wo er dann die performance Probleme hat.
B) Die Auslastung wärend dieser Probleme. Also ist die CPU am Anschlag, ist das IO-Wait am Anschlag oder weder noch. Und wie ist der RAM wärenddessen?

Ansonst wurde hier ja schon vieles genannt. Was bei ZFS die Performance nach unten treiben kann ist, wenn du es über längere Zeit am Kapazitätslimit betreibst.
Was auch nocht nicht genannt wurde: Bei Spikes in der Readperformance kann ein erhöhen des TXG Timeouts helfen (vfs.zfs.txg.timeout).
 
ZFS wird meiner Erfahrung nach nur bei 2 Sachen lahm - entweder Pool zu voll (>90%) oder dedup aktiviert mit zu wenig RAM (bzw generell zu wenig RAM im System), wobei letzteres bei der o.b. Maschine aber m.E. nicht zutrifft - außer, es würden Apps nebenher laufen, welche die 512 GB RAM vereinnahmen;

Sämtlichen anderen Kram, welcher jeweils zuverlässig ext und xfs killte - viele Dateien, viele kleine Dateien, viele Dateien mit spaßigen Dateinamen wie "a++-+++--++--++b--+zig-andere-Zeichen..+.c" (fragt nicht, alles schon gesehen!!) in rauhen Mengen, alles konnte ZFS performant ab.

Läuft ggf ein Task "innerhalb" der Maschine, welcher die Performance niederreißt?
Hatte mal so ne Maschine, eigentlich ausreichend RAM, gute I/O Performance der Platten, bis dann jeweils zu bestimmten Zeiten die Performance einbrach.
Stellte sich raus: das war ein interner cronjob, welcher TBytes an Daten von nem Pool zum anderen verschob, also Daten echt kopieren nicht irgendwie nur Zeiger umbiegen; da war die Maschine zu nix anderem mehr zu gebrauchen; kostete erstmal nicht viel CPU-Last und auch RAM hielt sich in Grenzen, aber scheinbar war da der interne Bus schon mit dieser Aktion dicht, mehr Daten konnte die halt einfach nicht bewegen - und dann schon gar nicht zum Netzwerk raus in so ner Situation.
Den Effekt konnte ich auch schon bei einigen Heim-PCs beobachten (unter Linux wie BSD) - sind scheinbar die Board-Chipsätze für nicht mehr I/O (als einen Stream) ausgelegt.
 
Der ARC-size ist m.W. standardmäßig wenn nichts anderes angegeben wird "RAM-halbe"
Leider nicht, er krallt sich weit mehr als einem lieb ist (80%, 90%? kenne die genaue Zahl nicht) und gibt zu zäh wieder frei, sodass ich seitdem prinzipiell limitiere, damit es nicht zum OOM kommt.
Die genaue workload wäre wirklich gut zu wissen, blind würde ich da aber auch mal 256G für den ARC zur Verfügung stellen, wenn anderweitig nicht gebraucht.

Dateinamen wie "a++-+++--++--++b--+zig-andere-Zeichen..+.c" (fragt nicht, alles schon gesehen!!)
Erinnert mich entfernt ans Downloadfolder, wenn ich an fremden Win-PCs sitze. avg_tuneup_setup.exe 13x vorliegen, BingBarSetup.EXE mindestens 5x. :ugly:
Klarer Fall für dedup, aber nein danke! :p
 
Der ARC-size ist m.W. standardmäßig wenn nichts anderes angegeben wird "RAM-halbe", d.h. in deinem Fall wäre das 256GB.
Läuft auf dem Server noch was anderes, Virtualisierung bzw Apps mit einigermaßen großem RAM-Bedarf?
Wenn nicht, würd ich die Size einfach mal testweise auf RAM-halbe raufsetzen und sehen, was passiert.
Mit dieser großen RAM Ausstattung von 512G solltest du sogar gefahrlos dedup für diesen Pool enablen können, ohne jegliche Performance-Einbußen (früher mal galt 1GB RAM pro 1TB Storage, das deckt das ja locker ab), außer halt direkt nach dem Enable, eine erhöhte CPU-Last, wenn er über die Daten rödelt.


Hast du zfs-stats installiert? Dann könnteste mal den ARC aktuell mit deinen 16GB beobachten, mittels
Bash:
zfs stats -A
bzw mit
Bash:
zfs stats -a

# zfs-stats -A

------------------------------------------------------------------------
ZFS Subsystem Report Thu Mar 12 11:17:43 2020
------------------------------------------------------------------------

ARC Summary: (HEALTHY)
Memory Throttle Count: 0

ARC Misc:
Deleted: 16.30 m
Recycle Misses: 0
Mutex Misses: 40.75 k
Evict Skips: 4.26 m

ARC Size: 100.10% 16.02 GiB
Target Size: (Adaptive) 100.00% 16.00 GiB
Min Size (Hard Limit): 97.48% 15.60 GiB
Max Size (High Water): 1:1 16.00 GiB

ARC Size Breakdown:
Recently Used Cache Size: 49.95% 8.00 GiB
Frequently Used Cache Size: 50.05% 8.02 GiB

ARC Hash Breakdown:
Elements Max: 1.09 m
Elements Current: 44.41% 483.31 k
Collisions: 262.25 k
Chain Max: 3
Chains: 1.66 k
 
Zurück
Oben