SSD Abnutzung maßgeblich reduzieren


Recommended Posts

Ursachen

 

Wer einen SSD Cache einsetzt, hat evtl schon festgestellt, dass er permanente Schreibzugriffe auf der SSD hat. Es gibt dafür verschiedene Ursachen:

  1. 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.
  2. 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:
    image.png.b007eb443daff818c8377d87f26bffac.png image.png.53f5dc8ba03fc7bcd092875becb56184.png
    Mir bekannte Container, die das nutzen sind zB Plex, Pi-Hole oder der Nginx Proxy Manager.
  3. 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
    1435604714_2021-08-1809_56_05.png.403d8e794ca15b9171a13e5a4884c56e.png
  4. 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:

  1. Docker vom docker.img auf "Directory" umstellen (ja, "/docker/docker/" ist richtig!):
    image.png.f1e9edbfe3bb537d0799625edffdda4e.png
    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".
  2. 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)
    image.png.598f31b8afc93baf7ce8e4d8fbecb71d.png
  3. 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:
    image.png.b0154a798d1420548d440fba3dd84781.png
    oder deaktivieren:
    image.png.7fc22aeb238d3e5f4cd5126fce5d2a97.png
    Was wann gebraucht wird, erfahrt ihr hier.
  4. 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":
    1527726087_2021-08-2812_28_03.png.bbb6c9ea90e0ae562487b34c2a919b4d.png
    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...":
    image.png.422472c0ba5697afcf76a64ca1c84509.png
    Nun tragen wir "/tmp" beim "Container Path" ein und "/tmp/<containername>" beim "Host Path":
    image.png.c99e428dc1efce80a3aa6ef3afd3c883.png
    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 😁

image.png.7d39ee2e497f8d703910bffc4d702509.png

 

 

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):

1790051756_2021-08-2611_43_22.png.c51285432496ef4777e544964c072495.png

 

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:

image.png.8735ddcf72a8ed734a52d0af774ac4de.png

 

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:

359952556_2021-08-2612_03_29.thumb.png.f448a030caf44a26c822abdc8d7484d9.png

 

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.

 

 

  • Like 3
  • Thanks 4
Link to comment

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 by sonic6
Link to comment
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:

image.png.d13c8ea9d91573199bc451f65ecf803f.png

 

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:

1766593443_2021-08-1817_35_24.png.6e1aa9d28d47806b5bbbdfd70a36da2f.png

 

Parallel dazu habe ich ganz oft den Ordner in neuen Tabs geladen:

 

Vorher:

image.png.d13c8ea9d91573199bc451f65ecf803f.png

 

Nach dem "Removing":

image.png.ff509e47aca6076d2d43218abcf2beb5.png

 

Und sobald der Container wieder erstellt wurde gibt es einen neuen Ordner "30b0...":

image.png.212e9cf7bade136f733bd082b97e3a06.png

 

Im Ordner "30b0... " sind nun auch alle Dateien neu, was man am Datum erkennt:

image.thumb.png.e7c98c638a44df8b222f22172ec4f7b0.png

 

 

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.

  • Thanks 1
Link to comment

@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.

  • Thanks 1
Link to comment

 

On 8/18/2021 at 10:15 AM, mgutt said:

Docker vom docker.img auf "Directory" umstellen:
image.png.f1e9edbfe3bb537d0799625edffdda4e.png
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 by gilladur
Link to comment
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.

  • Like 1
Link to comment
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.

grafik.png.ca88edb44112d823cdf4c63da9e71671.png

 

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

 

Link to comment
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 by sonic6
Link to comment
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.

Link to comment
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?

Link to comment
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 by gilladur
Link to comment
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)

image.png.9548e07638b236aaeb81fa01da6ea921.png

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.

Link to comment
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.

Link to comment
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:

  1. Docker auf Pfad umstellen
  2. Per "Yes" starten
  3. Dann die oben genannten Kommandos über das WebTerminal ausführen
  4. Und als letztes über Apps > Previous Apps die Container wieder installieren
  • Like 1
  • Thanks 1
Link to comment
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 by sonic6
Link to comment
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:

761782859_2021-08-2123_33_59.png.d6556e75b473bc6ac44326fb0c917e97.png

 

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.

Link to comment

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

 

 

Link to comment

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.

Link to comment
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.

 

Link to comment
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 🙂

Link to comment
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:

 

506000122_2021-08-2612_22_32.thumb.png.6b8b585c1298f878d0a86712f646edb0.png

 

 

 

  • Like 1
Link to comment
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 by T0a
Link to comment
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:

1745025373_2021-08-2615_22_06.thumb.png.a1677601c7de3f87d5c127a1423bd440.png

 

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.

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.