Hallo Forum,

 

vermutlich habe ich mir einen Bock geschossen (oder "hoffentlich" einen Bug gefunden) und komme hier nicht weiter bzw. sehe mittlerweile den Wald vor lauter Bäumen nicht mehr.

 

Kurz zum System:

 

• Unraid 7 im Unifi Netzwerk mit entspr. MACLAN anpassung
• 64 GB RAM
• 2x NICs, eine heißt zwar DMZ, führt aber in keine DMZ (um eventuelle Panik zu vermeiden)
• 1 Array. XFS, mit Parity
• diverse Pools, sowohl ZFS als auch XFS
• diverse Docker
• Nvidia GPU für Emby, Tdarr und Immich

 

Backup:

 

• Täglich automatisch auf externe USB HDD per Mgutt Script der wichtigsten Daten
• 1x Wöchentlich automatisch verschlüsselt auf NAS außer Haus und in Cloud per Duplicacy der wichtigsten Daten
• immer, wenn für nötig gehalten, manuelle Sicherung des gesamten Arrays auf interne NAS per Duplicacy (da kompirmiert)

 

Mods der Go File:

 

• Auto Unlock Array
• RAM-Disk for Docker json/log files v1.6 for 7.0.0 (ebenfalls genutzt für Emby, falls Transcode nötig)

 

Anpassungen seit Update auf V7:

 

• fastusr Fix
• Overlay2 Docker Storage Driver samt erneuten einspielen aller Docker
• Permit exclusive shares und anpassen der Docker und Mappings von ehemals Diskshare Appdata (mnt/cache/appdata) zurück zu mnt/user/appdata

 

Zum Problem:

 

Seit dem Update sind bisher keine Probleme aufgetretten. Nun versuche ich seit ein paar Tagen mal wieder ein manuelles Backup auf die interne NAS per Duplicacy zu fahren (das erste Mal unter Unraid 7). Das läuft erst eine Weile ohne Probleme, dann fängt Unraid an, sehr träge zu werden und reagiert teilweise nicht mehr. Wenn man dennoch irgendwann wieder aufs WebUI kommt sieht man, das ständig vom USB Stick gelesen wird.

 

Mein Verständiss von Unraid sagt mir, dass mir irgendwas den RAM zu Müllt und Unraid deswegen immer wieder das OS vom Stick in den RAM nachladen muss. Nur konnte ich bisher nicht rausfinden, was dieses Problem verursacht. Da es erst beim Backup auftritt habe ich die Dockermappings im Allgemienen und vor allem von Duplicacy mehrmals geprüft, kann aber keinen Fehler finden - eigene Betriebsblindheit als auch Unfähigkeit möchte ich an dieser Stelle auch nicht ausschließen.

 

Auch laufen in dieser Zeit keine Zugriffe auf Emby, was beim Transcoden ebenfalls in den RAM arbeitet, was aber auch in der Vergangenheit auch beim Backup keine Probleme darstellte.

 

Im Log, tauchen in dieser Zeit vermeht "php-fpm" Fehler auf, wie z.B. "php-fpm[11842]: [WARNING] [pool www] child 1425829 exited on signal 9 (SIGKILL) after 373.816196 seconds from start"

 

Ich vermute, dass es irgendein peinlicher Fehler meinerseits sein wird, denn ich aktuell jedoch einfach nicht erkenne bzw. finde. Daher hoffe ich, dass ihr mir weiter helfen könnt. Diagnostics liegt bei, falls noch noch weitere Infos benötigt werden, bitte Bescheid geben.

 

 

Edited March 1, 20251 yr by Gorosch

Nachtrag mit Info, was alles vom Stick ständig nachgeladen wird:

 

root@Datenschleuder:~# inotifywatch -r -t 30 /boot
Establishing watches...
Finished establishing watches, now collecting statistics.
total  access  close_nowrite  open  filename
1839   613     613            613   /boot/config/shares/
303    123     90             90    /boot/config/
171    57      57             57    /boot/config/plugins/dynamix/
108    54      27             27    /boot/
40     20      10             10    /boot/config/plugins/dynamix/notifications/agents/
40     20      10             10    /boot/config/plugins/dynamix/notifications/
15     5       5              5     /boot/config/plugins/ipmi/

 

 

Edited February 9, 20251 yr by Gorosch

Hat echt keiner eine Idee oder einen Ansatz, was as Problem verursachen könnte oder ich Gegenprüfen könnte? Oder fehlen noch Informationen? Oder habe ich irgendetwas geschrieben, was alle abhält oder verärgert hat?

35 minutes ago, Gorosch said:

was alle abhält oder verärgert hat?

sicher nicht

 

du hast zwar gemäß dem screen ne recht hohe Auslastung, aber noch nicht unbedingt "Anschlag"

 

 

zu deinem Issue an sich, ja, kann sein das da etwas in den RAM schreibt.

 

Jemand wie ich steigt ab hier normal bereits aus

 

On 2/8/2025 at 9:57 AM, Gorosch said:

• RAM-Disk for Docker json/log files v1.6 for 7.0.0 (ebenfalls genutzt für Emby, falls Transcode nötig)

 

warum, weil das für mich (persönlich) nonsens ist  und ich da nicht weiter schauen will wenn jemand so etwas einbaut

 

Memory Leaks sind auch nicht immer einfach zu finden ... hier war es mal rclone mount sync wo immens gefressen hatte ...

 

aber schau doch mal beispielsweise die RAM Last deiner Dockers an, speziell wenn ein Backup läuft

 

Docker Tab, oben rechts advanced aktivieren ... durchgehen ob sich da massiv was ändert.

 

oder ein tool wie ctop installieren, damit kannst du auch nachschauen ... ob etwas auffällig wäre.

 

48 minutes ago, Gorosch said:

Hat echt keiner eine Idee oder einen Ansatz, was as Problem verursachen könnte oder ich Gegenprüfen könnte? Oder fehlen noch Informationen?

 

Ich kann mich nur alturismo anschliessen.

 

Ich bin eher bei Hardware unterwegs und unraid zeigt bei mir auf meinen Maschinen ein solches Problem nicht.

Ich habe es aber auch nicht so speziell angepasst (was bei urbnaid default ja nicht vorgesehen ist).

 

Für mich ist das einfach zu spezifisch/hoch. Da müssen Dir Andere helfen.

Dann schon mal Danke für eure Antworten. Die RAM Disk Mod werde ich mal raus nehmen. Wird dann erst beim nächsten Neustart zum tragen kommen. Auch ctop spuckt bei mir keine Auffälligkeiten aus:

 

 

Lediglich Duplicacy nutzt aktuelle alle seine erlaubten Ressourcen, da das Backup läuft. Sonst dümpelt alles andere innerhalb der normalen Parameter (Geordi La Forge wäre Stolz bei diesem Satz).

 

Alle Docker sind auch per extra Parameter in der Nutzung des RAMs und CPU limitiert. Es tritt jedoch nur dann auf, wenn der Dockerdienst läuft - die Frage ist nur, welcher Docker nun das Problem ist und ob der Docker wirklich das Problem ist oder nur aufgrund der Last nur den Crash auslöst, da vielleicht doch was anderes den RAM voll prügelt. Wenn ich nur einzelne Docker laufen lasse, tritt das Problem nicht auf. Sobald das System jedoch im normalen Betrieb mit aktiven Backupjob irgendwann in die Knie geht (WebUI und SSH nicht mehr zuverlässig erreichbar, jedoch kein kompletter Crash von Unraid) und man es irgendwann dennoch schafft, den Docker Dienst zu stoppen, fängt sich das System wieder und reagiert wieder ganz normal. Ach das ständige lesen vom Stick stoppt dann. 

 

Edited February 10, 20251 yr by Gorosch

21 minutes ago, Gorosch said:

fängt sich das System wieder und reagiert wieder ganz normal. Ach das ständige lesen vom Stick stoppt dann. 

Wenn es denn nur beim Backup eintritt, wo schreibst du das denn hin ?

 

Das war auch mal hier ein Thema ...

1. Täglich automatisch auf externe USB HDD per Mgutt Script der wichtigsten Daten
2. 1x Wöchentlich automatisch verschlüsselt auf NAS (NFS) außer Haus und in Cloud (B2B) per Duplicacy der wichtigsten Daten
3. Immer, wenn für nötig gehalten, manuelle Sicherung des gesamten Arrays auf interne NAS (SMB) per Duplicacy (da komprimiert)

 

Der Punkt drei läuft nun zum ersten Mal unter V7 und macht auch erst seit dem Probleme.

Edited February 10, 20251 yr by Gorosch

2 hours ago, Gorosch said:

• 1x Wöchentlich automatisch verschlüsselt auf NAS (NFS) außer Haus und in Cloud (B2B) per Duplicacy der wichtigsten Daten
•  

nur gefragt, die Cloud wird direkt über Dupli angesprochen oder ist dies zufällig ein rclone mount ?

 

2 hours ago, Gorosch said:

1. Immer, wenn für nötig gehalten, manuelle Sicherung des gesamten Arrays auf interne NAS (SMB) per Duplicacy (da komprimiert)

 

läuft zum ersten mal generell ... ? daher auch v7,  oder macht erst seit v7 Probleme ? und lief unter v6 noch einwandfrei durch ?

27 minutes ago, alturismo said:

nur gefragt, die Cloud wird direkt über Dupli angesprochen oder ist dies zufällig ein rclone mount ?

 

läuft zum ersten mal generell ... ? daher auch v7,  oder macht erst seit v7 Probleme ? und lief unter v6 noch einwandfrei durch ?

Alle Backups, bis auf das USB HDD Backup, werden direkt über Dupli angesprochen und sind auch als Storage in Dupli konfiguriert.

 

Davon gehen zwei kleine, wöchentliche Backups auf die B2B Cloud und eins auf einen externen unraid Server, welcher als NFS in UD eingebunden ist. Das große Backup geht auf eine interne NAS, welche als SMB in UD eingebunden ist. Beide UD Remote Shares sind entsprechend in Dupli eingebunden.

 

Alle Dupli Backups laufen seit min. 2020 bisher ohne Probleme. Auch die beiden "kleinen", wöchentlichen Backups liefen schon mehrmals seit dem Updatre auf V7 ohne Probleme. Das "große" Backups des ganzen Arrays lief unter V6 ebenfalls schon Jahre ohne Probleme. Aber eben nur immer nach Bedarf, also nicht automatisiert. Das letzte Mal irgendwann im Oktober 2024 auf der V6. Nun das erste Mal auf V7.

Servus,

 

vor zwei Tagen habe ich die interne NAS von SMB auf NFS umgestellt und ein Vollbackup angestoßen (36TB). Seit dem läuft auch immer noch alles normal, kein Einfrieren und kein ständies nachladen vom Stick. Das Backup läuft zwar Stand jetzt noch 1 Tag und 10 Stunden, aber solange lief es mit SMB und Unraid 7 nicht stabil durch, ohne dass der RAM voll lief.

 

Leider sehe ich sowohl under TOP als auch CTOP keine großartigen unterschiede im vergleich zur SMB Konfig.

 

 

 

Aber nach aktuellen Stand mag irgendetwas keine größere Datenschieberei mit SMB unter Unraid V7. Unter V6 hatte ich mit dieser Kombi keine Probleme. Ich konnte bisher leider noch nicht rausfinden, was genau in der Kombi das Problem auslöst.

 

Wenn das Backup fertig ist (oder beim nächsten Freeze - hoffentlich nicht) gebe ich nochmals Rückmeldung.

 

 

Edited February 13, 20251 yr by Gorosch

3 hours ago, Gorosch said:

Aber nach aktuellen Stand mag irgendetwas keine größere Datenschieberei mit SMB unter Unraid V7.

 

Nachdem ich vor rund 1 Woche gesamt ca. 2,x TB über SMB auf mein unraid 7.0 geschoben habe und dahingehend keine Probleme bemerkt habe, kann ich diese Aussage so nicht stützen.

Ich sehe >1 TB schon als größere Datenschieberei an.

 

Aktuell läuft von einer Win11 VM ein Checksummenlauf, bei dem alle >300TB Dateien per SMB Freigabe von dem unraid 7.0.0.stable mit ausgelesen und per checksumme in der Win11 VM verifiziert werden. Auch das läuft bisher problemlos (ist aber vielleicht erst zur Hälfte oder so durch).

Edited February 13, 20251 yr by DataCollector

Die ersten paar TB gab es bei mir auch keine Probleme. Erst wenn der Job eine Weile lief, gab es diese Probleme - also wenn schon mehre TB im zweistelligen Bereich verabreitet worden sind. Daher muss ich in diesem Kontext leider sagen, dass 2,x TB hier nicht die "größere Datenschieberei" ist, die das Problem bei mir verursacht sondern hier von min. 10-15 TB die Rede ist, ab wann es zu Problemen kommt.

 

Hätte ich nur ein inkrementelles Backup gefahren und kein Vollbackup, hätte ich dieses Problem aber wahrscheinlich auch nicht gehabt. Zumindest kurz nach dem Update auf V7 habe ich auf dem System auch "kleinere" Datenmengen (auf den Kontext bezogen) von unter 5 TB vom Proudktivsystem (Unraid) weg zum Langzeitdatengrab (Synology NAS, SMB per UD) bewegt und hatte da auch keine Probleme. 

 

Und ja, 2 TB als auch 5 TB sind natürlich eine ganze Menge an Daten. Aber hier auf das Ganze betrachtet (36TB Array, ca. 4 TB in diversen Pools) keine Menge, die mir bisher Probleme machte.

Edited February 13, 20251 yr by Gorosch

16 minutes ago, Gorosch said:

Die ersten paar TB gab es bei mir auch keine Probleme. Erst wenn der Job eine Weile lief, gab es diese Probleme - also wenn schon mehre TB im zweistelligen Bereich verabreitet worden sind.

 

Ich glaube, daß ich meinen aktiuell laufenden Checksummenlauf über >300TB erwähnte. welcher aktuell vielleicht bei geschätzt 35 % sein sollte?

AAlso sind nun mmutmaßlich mehr als 100TB üer SMb gelesen worden und mein Ram Speicherverbreich liegt laut Dahboard aktuell weiterhin bei etwas mehr als 50 Prozent von 128GB Ram (bei 2 laufenden VM mit einmal 24576M und einmal 20480M zugewiesenem RAM +  1 Docker).

Wenn also die beiden VMs zusammen rund 45GB fressen und in Summe vielleicht 60-70GB Ram laut Dashboard belegt sind, kann ich weiterhin i´n dem seit mehr als 13 Tagen laufenden unraid 7.0.0 stable bei mir etwas erkennen, was einem Speicherleck nahe kommt.

 

 

16 minutes ago, Gorosch said:

Daher muss ich in diesem Kontext leider sagen, dass 2,x TB hier nicht die "größere Datenschieberei" ist, die das Problem bei mir verursacht sondern hier von min. 10-15 TB die Rede ist, ab wann es zu Problemen kommt.

 

Tja, Du hast den Checksummenlauf mit >300TB wohl überlesen.

 

1 hour ago, DataCollector said:

Tja, Du hast den Checksummenlauf mit >300TB wohl überlesen.

 

Ja, dass habe ich defintiv. Du machst deinem Namen Ehre.

 

Dann kann es echt nur an der Kombi Dupli mit größere Datenmengen und SMB liegen und meinem System liegen. Nur das warum und weshalb fehlen noch.

10 minutes ago, Gorosch said:

Dann kann es echt nur an der Kombi Dupli mit größere Datenmengen und SMB liegen und meinem System liegen. Nur das warum und weshalb fehlen noch.

ja, da bleibt nur das Dupli intern alles ablegt bevor es raus geht usw usw ... und damit den Ram voll schreibt.

 

wenn du das nochmals testen willst, limitiere den RAM des Dockers, unter Extra Parameter

 

--memory="4096m"

 

währen jetzt 4 GB Ram max für den Docker ...

Danke für den Tipp. Bei mir sind jedoch generell alle Docker bereits über die Extra Paramter limitiert, was CPU und RAM angehen. Auch Dupli - allerdings mit 8 GB statt mit 4 GB.

 

14 minutes ago, Gorosch said:

Danke für den Tipp. Bei mir sind jedoch generell alle Docker bereits über die Extra Paramter limitiert, was CPU und RAM angehen. Auch Dupli - allerdings mit 8 GB statt mit 4 GB.

 

stimmt, da war was ...

 

dann bin ich langsam raus, du sprichst auch dieses smb target direkt per smb aus dupli heraus an ...

 

da läuft ja nicht einmal was durch Unraid normal durch ... bei /mnt/remotes/... je nachdem ... aber so, sorry.

 

du kannst mal einen bug report aufmachen, aber das wird schwer ...

6 minutes ago, alturismo said:

stimmt, da war was ...

 

dann bin ich langsam raus, du sprichst auch dieses smb target direkt per smb aus dupli heraus an ...

 

da läuft ja nicht einmal was durch Unraid normal durch ... bei /mnt/remotes/... je nachdem ... aber so, sorry.

 

du kannst mal einen bug report aufmachen, aber das wird schwer ...

 

Ok, da habe ich wohl bei "direkt aus dupli heraus" was falsch verstanden. Es geht schon direkt aus Dupli raus:

 

Aber "/backuproot-remote/" führt innerhalb des Dockermapping auf "/mnt/remotes" - wie gesagt, über UD eingebunden:

 

Nur eben seit zwei Tagen über NFS zwecks Test statt wie bisher die letzten Jahre über SMB. Und seit NFS bisher eben ohne Probleme, wie eben auch SMB unter V6. Aber das Backup ist noch nicht durch. Nur kam ich mit SMB und V7 eben soweit gar nicht mehr.

Edited February 13, 20251 yr by Gorosch

8 hours ago, Gorosch said:

Ok, da habe ich wohl bei "direkt aus dupli heraus" was falsch verstanden. Es geht schon direkt aus Dupli raus:

 

nicht wirklich, du schiebst auf einen lokalen mountpoint (was ein smb mount ist), ok, zumindest könnte hier ein Ansatz sein

 

direkt wäre dies gewesen https://docs.duplicati.com/backup-destinations/standard-based-destinations/cifs-aka-smb-destination

 

dann würde ich dies im unassigned devices Thread mal anbringen mit allen Infos, @dlandon kann da sicher besser helfen wenn ein smb mount jetzt evtl. lokal "voll" läuft und damit das OSins stocken kommt, ob das überhaupt ein Thema sein kann oder wo ggf. der Hintergrund liegt ...

Danke für den Tipp. Werde ich machen. Ich warte nur noch die restlichen Stunden des Backups ab, ob es nun wirklich bis zum Schluss per NFS durchlauft.

Wie versprochen die Rückmeldung:

Nach einigen Tests kann ich mit Sicherheit sagen, dass die Kombi Unraid V7 mit Duplicacy Backup und größeren Datenmengen (zweistelliger TB Bereich) auf ein SMB Share über UD für ein Memoryproblem sorgt, was dazu führt, das Unraid immer wieder vom Stick laden muss. Über NFS gibt es keine Probleme. Dies wurde Mehrmals die letzten Tage mit beiden Variationen getestet.

 

Warum und weshalb konnte ich leider nach wie vor nicht in Erfahrung bringen. Sowohl jegliche Art von TOP als auch die Logs spucken zumindest für mich nichts verwertbares oder aufälliges aus.

 

Ob das nun an Dupli, UD oder Unraid liegt, weiß ich leider nicht. Ich werde es jedenfalls Mal im UD Thread weiter geben, da hier SMB und NFS zumindet zusammen laufen. Irgendwo muss man ja anfangen.

 

Ich kann das Problem damit umgehen, dass ich eben NFS statt SMB nutze, was für mich weder einen Vorteil noch Nachteil bringt. Deswegen kann ich damit leben. Bis auf die Tatsache, dass mein Ego nun angekratzt ist, da ich den Fehler nicht finde und lösen kann. 😅

"die Kombi Unraid V7 mit Duplicacy Backup und größeren Datenmengen (zweistelliger TB Bereich) auf ein SMB Share"

 

Das macht bei mir "jedes" BackUp oder Sync Programm mit großen Datenmengen (wenn nicht schon das meiste auf dem Ziel liegt, dann kein Problem). Egal ob im Docker oder per Script. Die "Eingrenzung" Speicher im Docker bringt zwar das ctop dann max. z.b. 2GB anzeigt aber SMB scheint immer weiter zu puffern bis kein Ram mehr da ist. Dann versucht unraid scheinbar doch einen swap zu machen (kann es aber nicht im Originalzustand) und läuft sich tot. Nur Neustart per Schalter hilft da bei mir.

On 2/21/2025 at 10:05 AM, Gorosch said:

Ob das nun an Dupli, UD oder Unraid liegt, weiß ich leider nicht. Ich werde es jedenfalls Mal im UD Thread weiter geben, da hier SMB und NFS zumindet zusammen laufen. Irgendwo muss man ja anfangen.

 

da kam ein Hinweis zum testen, smb Multichannel mal deaktivieren da nicht konfiguriert (nur 1 NIC)

10 minutes ago, alturismo said:

da kam ein Hinweis zum testen, smb Multichannel mal deaktivieren da nicht konfiguriert (nur 1 NIC)

 

Das ist noch ein Überbleibsel, was ich mal getestet habe. Bringt bei 2x 1GbE übrigens nichts bzw. keine relevanten Vorteile. Habe ich den Eintrag wohl nicht sauber gelöscht. Schande. Aber das ist jetzt zumindest mal ein Anhaltspunkt, denn ich angehen kann. Dafür schon Mal danke.  Diese Woche werde ich das nicht gegen Testen können. Werde aber Ende nächster Woche wahrscheinlich schon Feedback geben können.