mgutt Posted August 18, 2021 Share Posted August 18, 2021 Ursachen Wer einen SSD Cache einsetzt, hat evtl schon festgestellt, dass er permanente Schreibzugriffe auf der SSD hat. Es gibt dafür verschiedene Ursachen: Write Amplification Das bedeutet es wird mehr auf das Laufwerk geschrieben als die Daten eigentlich groß sind und das liegt daran, dass der festgelegte Datenblock größer ist als die Daten selbst oder es werden je nach Dateisystem zusätzliche Informationen wie Prüfsummen, Metadaten oder Journaling gespeichert, die eine hohe Amplification resultieren können. Healthcheck Wenn ein Container diese Funktion besitzt, schreibt er alle 5 Sekunden (!) in die Dateien "/var/lib/docker/containers/*/hostconfig.json" und "/var/lib/docker/containers/*/config.v2.json". Diese ermöglicht den "healthy", "unhealthy" oder "health: starting" Status in der Docker Übersicht: Mir bekannte Container, die das nutzen sind zB Plex, Pi-Hole oder der Nginx Proxy Manager. Container Logs Über die Logs eines Containers können wir sehen was er gerade macht. Manche Container schreiben sehr viel in "/var/lib/docker/containers/*/*-json.log". Ich hatte zB schon eine 500MB große Log-Datei bei Plex Interne Logs oder temporäre Dateien Innerhalb eines Containers können ebenfalls Logs oder temporäre Dateien erstellt werden. zb schreibt der Nginx Proxy Manager im Pfad /var/logs ständig in Log-Dateien oder der Unifi-Controller ständig in /tmp temporäre Dateien. Mit dem folgenden "find" Kommando können wir uns alle Dateien ausgeben lassen, die durch Container oder dem Docker Dienst geschrieben werden: find /var/lib/docker -type f -not -path "*/diff*" -print0 | xargs -0 stat --format '%Y:%.19y %n' | sort -nr | cut -d: -f2- 2> /dev/null | head -n30 | sed -e 's|/merged|/...|; s|^[0-9-]* ||' Es listet die 30 zuletzt geänderten Dateien auf. Wiederholt man das Kommando, dann sieht man schnell welche Dateien (teilweise im Sekundentakt) immer wieder aktualisiert werden: 09:36:29 /var/lib/docker/containers/*/hostconfig.json 09:36:29 /var/lib/docker/containers/*/config.v2.json 09:12:45 /var/lib/docker/containers/*/*-json.log 09:12:34 /var/lib/docker/overlay2/*/merged/tmp/*.log 09:12:34 /var/lib/docker/overlay2/*/merged/var/log/*.log ... 09:12:34 /var/lib/docker/btrfs/subvolumes/*/var/log/*.log Gegenmaßnahmen Was können wir nun dagegen tun: Docker vom docker.img auf "Directory" umstellen (ja, "/docker/docker/" ist richtig!): Damit reduzieren wir schon mal die Write Amplification, da das Schreiben einer kleinen Zeile in eine log/json-Datei mehr Datenblöcke im docker.img ändern kann, als das beim direkten Zugriff auf die Datei der Fall ist. Hinweis: Dadurch werden alle Custom Networks und Container gelöscht. Diese können dann einfach (ohne Datenverlust) über Apps > Previous Apps wieder installiert werden (Custom Networks müssen natürlich vorher neu erstellt werden! Geht übrigens auch per Kommandozeile) Bonus: Wer den Share "system" beim Cache auf "Prefer" gestellt hat, der sollte auch gleich den Pfad auf /mnt/<cache-pool-name>/docker/docker ändern. Grund: Die CPU wird bei /mnt/user... mehr belastet. Optional: Ist das erledigt und setzt man nur eine SSD ein, sollte man außerdem über den Wechsel von BTRFS zu XFS nachdenken, da XFS eine deutlich kleinere Write Amplification besitzt. Das ginge so: Alle Shares beim Cache von "Prefer" auf "Yes" stellen, Docker & VM Service auf "No", Mover starten, SSD sichten ob sie wirklich leer ist, SSD umformatieren, alle geänderten Shares beim Cache zurück auf "Prefer", Mover starten, HDD sichten ob sie wirklich leer ist, Docker & VM Service auf "Yes". Wir ändern über die Go-Datei den Unraid Code, so dass automatisch eine RAM-Disk vom Pfad /var/lib/docker/containers erstellt wird, in dem die healthcheck-Dateien liegen. Alternativ: Bei allen Containern mit "healthy" status folgendes einstellen (siehe auch unten) Wir ändern über die Go-Datei den Unraid Code, so dass automatisch eine RAM-Disk vom Pfad /var/lib/docker/containers erstellt wird, in dem die Container Logdateien liegen. Alternativ: Bei allen Containern die Container Logs umlenken: oder deaktivieren: Was wann gebraucht wird, erfahrt ihr hier. Um die Aktivitäten innerhalb der Container ermitteln zu können, müssen wir wissen welcher Container in welchen Pfad schreibt. Das oben genannte "find" Kommando hat zB diesen Pfad ausgegeben: /var/lib/docker/overlay2/b04890a87507090b14875f716067feab13081dea9cf879aade865588f14cee67/merged/tmp/hsperfdata_abc/296 rgendein Container schreibt also in den Ordner "/b04890a875...". Mit diesem Kommando finden wir heraus welcher das ist: csv="CONTAINER;PATHS\n"; for f in /var/lib/docker/image/*/layerdb/mounts/*/mount-id; do subid=$(cat $f); idlong=$(dirname $f | xargs basename); id="$(echo $idlong | cut -c 1-12)"; name=$(docker ps --format "{{.Names}}" -f "id=$id"); [[ -z $name ]] && continue; csv+="\n"$(printf '=%.0s' {1..20})";"$(printf '=%.0s' {1..100})"\n"; [[ -n $name ]] && csv+="$name;" csv+="/var/lib/docker/(btrfs|overlay2).../$subid\n"; csv+="$id;"; csv+="/var/lib/docker/containers/$idlong\n"; for vol in $(docker inspect -f '{{ range .Mounts }}{{ if eq .Type "volume" }}{{ .Destination }}{{ printf ";" }}{{ .Source }}{{ end }}{{ end }}' $id); do csv+="$vol\n"; done; done; echo ""; echo -e $csv | column -t -s';'; echo ""; In meinem Fall ist das der "unifi-controller": Außerdem prüfen wir genau in welchen Unterordner der Container geschrieben hat: /merged/tmp/hsperfdata_abc/296 Das "/merged" (oder auch "/diff") kann man ignorieren. Der Pfad des Containers beginnt also mit "/tmp". Diesen Pfad können wir normalerweise bedenkenlos in eine RAM-Disk packen, da bei Debian, Ubuntu und Unraid das bereits von Haus aus eine RAM-Disk ist und Anwendungen in der Regel ja auch auf diesen Betriebssystemen laufen. Aber Achtung: Falls ihr einen anderen Pfad ermittelt habt, darf dieser in der Regel nicht in eine RAM-Disk verlagert werden, da dass zum Datenverlust im Container führen kann! Wir öffnen nun also die Einstellungen des ermittelten Containers, scrollen nach unten und wählen "Add another Path...": Nun tragen wir "/tmp" beim "Container Path" ein und "/tmp/<containername>" beim "Host Path": Sobald ihr nun den Container startet, schreibt der Container nicht mehr in "/var/lib/docker/.../tmp", also auf eure SSD, sondern in "/tmp/unifi-controller" und damit in die RAM-Disk von Unraid. Nachdem das getan ist, wiederholen wir das "find" Kommando erneut und vergleichen noch mal die Ergebnisse: 2021-08-18 10:06:36.256939658 +0200 /var/lib/docker/containers/*/hostconfig.json 2021-08-18 10:06:36.256939658 +0200 /var/lib/docker/containers/*/config.v2.json 2021-08-18 09:49:32.698781862 +0200 /var/lib/docker/containers/*/*-json.log Die Schreibzugriffe auf die "/tmp" Ordner sind nun alle verschwunden, da wir diese in die RAM-Disk von Unraid ausgelagert haben. Die Schreibzugriffe auf /var/lib/docker/containers sehen wir zwar noch (außer ihr verwendet die --no-healthcheck/--log-driver Lösung, dann werden auch diese verschwunden sein), können diese aber ignorieren, da wir dafür über die Code-Änderung eine RAM-Disk ergänzt haben. Zur Belohnung genießen wir dann mal keine Schreibzugriffe auf unserem Cache 😁 Pedanterie Eventuell stellt ihr fest, dass trotzdem noch Daten auf die SSD geschrieben werden und nun wollt ihr es genau wissen. In diesem Fall lohnt es sich das "find" Kommando so anzupassen, dass ihr euch die neuesten Dateien in einem "appdata" Share anzeigen lasst: find /mnt/cache/appdata -type f -print0 | xargs -0 stat --format '%Y :%y %n' | sort -nr | cut -d: -f2- | head -n30 In meinem Fall kam das dabei heraus und ich habe auch gleich mal eingekreist, was man optimieren könnte (auf eigene Gefahr, versteht sich): Da der Nginx-Proxy-Manager bereits eine RAM-Disk für /tmp benötigte, habe ich dann entschieden auch /data/logs in eine RAM-Disk zu packen, so dass ich es schlussendlich so gelöst habe: Den Pfad vom Unifi-Controller habe ich gelassen, da der letzte Schreibzugriff bereits vor mehreren Minuten erfolgte, so dass ich keinen Verschleiß der SSD befürchte. Ich habe dann ein paar Minuten gewartet und das Kommando wiederholt und tatsächlich ist mir dann noch was aufgefallen: 1.) Der Zerotier Container schreibt alle 30 Sekunden in eine conf-Datei, was mich nervt, aber nachdem ich die Datei versucht habe zu öffnen und nur Binärdaten darin enthalten sind, lasse ich davon erstmal die Finger. 2.) Der Unifi-Controller schreibt ständig in haufenweise Datenbank-Dateien. Diese sind natürlich für den Betrieb des Containers notwendig, weshalb wir daran nichts ändern können. Da mich aber die Statistiken von Unifi eh nicht interessieren, lasse ich den Container wie gehabt abgeschaltet. Ich aktiviere den nur, wenn ich etwas an den Access-Points ändern möchte. Alternativ könnte man überlegen ein Script zu schreiben, dass /mnt/cache/appdata/unifi-controller in eine RAM-Disk packt und regelmäßig den Container stoppt, die RAM-Disk sichert und dann wieder startet. Den Aufwand spare ich mir aber. 3.) Der Plex-Container schreibt alle paar Minuten in eine Log-Datei, was ich aber akzeptabel finde. 4 7 Quote Link to comment
sonic6 Posted August 18, 2021 Share Posted August 18, 2021 (edited) Erstmal Danke, ich beobachte das Thema schon seit es im Reddit aufgetaucht ist. Gibt es auch eine Kehrseite der Medaille? Was ist mit nem Crash oder sonstigem unvorhersehbarem verhalten? Ist absehbar ob eine dauerhafte Lösung in Unraid implementiert wird? Edited August 18, 2021 by sonic6 Quote Link to comment
mgutt Posted August 18, 2021 Author Share Posted August 18, 2021 18 hours ago, sonic6 said: Gibt es auch eine Kehrseite der Medaille? Dazu einfach mal schauen was in dem Ordner enthalten ist: Erstmal für jeden Container ein Ordner: Wenn ich die drei Ordner im laufenden Betrieb lösche, dann ist der Tab "docker" in Unraid leer. Ich kann aber über Apps > Previous Apps die Container ganz normal wieder ohne Datenverlust starten und die Ordner werden neu erstellt. Die Ordner werden übrigens auch gelöscht und neu erstellt, wenn man einen Container bearbeitet. Ich habe das gerade mal mit Nginx gemacht: Parallel dazu habe ich ganz oft den Ordner in neuen Tabs geladen: Vorher: Nach dem "Removing": Und sobald der Container wieder erstellt wurde gibt es einen neuen Ordner "30b0...": Im Ordner "30b0... " sind nun auch alle Dateien neu, was man am Datum erkennt: Fazit: Der Inhalt des Ordners ist unwichtig. Aber: Wenn man den Docker Service startet, dann einen Container hinzufügt und der Server abstürzt, dann ist dieser hinzugefügte Container nach einem Neustart erstmal weg. Er kann aber problemlos und ohne Datenverlust über Apps > Previous Apps wieder installiert werden. Update: Passiert nicht mehr. 1 Quote Link to comment
mgutt Posted August 19, 2021 Author Share Posted August 19, 2021 @sonic6 Ich habe nun auch ein automatisches Backup integriert, so dass das hier nicht mehr passiert: 17 hours ago, mgutt said: Wenn man den Docker Service startet, dann einen Container hinzufügt und der Server abstürzt, dann ist dieser hinzugefügte Container nach einem Neustart erstmal weg. Das einzige was jetzt noch bei einem Serverabsturz verloren gehen kann sind Container Log Einträge, die nach dem letzten automatisch Backup dazu gekommen sind. Das kann man aber denke ich verschmerzen. 1 Quote Link to comment
gilladur Posted August 20, 2021 Share Posted August 20, 2021 (edited) On 8/18/2021 at 10:15 AM, mgutt said: Docker vom docker.img auf "Directory" umstellen: Damit reduzieren wir schon mal die Write Amplification, da nicht immer das docker.img aktualisert werden muss, wenn etwas in eine kleine log/json-Datei geschrieben wird. Hinweis: Falls keine Container mehr da sind, einfach über Apps > Previous Apps wieder installieren Leider hat dieser Schritt alle meine Docker mit Swag reverse proxy und dem Docker Netzwerk proxynet nicht mehr erreichbar gemacht 😐 Ich komme auch nicht direkt über die IP auf die WebGUIs. Das Proxynet habe ich hiermit "docker network create proxynet" wieder erstellt aber trotzdem gehen Nextcloud, Vaultwarden, OnlyOffice nicht mehr. Hat einer eine Idee, woran das liegen könnte? Swag gibt auch plötzlich folgende Fehlermeldung im Log aus: nginx: [emerg] host not found in upstream "vaultwarden:80" in /config/nginx/proxy-confs/vaultwarden.subdomain.conf:9 Edited August 20, 2021 by gilladur Quote Link to comment
mgutt Posted August 20, 2021 Author Share Posted August 20, 2021 21 minutes ago, gilladur said: Das Proxynet habe ich hiermit "docker network create proxynet" wieder erstellt Warum war das überhaupt weg? Hast du nicht eingestellt, dass Custom Network erhalten bleiben sollen (Docker Settings)? 22 minutes ago, gilladur said: Ich komme auch nicht direkt über die IP auf die WebGUIs Das ist ein bisschen wenig Input. Welche IP nutzt du denn um auf die GUI zu kommen, die aus dem proxynet? Dann wäre es ja logisch, dass du da nicht draufkommst, weil du ja nicht im proxynet bist, sondern im Netz von deinem Unraid-Server oder verstehe ich da jetzt was falsch? Vielleicht mal Screenshots posten! Einfachste Methode ist auch die jeweilige Container Console zu öffnen und mit "ping <ip-des-anderen-containers" oder "curl <ip-des-anderen-containers" den Zugriff untereinander zu testen. 23 minutes ago, gilladur said: host not found in upstream "vaultwarden:80" Klingt so als könnte nginx den hostnamen "vaultwarden" nicht auflösen, also dessen IP kommt nicht vom Docker DHCP zurück. Hattest du das proxynet vorher erstellt oder während die Container bereits liefen? Das muss vorher stehen. Ich habe das ganze übrigens aufgegeben. Nur Stress damit gehabt. Ich mache es jetzt so: https://forums.unraid.net/topic/110245-support-nginx-proxy-manager-npm-official/?tab=comments#comment-1011152 Also Unraid auf 5000 und 5001 umgestellt, der Proxy lauscht als Host auf 80 und 443 und alle anderen Container laufen als Bridge. Keiner läuft mehr als br0 oder in custom networks. Seitdem habe ich Ruhe und sogar IPv6 geht störungsfrei. 1 Quote Link to comment
gilladur Posted August 20, 2021 Share Posted August 20, 2021 1 hour ago, mgutt said: Warum war das überhaupt weg? Hast du nicht eingestellt, dass Custom Network erhalten bleiben sollen (Docker Settings)? Doch, das hatte ich nicht geändert - verstehe ich auch nicht. Aber.... 1 hour ago, mgutt said: Hattest du das proxynet vorher erstellt oder während die Container bereits liefen? Das muss vorher stehen. Schande über mich - genau das war es. Bin wohl doch zu müde gewesen. Ich habe nun alles noch mal auf Image zurück gestellt und dann wieder auf Directory und dieses mal aber dann zuerst das Docker Netzwerk proxynet erstellt - das war es 🙂 1 hour ago, mgutt said: Welche IP nutzt du denn um auf die GUI zu kommen, die aus dem proxynet? Nur zur Vervollständigung - ich meine die WebUI - also nicht meine Subdomain - da war ich schon verwundert, dass ich da local nicht drauf zugreifen konnte. Aber läuft ja jetzt wieder - Puh Vielen lieben Dank für die ausführliche Antwort - zuerst dachte ich das ich wieder mit meinem Halbwissen mir die halbe Nacht mit dem Problem beschäftigen muss. Deine Anleitung kann ich mir jetzt in Ruhe einmal anschauen 🙂 Wenn ich nämlich Probleme mit Unraid / Swag dann steht man schnell auf dem Schlauch und ist froh, wenn man es am ende irgendwie wieder ans laufen bekommen hat... Cheers Gilladur Quote Link to comment
sonic6 Posted August 21, 2021 Share Posted August 21, 2021 (edited) 14 hours ago, mgutt said: 15 hours ago, gilladur said: Das Proxynet habe ich hiermit "docker network create proxynet" wieder erstellt Warum war das überhaupt weg? Hast du nicht eingestellt, dass Custom Network erhalten bleiben sollen (Docker Settings)? Das liegt daran, dass die Docker Network Setting im Docker Image unter /docker/container/network/files/local-kv.db liegen. Wenn man die "local-kv.db" vorher aus dem laufenden Docker Image sichert und später im Docker Path wieder herstellt, sind die Customnetworks wieder vorhanden. - Docker mit Docker Image starten - local-kv.db sichern - Docker auf Docker Path starten und warten, dass alle Container gestartet sind - Docker Dienst stoppen - local-kv.db mit dem Backup ersetzten - Docker Dienst starten - ... - sich darüber freuen, dass alles ist wie vorher *edit* Die Lösung einfach "wieder" das Proxynet zu erstellen ist nur Semi gut. Beim ersten mal wenn das Proxynet erstellt wird und man kein Subnet angibt, wird 172.17.0.0 erstellt. Wenn man nur einfach wieder eines erstellt, wird 172.18.0.0 erstellt, selbst wenn das Proxynet "verschwunden" ist. Und so weiter... das hat bei mir alles durcheinander geworfen, als ich auf Docker Path umgestellt habe, da ich überall, wo nicht mit der Namesauflösung gearbeitet wurde, die IPs anpassen musste. Nicht zu vergessen einige Zeilen in der config von NC. In Summe ist da schnell mal was vergessen. Das ganze habe ich umgangen, in dem ich mir einfach meine alten Netzwerksetting aus dem Docker Image gesichert habe. Edited August 21, 2021 by sonic6 Quote Link to comment
mgutt Posted August 21, 2021 Author Share Posted August 21, 2021 7 hours ago, sonic6 said: Das liegt daran, dass die Docker Network Setting im Docker Image unter /docker/container/network/files/local-kv.db liegen Wenn man aber auf Pfad umstellt, wird ja das docker.img doch 1:1 in den Pfad entpackt?! EDIT: Ist leider nicht so. Quote Link to comment
sonic6 Posted August 21, 2021 Share Posted August 21, 2021 9 minutes ago, mgutt said: Wenn man aber auf Pfad umstellt, wird ja das docker.img doch 1:1 in den Pfad entpackt?! Bei mir war es damals nicht so, da wurde das "Docker Image" als Pfad neu erstellt. Wenn ich mich recht erinnere musste ich auch die Container "neu laden". Ich erinnere mich nicht mehr 100%tig, war aber glaube ich in der 6.9.2 Beta? Quote Link to comment
gilladur Posted August 21, 2021 Share Posted August 21, 2021 (edited) 1 hour ago, sonic6 said: Und so weiter... das hat bei mir alles durcheinander geworfen, als ich auf Docker Path umgestellt habe, da ich überall, wo nicht mit der Namesauflösung gearbeitet wurde, die IPs anpassen musste. Nicht zu vergessen einige Zeilen in der config von NC Hallo Sonic, danke für die Erklärung . Auf den ersten Blick musste ich nichts anpassen, nachdem ich das Proxynet vor dem nachinstallieren der Docker erstellt habe - alles läuft soweit auf Anhieb. Kann aber sein, dass ich noch nicht alles getestet habe. Gibt es eine Möglichkeit die local-kv.db aus dem alten Docker Image zu extrahieren? Das Image ist immer noch auf dem Server vorhanden. Wenn ich diese aber herunterlade, kann ich die weder entpacken noch einbinden. Edit: sehe gerade das mgutt ja eigentlich schon auf meine Frage geantwortet hat: 33 minutes ago, mgutt said: Wenn man aber auf Pfad umstellt, wird ja das docker.img doch 1:1 in den Pfad entpackt?! Edited August 21, 2021 by gilladur Quote Link to comment
sonic6 Posted August 21, 2021 Share Posted August 21, 2021 1 minute ago, gilladur said: Hallo Sonic, danke für die Erklärung . Auf den ersten Blick musste ich nichts anpassen, nachdem ich das Proxynet vor dem nachinstallieren der Docker erstellt habe - alles läuft soweit auf Anhieb. Kann aber sein, dass ich noch nicht alles getestet habe. Gibt es eine Möglichkeit die local-kv.db aus dem alten Docker Image zu extrahieren? Das Image ist immer noch auf dem Server vorhanden. Wenn ich diese aber herunterlade, kann ich die weder entpacken noch einbinden. Meine Holzhammer-Methode wäre, einfach wieder auf Docker Image umzustellen, dann rauszukopieren, wieder auf Docker Path zurück und ersetzten. So wie ich es oben beschrieben habe. Aber es gibt sicherlich eine elegantere Methode. Ich für meine Teil sichere mich die local-kv.db monatlich. 3 minutes ago, gilladur said: Auf den ersten Blick musste ich nichts anpassen, nachdem ich das Proxynet vor dem nachinstallieren der Docker erstellt habe - alles läuft soweit auf Anhieb. Kann aber sein, dass ich noch nicht alles getestet habe. Wie siehts hiermit aus? (nextcloud config.php) Oder configs aus SWAG für den RP? Ich hatte tatsächlich hier und dort mal mit IPs, statt Namensauflösung gearbeitet. (Was sich im nachhinein als nicht sehr schlau darstellte, da sich die IPs im Dockernetz ja anhand der Startreihenfolge ändern können.) Aber das war von meiner Seite aus genug Off-Topic und würde in nen eigenen Thread gehören. Quote Link to comment
mgutt Posted August 21, 2021 Author Share Posted August 21, 2021 23 minutes ago, gilladur said: vor dem nachinstallieren der Docker erstellt habe Musstest du die Container nachinstallieren oder waren sie nach dem Wechsel auf Pfad noch da? Quote Link to comment
mgutt Posted August 21, 2021 Author Share Posted August 21, 2021 On 8/18/2021 at 10:15 AM, mgutt said: Bonus: Wer den Share "system" beim Cache auf "Prefer" gestellt hat, der sollte auch gleich den Pfad auf /mnt/<name-des-cache-pools>/docker/docker ändern. Grund: Die CPU wird bei /mnt/user... mehr belastet. Das habe ich noch in der Anleitung ergänzt. Quote Link to comment
mgutt Posted August 21, 2021 Author Share Posted August 21, 2021 On 8/18/2021 at 10:15 AM, mgutt said: Hinweis: Dadurch werden alle Custom Networks und Container gelöscht. Diese können dann einfach über Apps > Previous Apps wieder installiert werden (Custom Networks müssen natürlich vorher neu erstellt werden!) Den Satz habe ich umformuliert. Ich habe das gerade getestet. Ich dachte das docker.img wird entpackt. Das ist aber nicht der Fall. Es ist so als würde man das docker.img löschen, was ja nicht weiter tragisch ist, aber gerade das mit den Custom Networks ist natürlich wichtig zu erwähnen. 1 hour ago, sonic6 said: Meine Holzhammer-Methode wäre, einfach wieder auf Docker Image umzustellen, dann rauszukopieren Hier die "elegante" Lösung um Custom Networks wiederherzustellen: mkdir /mnt/user/system/docker_bind mount /mnt/user/system/docker/docker.img /mnt/user/system/docker_bind cp -a /mnt/user/system/docker_bind/network/files/local-kv.db /mnt/user/system/docker/docker/network/files/local-kv.db umount /mnt/user/system/docker_bind rmdir /mnt/user/system/docker_bind Also: Docker auf Pfad umstellen Per "Yes" starten Dann die oben genannten Kommandos über das WebTerminal ausführen Und als letztes über Apps > Previous Apps die Container wieder installieren 1 1 Quote Link to comment
gilladur Posted August 21, 2021 Share Posted August 21, 2021 47 minutes ago, mgutt said: Musstest du die Container nachinstallieren oder waren sie nach dem Wechsel auf Pfad noch da? die Container waren weg und ich musste sie nachinstallieren Quote Link to comment
sonic6 Posted August 21, 2021 Share Posted August 21, 2021 (edited) 9 hours ago, mgutt said: On 8/18/2021 at 10:15 AM, mgutt said: Bonus: Wer den Share "system" beim Cache auf "Prefer" gestellt hat, der sollte auch gleich den Pfad auf /mnt/<name-des-cache-pools>/docker/docker ändern. Grund: Die CPU wird bei /mnt/user... mehr belastet. Das habe ich noch in der Anleitung ergänzt. Wird "Prefer" (also bei "Überlauf aufs Array schreiben") überhaupt noch funktionieren, wenn ich in /mnt/cache/... schreibe? Dachte "Prefer" wird nur angewand, wenn in /mnt/user/... geschrieben wird. Edited August 21, 2021 by sonic6 Quote Link to comment
mgutt Posted August 21, 2021 Author Share Posted August 21, 2021 2 hours ago, sonic6 said: Wird "Prefer" (also bei "Überlauf aufs Array schreiben") überhaupt noch funktionieren, wenn ich in /mnt/cache/... schreibe? Nein, das funktioniert dann nicht mehr. Das selbe gilt natürlich auch für /mnt/cache/appdata, womit man die CPU ja ebenfalls entlastet. Damit nun andere Shares, die auf den selben Cache Pool schreiben können, diese nicht vollschreiben und damit den Betrieb von Docker gefährden, sollte man beim Cache Pool einen Minimum free space definieren: Dieser Wert gilt nur bei /mnt/user, während man mit /mnt/cache weiterschreiben kann. So hat /mnt/cache/system/docker und /mnt/cache/appdata noch genug Platz bis der Mover die SSD eh wieder leert. Ich habe übrigens 100GB eingestellt, da ich beim parallelen Rippen von mehreren Blu-Rays manchmal 70 bis 90GB "nachschreibe". Blu-Ray Rips sind bekanntlich große MKV Dateien und wie groß die schlussendlich werden, kann Unraid natürlich nicht wissen und die Minimum Free Space Regel greift immer nur beim Erstellen der Datei. Soll heißen wenn von 1000GB gerade 899GB belegt sind, könnte ich theoretisch einen 500GB großen Rip hochladen und er würde, obwohl er nicht auf die SSD passt, auf dieser erstellt werden (und dann im Fehler enden). Erst wenn 900GB belegt sind, werden neue Dateien direkt auf dem Array erstellt. Quote Link to comment
mgutt Posted August 22, 2021 Author Share Posted August 22, 2021 Ebenfalls im Guide ergänzt: Wer weiter auf BTRFS setzt, der hat evtl das Problem, dass er die Zugriffe auf /var/lib/docker/btrfs/subvolumes keinem Container zuordnen kann. Dann diesen Befehl ausführen: for f in /var/lib/docker/image/btrfs/layerdb/mounts/*/mount-id; do echo $(dirname $f | xargs basename | cut -c 1-12)' (Container-ID) > '$(cat $f)' (BTRFS subvolume ID)'; done && docker ps -a Quote Link to comment
gilladur Posted August 25, 2021 Share Posted August 25, 2021 Hallo zusammen, ich hätte noch eine Frage und zwar ob diese Einträge irgendwie verhindert werden können: 2021-08-25 23:27:34.262584981 +0200 /var/lib/docker/overlay2/*/merged/tmp/sess_* 2021-08-25 23:27:34.262584981 +0200 /var/lib/docker/overlay2/*/diff/tmp/sess_* 2021-08-25 23:27:33.419584610 +0200 /var/lib/docker/overlay2/*/merged/tmp/sess_* 2021-08-25 23:27:33.419584610 +0200 /var/lib/docker/overlay2/*/diff/tmp/sess_* 2021-08-25 23:27:30.209582126 +0200 /var/lib/docker/overlay2/*/merged/tmp/hsperfdata_abc/292 2021-08-25 23:27:30.209582126 +0200 /var/lib/docker/overlay2/*/diff/tmp/hsperfdata_abc/292 2021-08-25 23:27:30.139582068 +0200 /var/lib/docker/overlay2/*/merged/run/postgresql/10-main.pg_stat_tmp/global.stat Bei mir scheinen die noch immer alle paar Sekunden auf die SSD zu schreiben. So richtig verstehe ich auch die Funktion dieser Schreibvorgänge nicht. Quote Link to comment
mgutt Posted August 25, 2021 Author Share Posted August 25, 2021 13 minutes ago, gilladur said: ob diese Einträge irgendwie verhindert Ja das ist das was im Guide unter 5.) beschrieben ist. Du musst den Container ermitteln und bei diesem dann einen neuen Path hinzufügen Container: /tmp und Host: /tmp/containername. Dadurch schreibt der Container nicht mehr auf das /tmp Verzeichnis was auf der SSD liegt, sondern das was im RAM liegt. Nenn gerne die Container, wenn du sie gefunden hast. Dann melden wir das an den Maintainer, dass er das direkt ins Template übernimmt. Quote Link to comment
gilladur Posted August 26, 2021 Share Posted August 26, 2021 11 hours ago, mgutt said: Path hinzufügen Container: /tmp und Host: /tmp/containername Heißt der neue Pfad nun in meinem Fall /tmp oder wie in deinem Beispiel oben /var/log? Wenn ich das richtig verstehe, muss ich das aus der Find-Ausgabe her ableiten und müsste das dann nach meinem logs oben nicht zwei Verzeichnisse sein? /merged/tmp/ und /diff/tmp/ In deiner Beschreibung oben hast du zwei Fälle in der find Ausgabe: 09:12:34 /var/lib/docker/overlay2/*/merged/var/log/*.log ... 09:12:34 /var/lib/docker/btrfs/subvolumes/*/var/log/*.log Deswegen bin ich da etwas verwirrt + viel Unwissen 🙂 Quote Link to comment
mgutt Posted August 26, 2021 Author Share Posted August 26, 2021 1 hour ago, gilladur said: Heißt der neue Pfad nun in meinem Fall /tmp oder wie in deinem Beispiel oben /var/log? Er heißt "/tmp" wie in der Ausgabe des "find"-Kommandos zu sehen. Ich habe die Anleitung übrigens in großen Teilen umformuliert und mehr Screenshots / Erklärungen ergänzt. Es sollte jetzt denke ich besser zu verstehen sein. Lies insbesondere bei Gegenmaßnahmen noch mal Punkt 4. 1 hour ago, gilladur said: müsste das dann nach meinem logs oben nicht zwei Verzeichnisse sein? /merged/tmp/ und /diff/tmp/ Auch das steht jetzt in der Anleitung. merged und diff gehören nicht zum Container, sondern zum Docker-Dienst und diese muss man sich daher wegdenken. Alles was nach "merged/" steht, ist die Root-Ebene des Containers. Vergleiche: 1 Quote Link to comment
T0a Posted August 26, 2021 Share Posted August 26, 2021 (edited) On 8/22/2021 at 11:55 AM, mgutt said: Ebenfalls im Guide ergänzt: Wer weiter auf BTRFS setzt, der hat evtl das Problem, dass er die Zugriffe auf /var/lib/docker/btrfs/subvolumes keinem Container zuordnen kann. Dann diesen Befehl ausführen: for f in /var/lib/docker/image/btrfs/layerdb/mounts/*/mount-id; do echo $(dirname $f | xargs basename | cut -c 1-12)' (Container-ID) > '$(cat $f)' (BTRFS subvolume ID)'; done && docker ps -a Hi @mgutt, vielen Dank fuer deine detaillierte Analyse und Schritte zur Senkung der Schreibvorgaenge. Leider habe ich ein paar Container, welche ich mit deinen Befehlen nicht identifizieren kann. In dem angefuegten Beispiel finde ich nur einen Container. Ich verwende BTRFS. $ find /var/lib/docker -type f -print0 | xargs -0 stat --format '%Y :%y %n' | sort -nr | cut -d: -f2- | head -n30 2021-08-26 14:22:10.173941747 +0200 /var/lib/docker/containers/b08e6e2d18fbb8ac7743f05c9587936cf216d07c02fb077bf36ec6ec666ddfa4/b08e6e2d18fbb8ac7743f05c9587936cf216d07c02fb077bf36ec6ec666ddfa4-json.log 2021-08-26 14:22:10.075941360 +0200 /var/lib/docker/volumes/11ad4a2d8c58a5baf36528dafe15c4d71b3b47db02676219ec4a35c4247131fc/_data/dump.rdb 2021-08-26 14:20:43.434600397 +0200 /var/lib/docker/containers/3a619f64c1353174cecf913582ffb3360a3d972521640c39d17e924f99e88d62/3a619f64c1353174cecf913582ffb3360a3d972521640c39d17e924f99e88d62-json.log 2021-08-26 14:05:40.423066270 +0200 /var/lib/docker/containers/1de8d6e23f5a1cb3c1cfe497156c557deb3c1b187d7916ab71eb2116885cd685/1de8d6e23f5a1cb3c1cfe497156c557deb3c1b187d7916ab71eb2116885cd685-json.log 2021-08-26 14:05:39.344062070 +0200 /var/lib/docker/btrfs/subvolumes/2c44fb572165fdf52a19fc518924de003750fcdbfc4074505a14cb8997477f1b/run/tomcat/tomcat9.pid 2021-08-26 14:05:31.841032871 +0200 /var/lib/docker/containerd/daemon/io.containerd.metadata.v1.bolt/meta.db 2021-08-26 14:05:31.786032657 +0200 /var/lib/docker/btrfs/subvolumes/2c44fb572165fdf52a19fc518924de003750fcdbfc4074505a14cb8997477f1b/etc/mysql/my.cnf $ csv="CONTAINER ID;NAME;SUBVOLUME\n"; for f in /var/lib/docker/image/*/layerdb/mounts/*/mount-id; do sub=$(cat $f); id=$(dirname $f | xargs basename | cut -c 1-12); csv+="$id;" csv+=$(docker ps --format "{{.Names}}" -f "id=$id")";" csv+="/var/lib/docker/.../$sub\n"; done; echo -e $csv | column -t -s';' CONTAINER ID NAME SUBVOLUME 0837668ab9aa ha-dockermon /var/lib/docker/.../c453891a316ec4eb019e3f422822522ab02eab5206d8057fb683148f9f9ee73e 1de8d6e23f5a ApacheGuacamole /var/lib/docker/.../2c44fb572165fdf52a19fc518924de003750fcdbfc4074505a14cb8997477f1b 327b99639003 mediabox-webdav /var/lib/docker/.../060bacaf2b0a5ba9da609170d23f3aa784c740013a868a7144109b5074679e8d 3332bcd89455 /var/lib/docker/.../9b2cfb3fa23e8f6e223b3e706663fcbbeebf84b8597d706c8ce23f643fc42274 3a619f64c135 paperless-ng /var/lib/docker/.../1c3de7a697750b83951615239d40a196fdfe8a3c1f14dd987ee39b28a72ee6f3 658a3cdbc4ec pyload /var/lib/docker/.../9ee162566420a1490a21a1365665b9d72bd0282f89a384950867d0142cee4cb1 85d30bcb7ebc PhotoPrism /var/lib/docker/.../afe5ba079e28dafb855219569836437f013add1ea5f4ae77972c78ac72d42c04 a486d6c7fd29 syncthing /var/lib/docker/.../42ec5e12317b47750f9c6776952678028b20416bbe868f5e152deb10bc239b56 abfd165b7c2d cyberchef /var/lib/docker/.../8437459cd2b973a976954aaa87bbe82be907bf48c106cafb2b3ea540cc460b6f b08e6e2d18fb Redis /var/lib/docker/.../230a683c4c170076532d72dd3c44fe5864ffafc3b354c3936831f86d239ca22c b6d9783d0efa borgmatic /var/lib/docker/.../00348b7c4c31d7a8c62c1d3f887db40be599d7bce20a121afd9a07c532d6c98d c0e15cf5cfee /var/lib/docker/.../202335a2b00810c0292518af7cf2985341e3953e6c5cbc86f206a8bff52a9c70 e6027b587016 /var/lib/docker/.../65e4ae75354b4593e84f8555444e9168420984d11d76365ee1ad06b6dcc4acfb $ for f in /var/lib/docker/image/btrfs/layerdb/mounts/*/mount-id; do echo $(dirname $f | xargs basename | cut -c 1-12)' (Container-ID) > '$(cat $f)' (BTRFS subvolume ID)'; done 0837668ab9aa (Container-ID) > c453891a316ec4eb019e3f422822522ab02eab5206d8057fb683148f9f9ee73e (BTRFS subvolume ID) 1de8d6e23f5a (Container-ID) > 2c44fb572165fdf52a19fc518924de003750fcdbfc4074505a14cb8997477f1b (BTRFS subvolume ID) 327b99639003 (Container-ID) > 060bacaf2b0a5ba9da609170d23f3aa784c740013a868a7144109b5074679e8d (BTRFS subvolume ID) 3332bcd89455 (Container-ID) > 9b2cfb3fa23e8f6e223b3e706663fcbbeebf84b8597d706c8ce23f643fc42274 (BTRFS subvolume ID) 3a619f64c135 (Container-ID) > 1c3de7a697750b83951615239d40a196fdfe8a3c1f14dd987ee39b28a72ee6f3 (BTRFS subvolume ID) 658a3cdbc4ec (Container-ID) > 9ee162566420a1490a21a1365665b9d72bd0282f89a384950867d0142cee4cb1 (BTRFS subvolume ID) 85d30bcb7ebc (Container-ID) > afe5ba079e28dafb855219569836437f013add1ea5f4ae77972c78ac72d42c04 (BTRFS subvolume ID) a486d6c7fd29 (Container-ID) > 42ec5e12317b47750f9c6776952678028b20416bbe868f5e152deb10bc239b56 (BTRFS subvolume ID) abfd165b7c2d (Container-ID) > 8437459cd2b973a976954aaa87bbe82be907bf48c106cafb2b3ea540cc460b6f (BTRFS subvolume ID) b08e6e2d18fb (Container-ID) > 230a683c4c170076532d72dd3c44fe5864ffafc3b354c3936831f86d239ca22c (BTRFS subvolume ID) b6d9783d0efa (Container-ID) > 00348b7c4c31d7a8c62c1d3f887db40be599d7bce20a121afd9a07c532d6c98d (BTRFS subvolume ID) c0e15cf5cfee (Container-ID) > 202335a2b00810c0292518af7cf2985341e3953e6c5cbc86f206a8bff52a9c70 (BTRFS subvolume ID) e6027b587016 (Container-ID) > 65e4ae75354b4593e84f8555444e9168420984d11d76365ee1ad06b6dcc4acfb (BTRFS subvolume ID) PS: Kann es sein, dass du vergessen hast den Befehl fuer BTRFS im Guide zu ergaenzen? Edited August 26, 2021 by T0a Quote Link to comment
mgutt Posted August 26, 2021 Author Share Posted August 26, 2021 3 hours ago, T0a said: PS: Kann es sein, dass du vergessen hast den Befehl fuer BTRFS im Guide zu ergaenzen? Nein, der Befehl ist nun universell. 3 hours ago, T0a said: Leider habe ich ein paar Container, welche ich mit deinen Befehlen nicht identifizieren kann Zwei finde ich nicht (eingerahmt), aber den Rest schon: Wann wird denn "volumes" erstellt? Hast du einen Container, der bei den Pfaden ein "Volume" einbindet? Und das mit dem Daemon weiß ich auch nicht. Ist das evtl ein Gerät? Du könntest so nach Dateien suchen, die "11ad4a..." enthalten: grep -rnw '/var/lib/docker' -e '11ad4a2d8c58a' Sag bescheid was du findest, dann kann ich das evtl in den Befehl integrieren. 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.