Cache Problem


speedycxd

Recommended Posts

Hallo,

 

Ich habe bei einigen Dockern Probleme mit meinem Ram bzw Rootfs gehabt und wusste nicht woran es liegt. Ich glaube ich habe den Fehler gefunden allerdings weiß ich nicht wie es dieses Rückgängig machen kann.

 

Irgendwie ist das beim Verschieben des Caches passiert und wahrscheinlich habe ich die Docker nicht deaktiviert, so das ich jetzt zwar einen neuen cache habe aber das System nutzt jetzt den alten und den neuen cache zusammen obwohl ich den Pfad geändert habe.

 

Also hier mal mit Bild.

 

Oben cache ist mein aktueller cache und user war der alte, der jetzt aber quasi gespiegelt wird.

Wie kann ich dieses Problem beheben?

 

Vielen dank für eure Hilfe

2022-04-30 12.17.17 192.168.178.53 c32f2f426826.jpg

Edited by speedycxd
Link to comment
2 hours ago, jj1987 said:

Also eigentlich ist "/user" die Summe aus Cache und Array, "/user0" dann nur Array und "/cache" halt Cache

Ja aber ich habe jetzt das Problem das einige Docker cache/appdata und user/appdata gleichzeitig nutzen dadurch kommt es wohl das mein rootfs mit 100% belastet wird.

 

Wie bekomme ich es jetzt hin das nur in auf einem geschrieben wird?

 

Link to comment
7 minutes ago, speedycxd said:

das einige Docker cache/appdata und user/appdata gleichzeitig nutzen

Naja, dann wäre der erste Schritt die einzelnen Docker mal durchzugehen, wo welcher Pfad eingetragen ist und das zu vereinheitlichen

Dann alle Docker stoppen, den Docker Service stoppen, Einstellungen des Docker Service prüfen (welcher Pfad wird hier für appdata genannt? ggfs ändern), appdata auf Cache=Yes setzen, Mover starten. Warten bis fertig.

Dann appdata wieder auf Cache=prefer setzen, wieder Mover starten. Warten bis fertig.

Docker Service starten, gewünschte Docker starten.

Link to comment

Moment, dein rootfs wird vollgeschrieben?

Heißt dein Cache eventuell gar nicht cache und du hast aber manuell irgendwo den Pfad "/cache" eingetragen?

Dann wird das nämlich direkt in rootfs erstellt und entweder in den RAM oder auf den USB-Stick geschrieben, weiß ich gerade aus dem Kopf nicht. So oder so NICHT empfehlenswert.

Link to comment
3 minutes ago, jj1987 said:

Moment, dein rootfs wird vollgeschrieben?

Heißt dein Cache eventuell gar nicht cache und du hast aber manuell irgendwo den Pfad "/cache" eingetragen?

Dann wird das nämlich direkt in rootfs erstellt und entweder in den RAM oder auf den USB-Stick geschrieben, weiß ich gerade aus dem Kopf nicht. So oder so NICHT empfehlenswert.

Japp genau das ist es..man sieht es erst am Ram und wenn ich mir rootfs anschaue läuft er komplett voll dann.

Die Pfade hatte ich im Conatiner Manuell geändert zum richtigen pfad auf dem cache. Aber auch wenn ich es wieder über user/appdata laufen lasse besteht das Problem. Allerdings nur bei bestimmten Dockern. Bei dem meisten besteht da kein Problem.

Link to comment
14 minutes ago, jj1987 said:

Dann solltest du drauf basierend mal auf die Fehlersuche gehen. Anscheinend ist bei den betroffenen Dockern ja irgendwas abweichendes eingestellt.

Ja ich schaue dort nochmal, habe aber entsprechend den Pfad eingestellt.

Kann es sonst auch sein weil unter Einstellungen Docker der Standard pfad user/appdata ist?

Ich meine ich änder den ja eh Manuell deswegen sollte es ja kein problem sein oder?

 

2022-04-30 19.42.15 192.168.178.53 8742c6a1987d.jpg

Link to comment
7 hours ago, speedycxd said:

Ja aber ich habe jetzt das Problem das einige Docker cache/appdata und user/appdata gleichzeitig nutzen

Das spielt vom Prinzip gar keine Rolle, wenn es ein Pool namens "cache" gibt.

 

7 hours ago, speedycxd said:

dadurch kommt es wohl das mein rootfs mit 100% belastet wird.

Das Root-Verzeichnis, also dein RAM, wird nur belastet, wenn in einen Pfad geschrieben wird, der nichts mit deinem Array oder deinen Pools zu tun hat.

 

Also hast du einen Pool namens "cache"? Wenn nein, dann ist das dein Problem.

 

 

7 hours ago, speedycxd said:

Aber auch wenn ich es wieder über user/appdata laufen lasse besteht das Problem.

Das passiert aber nur, wenn man zB "cache" bei dem appdata-Share als Pool hinterlegt hat und dann den Pool "cache" entfernt UND der Ordner /mnt/cache existiert (der dann kein Mount mehr auf die SSD ist, sondern ein Ordner im RAM).

 

Eigentlich ziemlich simpel.

 

Was gibt das aus:

findmnt /mnt/cache

 

Bei mir zB das:

TARGET     SOURCE         FSTYPE OPTIONS
/mnt/cache /dev/nvme0n1p1 xfs    rw,noatime,attr2,inode64,logbufs=8,logbsize=32k,noquota

 

 

Ist das Ergebnis bei dir dagegen leer, dann hast du keinen Pool mit dem Namen "cache". In dem Fall ist alles was in /mnt/cache liegt, bei dir im RAM.

 

Nun könntest du überlegen was du mit den Dateien darin machst. Ich vermute mal, dass du sie nicht brauchst. Dann könntest du alles löschen (Achtung löscht alles unwiederbringlich!):

rm -r /mnt/cache

 

Wenn jetzt kein Container mehr den direkten Pfad /mnt/cache verwendet, wird /mnt/user/appdata auch nicht mehr nach /mnt/cache schreiben.

 

Den selben Effekt hättest du, wenn du den Server einfach neu startest, denn der Ordner /mnt/cache wird nicht von Unraid erstellt, wenn es keinen Pool gibt. Sollte er nach einen Neustart doch wieder da sein, dann nur, weil es immer noch einen Container gibt, wo /mnt/cache hinterlegt ist.

 

Ich weise dich aber schon mal darauf hin, dass alle deine Container vermutlich korrupt sind, denn in den RAM schreiben, der dann voll läuft und ein Serverneustart... da gehen logischerweise Daten verloren.

Link to comment

Ja ein Cache pool existiert bei mir und die Ausgabe sagt.

 

/mnt/cache /dev/nvme0n1p1 btrfs  rw,noatime,ssd,discard=async,space_cache=v2,subvolid=5,subvol=/

 

12 hours ago, mgutt said:

Das Root-Verzeichnis, also dein RAM, wird nur belastet, wenn in einen Pfad geschrieben wird, der nichts mit deinem Array oder deinen Pools zu tun hat.

 

Ok dann habe ich hier scheinbar doch irgendwo eine Fehler gemacht in dem Docker.

Wie ich schon sagte läuft ja mit allen anderen alles ganz normal rootfs liegt da bei 6% und meine RAM Auslastung im schnitt bei 18% 

 

Danke erstmal für deine ausführliche Erklärung. 

Link to comment
39 minutes ago, speedycxd said:

Ok dann habe ich hier scheinbar doch irgendwo eine Fehler gemacht in dem Docker.

Dann ist nicht /mnt/cache dein Problem, sondern ein anderes Verzeichnis.

 

Führe mal das aus um alle Dateien nach Größe sortiert ausgeben zu lassen, die im RAM liegen:

 

du -ah --one-file-system / --exclude="proc" --exclude="run" --exclude="sys" | grep -v '\s/[^.]*$' | sort -rh | head -50

 

Findest du so das Problem? zB Dateien in /mnt dürfen dabei nicht auftauchen.

Link to comment
25 minutes ago, mgutt said:

Findest du so das Problem? zB Dateien in /mnt dürfen dabei nicht auftauchen.

 

Die Ausgabe sagt:

 

28M     /usr/lib64/libicudata.so.68.1
28M     /usr/lib64/libicudata.so.67.1
12M     /tmp/community.applications/tempFiles/templates.json
12M     /tmp/community.applications/tempFiles
12M     /tmp/community.applications
7.1M    /etc/udev/hwdb.bin
5.8M    /usr/local/emhttp/plugins/dynamix.vm.manager
5.8M    /lib/udev/hwdb.d
5.4M    /tmp/CA_logs/ca_log.txt
5.2M    /tmp/fix.common.problems/templates.json
5.2M    /tmp/fix.common.problems
4.9M    /usr/local/emhttp/plugins/dynamix.vm.manager/novnc
4.6M    /usr/share/hwdata/oui.txt
4.2M    /usr/lib64/perl5/CORE/charclass_invlists.h
4.1M    /usr/local/emhttp/plugins/dynamix.vm.manager/novnc/vendor
4.0M    /usr/src/linux-5.10.28-Unraid
3.9M    /usr/local/emhttp/plugins/dynamix.vm.manager/novnc/vendor/browser-es-module-loader
3.8M    /usr/local/emhttp/plugins/dynamix.vm.manager/novnc/vendor/browser-es-module-loader/dist
3.7M    /usr/src/linux-5.10.28-Unraid/System.map
3.7M    /usr/local/emhttp/plugins/dynamix.vm.manager/novnc/vendor/browser-es-module-loader/dist/babel-worker.js
3.6M    /usr/lib64/perl5/CORE/libperl.so
3.6M    /usr/lib64/libvirt.so.0.6005.0
3.6M    /usr/lib64/libpython3.9.so.1.0
3.5M    /usr/share/qemu/edk2-x86_64-secure-code.fd
3.5M    /usr/share/qemu/edk2-x86_64-code.fd
3.5M    /usr/lib64/libsmbd-base-samba4.so
3.5M    /usr/lib64/libndr-standard.so.0.0.1
3.2M    /usr/lib64/libicui18n.so.68.1
3.1M    /usr/lib64/libicui18n.so.67.1
2.9M    /usr/lib64/locale/en_US.utf8
2.9M    /usr/lib64/libIlmImf-2_2.so.22.0.0
2.9M    /lib64/libcrypto.so.1.1
2.8M    /lib/udev/hwdb.d/20-pci-vendor-model.hwdb
2.7M    /usr/lib64/perl5/auto/Encode/JP/JP.so
2.7M    /usr/lib64/libmpfr.so.6.1.0
2.5M    /usr/lib64/locale/en_US.utf8/LC_COLLATE
2.4M    /usr/lib64/perl5/auto/Encode/KR/KR.so
2.3M    /lib64/liblvm2cmd.so.2.03
2.2M    /usr/lib64/libndr-samba4.so
2.2M    /lib64/libc-2.30.so
2.1M    /usr/lib64/perl5/auto/Encode/CN/CN.so
2.0M    /usr/share/qemu/ovmf-x64/OVMF-pure-efi.fd
2.0M    /usr/lib64/perl5/auto/Encode/TW/TW.so
2.0M    /usr/lib64/libicuuc.so.68.1
2.0M    /usr/lib64/libicuuc.so.67.1
1.9M    /usr/share/qemu/ovmf-x64/OVMF_CODE-pure-efi.fd
1.9M    /usr/lib64/libstdc++.so.6.0.28
1.9M    /usr/lib64/libisl.so.22.0.1
1.8M    /usr/share/perl5/Unicode/Collate/allkeys.txt
1.8M    /usr/share/hwdata/manuf.txt
sort: write failed: 'standard output': Broken pipe
sort: write error

 

Nur am Ende gibt es wirite error.

 

Link to comment
5 minutes ago, mgutt said:

Ist der RAM denn jetzt voll?

Nein es ist alles normal, und das passiert ja auch nur bei einer ganz bestimmten Aktion in dem jeweiligen Docker.

Ich werde dort nochmal genauer schauen. 

 

Kann ich das ermitteln wenn diese Aktion ausgeführt wird?  Mit df -h sehe ich ja nur das rootfs voll läuft.

Link to comment
38 minutes ago, mgutt said:

Dann zuvor genanntes du Kommando ausführen. Dann siehst du ja die Dateien nach Größe sortiert und damit denke ich auch die problematischen Dateien.

Ok, Problem ist gefunden. 

Der Docker hat mein Laufwerk auf das geschrieben werden soll nicht in der Location gemountet. 

Warum das so ist verstehe ich noch nicht, weil die angaben soweit richtig sind. Ich werde mal den Supporter des Containers fragen.

 

Vielen dank erstmal.

Link to comment
On 5/1/2022 at 9:02 PM, speedycxd said:

Ok, Problem ist gefunden. 

Der Docker hat mein Laufwerk auf das geschrieben werden soll nicht in der Location gemountet. 

Warum das so ist verstehe ich noch nicht, weil die angaben soweit richtig sind. Ich werde mal den Supporter des Containers fragen.

 

Vielen dank erstmal.

 

Normal lässt sich jeder Container einfach einem Ordner zuweisen bzw. spezielle Punkte innerhalb des Containers mounten. Selbst Kritische Pfade könnte man mounten, ob die Daten dann vom Docker geschrieben werden können steht auf einem anderen Blatt.

Du kannst ja prüfen wenn du im jeweiligen Container auf die Console gehst und guckst wo der richtige Pfad des "Ordners" liegt. Vielleicht doch nur vertippt?

 

Link to comment
On 5/5/2022 at 10:38 AM, RiDDiX said:

 

Normal lässt sich jeder Container einfach einem Ordner zuweisen bzw. spezielle Punkte innerhalb des Containers mounten. Selbst Kritische Pfade könnte man mounten, ob die Daten dann vom Docker geschrieben werden können steht auf einem anderen Blatt.

Du kannst ja prüfen wenn du im jeweiligen Container auf die Console gehst und guckst wo der richtige Pfad des "Ordners" liegt. Vielleicht doch nur vertippt?

 

 

Pfad usw waren richtig.

Ich arbeite mit rclone und einer Cloud. Hier war der Fehler das ich in der rclone config mein Laufwerk einfach als Unionfs erstellen musste.

Jetzt erkennt der Docker es auch als Lokales Laufwerk und schreibt nicht mehr in den RAM.



 

 

Link to comment

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Restore formatting

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.