speedycxd Posted April 30, 2022 Share Posted April 30, 2022 (edited) 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 Edited April 30, 2022 by speedycxd Quote Link to comment
jj1987 Posted April 30, 2022 Share Posted April 30, 2022 21 minutes ago, speedycxd said: Oben cache ist mein aktueller cache und user war der alte, der jetzt aber quasi gespiegelt wird. Wie kann ich dieses Problem beheben? Also eigentlich ist "/user" die Summe aus Cache und Array, "/user0" dann nur Array und "/cache" halt Cache Quote Link to comment
speedycxd Posted April 30, 2022 Author Share Posted April 30, 2022 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? Quote Link to comment
jj1987 Posted April 30, 2022 Share Posted April 30, 2022 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. Quote Link to comment
jj1987 Posted April 30, 2022 Share Posted April 30, 2022 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. Quote Link to comment
speedycxd Posted April 30, 2022 Author Share Posted April 30, 2022 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. Quote Link to comment
jj1987 Posted April 30, 2022 Share Posted April 30, 2022 1 hour ago, speedycxd said: Allerdings nur bei bestimmten Dockern. Bei dem meisten besteht da kein Problem. Dann solltest du drauf basierend mal auf die Fehlersuche gehen. Anscheinend ist bei den betroffenen Dockern ja irgendwas abweichendes eingestellt. Quote Link to comment
speedycxd Posted April 30, 2022 Author Share Posted April 30, 2022 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? Quote Link to comment
mgutt Posted April 30, 2022 Share Posted April 30, 2022 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. Quote Link to comment
speedycxd Posted May 1, 2022 Author Share Posted May 1, 2022 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. Quote Link to comment
mgutt Posted May 1, 2022 Share Posted May 1, 2022 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. Quote Link to comment
speedycxd Posted May 1, 2022 Author Share Posted May 1, 2022 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. Quote Link to comment
mgutt Posted May 1, 2022 Share Posted May 1, 2022 4 minutes ago, speedycxd said: Nur am Ende gibt es wirite error. Ja, weil bei 50 Dateien abgeschnitten wird. Ist also kein Fehler. Ist der RAM denn jetzt voll? Quote Link to comment
speedycxd Posted May 1, 2022 Author Share Posted May 1, 2022 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. Quote Link to comment
mgutt Posted May 1, 2022 Share Posted May 1, 2022 5 hours ago, speedycxd said: Kann ich das ermitteln wenn diese Aktion ausgeführt wird? 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. Quote Link to comment
speedycxd Posted May 1, 2022 Author Share Posted May 1, 2022 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. Quote Link to comment
RiDDiX Posted May 5, 2022 Share Posted May 5, 2022 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? Quote Link to comment
speedycxd Posted May 8, 2022 Author Share Posted May 8, 2022 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. Quote Link to comment
Recommended Posts
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.