Discourse Bild- und Installationsgröße. /var/lib/docker/overlay2? bereinigen?

Unterstützung Installation
1

Hallo, ich habe Discourse auf einer neuen, dedizierten Maschine installiert, und zwar nach der Anleitung unter discourse/docs/INSTALL-cloud.md at main · discourse/discourse · GitHub.

Der Server verfügt über 15 GB Festplattenspeicher. Selbst wenn die Installation noch nicht produktiv läuft (weniger als 10 Benutzer, keine Anhänge, einige erstellte und gelöschte Beiträge), scheint die Installationsgröße dennoch recht groß zu sein.

#df -kh
Filesystem                         Size  Used Avail Use% Mounted on
udev                               950M     0  950M   0% /dev
tmpfs                              199M  1.3M  198M   1% /run
/dev/mapper/ubuntu--vg-ubuntu--lv   15G   11G  3.2G  78% /
tmpfs                              994M     0  994M   0% /dev/shm
tmpfs                              5.0M     0  5.0M   0% /run/lock
tmpfs                              994M     0  994M   0% /sys/fs/cgroup
/dev/sda2                          976M  203M  707M  23% /boot
/dev/loop0                          56M   56M     0 100% /snap/core18/2066
/dev/loop1                          56M   56M     0 100% /snap/core18/2074
/dev/loop2                          33M   33M     0 100% /snap/snapd/12398
/dev/loop3                          33M   33M     0 100% /snap/snapd/12159
/dev/loop4                          68M   68M     0 100% /snap/lxd/20326
overlay                             15G   11G  3.2G  78% /var/lib/docker/overlay2/ef92e2dc7a656c20eccbbdd40e660c76631ef48b6989f9ded3889a929eb*****/merged
/dev/loop6                          71M   71M     0 100% /snap/lxd/21029
tmpfs                              199M     0  199M   0% /run/user/1000

# du -csh /var/lib/docker/overlay2
580M    51d029d96e73b67e449f0b0570be47b6292da46c8c69b9f0dc6df35db85*****
2.3G    ae38f397c79178185e26b87a9e2c6c890b0db9d3456de6d34ae3c3b96db*****
76M     d1b8d94d2ecfa140794c61e2a81ad4a09eba1646d764018cf5afd433b51*****
4.5G    ef92e2dc7a656c20eccbbdd40e660c76631ef48b6989f9ded3889a929eb*****
40K     ef92e2dc7a656c20eccbbdd40e660c76631ef48b6989f9ded3889a929eb*****-init
24K     l
7.4G    total

# du -shc /var/lib/docker/overlay2/*/diff
580M    /var/lib/docker/overlay2/51d029d96e73b67e449f0b0570be47b6292da46c8c69b9f0dc6df35db85*****/diff
2.3G    /var/lib/docker/overlay2/ae38f397c79178185e26b87a9e2c6c890b0db9d3456de6d34ae3c3b96db*****/diff
76M     /var/lib/docker/overlay2/d1b8d94d2ecfa140794c61e2a81ad4a09eba1646d764018cf5afd433b51*****/diff
996M    /var/lib/docker/overlay2/ef92e2dc7a656c20eccbbdd40e660c76631ef48b6989f9ded3889a929eb*****/diff
20K     /var/lib/docker/overlay2/ef92e2dc7a656c20eccbbdd40e660c76631ef48b6989f9ded3889a929eb*****-init/diff
3.9G    total

# docker images -a
REPOSITORY            TAG       IMAGE ID       CREATED        SIZE
local_discourse/app   latest    b29b7073fea2   2 months ago   2.69GB
<none>                <none>    30e4746e631e   3 months ago   2.23GB

docker system df
TYPE            TOTAL     ACTIVE    SIZE      RECLAIMABLE
Images          1         1         2.689GB   0B (0%)
Containers      1         1         950.4MB   0B (0%)
Local Volumes   0         0         0B        0B
Build Cache     0         0         0B        0B

Ich habe dies versucht, aber es hat nicht geholfen:

# /var/discourse/launcher cleanup
WARNING! This will remove all stopped containers.
Are you sure you want to continue? [y/N] y
Total reclaimed space: 0B
WARNING! This will remove all images without at least one container associated to them.
Are you sure you want to continue? [y/N] y
Total reclaimed space: 0B

Ich mache mir Sorgen, dass die Installation in der Produktion immer mehr Speicherplatz verbrauchen und zum Absturz führen könnte. Könnten Sie mir empfehlen, welche Größe das Docker-Image und die Installation normalerweise haben sollten und was ich tun kann, um Speicherplatz freizugeben?

Vielen Dank.

1 „Gefällt mir“
2

Ich bin gespannt, was die Bedeutung des Docker-Images <none> ist. (Edit: Es scheint, dass es nicht allzu wichtig ist, wenn ein <none>-Image in docker images -a auftaucht. Taucht es jedoch in docker images auf, ist es eine Verschwendung von Speicherplatz. Ich würde hoffen, dass die Bereinigung durch den Launcher hilft, aber das hat bei dir leider nicht funktioniert.)

Beachte, dass die vom Befehl df angezeigte Nutzung des Overlay-Dateisystems mit der Nutzung des Root-Dateisystems übereinstimmt: Es gibt viele Daten, die eine doppelte Funktion erfüllen, und du musst darauf achten, sie nicht doppelt zu zählen. In deinem Fall beträgt der verfügbare Speicherplatz 3,2 GB, und das ist der Wert, der dir Sorgen bereiten sollte. Es könnte durchaus einige Aufräumarbeiten geben, die erledigt werden müssen.

Ich zeige dir unten meine ähnlichen Statistiken. Ich habe zwei Foren, jeweils auf einem anderen Host. Der eine Host verfügt über 20 GB, der andere über 25 GB Speicherplatz. Ich denke, 15 GB könnten sich als sehr knapp erweisen, besonders wenn der Update-Prozess vor dem Start 5 GB freien Speicherplatz benötigt.

# df -h /
Filesystem      Size  Used Avail Use% Mounted on
/dev/vda1        25G   19G  5.1G  79% /

# docker images -a
REPOSITORY            TAG                 IMAGE ID            CREATED             SIZE
local_discourse/app   latest              8da0107aba03        2 months ago        2.7GB
discourse/base        2.0.20210415-1332   30e4746e631e        3 months ago        2.23GB
<none>                <none>              1e6bf44c2762        5 months ago        2.46GB
discourse/base        2.0.20201221-2020   c0704d4ce2b4        7 months ago        2.11GB


# du -shc /var/lib/docker/overlay2/*/diff
2.2G	/var/lib/docker/overlay2/05fa0e4df2...
76M 	/var/lib/docker/overlay2/58b000b1f5c...
20K  	/var/lib/docker/overlay2/6271023fc7a...
1.1G	/var/lib/docker/overlay2/6271023fc7...
2.3G	/var/lib/docker/overlay2/91d6adf7ad...
481M	/var/lib/docker/overlay2/b6b06a7cee...
592M	/var/lib/docker/overlay2/d81e44d563...
76M 	/var/lib/docker/overlay2/fb98649680b...
6.8G	total


# du -shc /var/lib/docker/overlay2/*
2.2G	/var/lib/docker/overlay2/05fa0e4df2...
76M 	/var/lib/docker/overlay2/58b000b1f5c...
4.7G	/var/lib/docker/overlay2/6271023fc7...
40K  	/var/lib/docker/overlay2/6271023fc7a...
2.3G	/var/lib/docker/overlay2/91d6adf7ad...
481M	/var/lib/docker/overlay2/b6b06a7cee...
592M	/var/lib/docker/overlay2/d81e44d563...
76M 	/var/lib/docker/overlay2/fb98649680b...
36K  	/var/lib/docker/overlay2/l
11G	total


# docker system df
TYPE                TOTAL               ACTIVE              SIZE                RECLAIMABLE
Images              4                   1                   5.155GB             4.689GB (90%)
Containers          1                   1                   1.059GB             0B (0%)
Local Volumes       0                   0                   0B                  0B
Build Cache         0                   0                   0B                  0B

Siehe auch möglicherweise Behebung von Discourse nach vollem Datenträger:

und Mindestanforderungen zur Nutzung von Discourse?:

und 2.6.0 Beta 3 Update fehlgeschlagen wegen Festplatten- und/oder Arbeitsspeichermangel:

1 „Gefällt mir“
3

Ein Update: Nachdem ich ein Backup erstellt und ein Update durchgeführt habe, habe ich auch eine Bereinigung ausgeführt.

Ich bin mir ziemlich sicher, dass die Tools zur Verwaltung von Docker-Images vorzuziehen sind gegenüber direkten Eingriffen in /var/lib/docker/overlay2. Und die automatische Bereinigung ist diesen Tools vorzuziehen. (Wie in den verlinkten Beiträgen jedoch erwähnt, wird Festplattenspeicher auch auf andere Weise belegt: Backups, Swap-Dateien, Journal-Dateien, Uploads, Importe, Protokolldateien und so weiter)

Hier ist das Ergebnis, als ‘nachher’ zum oben geposteten ‘vorher’ – beachte, dass der Ausgangspunkt aufgrund des Backups wahrscheinlich weniger freien Speicherplatz hatte:

# df -h /
Filesystem      Size  Used Avail Use% Mounted on
/dev/vda1        25G   19G  5.1G  79% /
# docker images -a
REPOSITORY            TAG                 IMAGE ID            CREATED             SIZE
local_discourse/app   latest              8da0107aba03        2 months ago        2.7GB
discourse/base        2.0.20210415-1332   30e4746e631e        3 months ago        2.23GB
<none>                <none>              1e6bf44c2762        5 months ago        2.46GB
discourse/base        2.0.20201221-2020   c0704d4ce2b4        7 months ago        2.11GB
# /var/discourse/launcher cleanup
WARNING! This will remove all stopped containers.
Are you sure you want to continue? [y/N] y
Total reclaimed space: 0B
WARNING! This will remove all images without at least one container associated to them.
Are you sure you want to continue? [y/N] y
Deleted Images:
untagged: discourse/base:2.0.20201221-2020
untagged: discourse/base@sha256:e18*
deleted: sha256:1e6*
deleted: sha256:a22*
deleted: sha256:c07*
deleted: sha256:9b7*
deleted: sha256:87c*
untagged: discourse/base:2.0.20210415-1332
untagged: discourse/base@sha256:b3b*

Total reclaimed space: 2.456GB
# docker images -a
REPOSITORY            TAG                 IMAGE ID            CREATED             SIZE
local_discourse/app   latest              8da0107aba03        2 months ago        2.7GB
<none>                <none>              30e4746e631e        3 months ago        2.23GB
# docker images 
REPOSITORY            TAG                 IMAGE ID            CREATED             SIZE
local_discourse/app   latest              8da0107aba03        2 months ago        2.7GB
# df -h /
Filesystem      Size  Used Avail Use% Mounted on
/dev/vda1        25G   17G  7.8G  68% /
# docker system df
TYPE                TOTAL               ACTIVE              SIZE                RECLAIMABLE
Images              1                   1                   2.699GB             0B (0%)
Containers          1                   1                   1.13GB              0B (0%)
Local Volumes       0                   0                   0B                  0B
Build Cache         0                   0                   0B                  0B
# df -h /
Filesystem      Size  Used Avail Use% Mounted on
/dev/vda1        25G   17G  7.8G  68% /
# du -shc /var/lib/docker/overlay2/*
4.9G	/var/lib/docker/overlay2/627*
40K 	/var/lib/docker/overlay2/627*-init
2.3G	/var/lib/docker/overlay2/91d*
592M	/var/lib/docker/overlay2/d81*
76M 	/var/lib/docker/overlay2/fb9*
24K 	/var/lib/docker/overlay2/l
7.8G	total
# du -shc /var/lib/docker/overlay2/*/diff
20K 	/var/lib/docker/overlay2/627*-init/diff
1.2G	/var/lib/docker/overlay2/627*/diff
2.3G	/var/lib/docker/overlay2/91d*/diff
592M	/var/lib/docker/overlay2/d81*/diff
76M 	/var/lib/docker/overlay2/fb9*/diff
4.2G	total
1 „Gefällt mir“
4

Ich würde sagen, dass du mindestens 25 GB brauchst, aber @Ed_S hat gesagt, dass es mit 20 funktioniert. Und selbst 25 sind meiner Erfahrung nach etwas knapp bemessen.

1 „Gefällt mir“
5

Hallo zusammen,
vielen Dank für eure Antworten.

Ich habe das Journal mit folgendem Befehl überprüft:

# journalctl --disk-usage
Archivierte und aktive Journale belegen 1,5 GB im Dateisystem.

Und habe diesen Befehl ausgeführt, um Speicherplatz freizugeben:
# journalctl --vacuum-time=10d

Jetzt habe ich 1 GB mehr Speicherplatz.
Meine eigentliche Frage galt dem tatsächlichen Speicherbedarf von Discourse.
Tatsächlich sind meine Backups, da sie nicht in der Produktion laufen, jeweils ca. 10 MB groß, also insgesamt 3 Backups (30 MB).

Ich verstehe den Bedarf an Speicherplatz während eines Updates, aber im laufenden Betrieb erwarte ich, dass die aktuelle Version gespeichert wird und ich die Möglichkeit habe, alte Versionen zu löschen.
Brauchen wir wirklich alle Unterschiede im Overlay, oder können wir den Inhalt irgendwie zusammenführen, um Speicherplatz zurückzugewinnen? Ich sehe auch keine gemounteten Volumes, daher vermute ich, dass Discourse dort alle Daten speichert.

@Ed_S hier das Ergebnis des Befehls:

~# du -kx / | sort -n | tail -33
431172  /usr/bin
482000  /var/lib/snapd
499660  /var/lib/docker/overlay2/ae38f397c79178185e26b87a9e2c6c890b0db9d3456de6d34ae3c3b96db*****/diff/var/www/discourse/vendor/bundle/ruby/2.7.0/gems
533056  /var/lib/docker/overlay2/51d029d96e73b67e449f0b0570be47b6292da46c8c69b9f0dc6df35db85*****/diff/var/www/discourse
533060  /var/lib/docker/overlay2/51d029d96e73b67e449f0b0570be47b6292da46c8c69b9f0dc6df35db85*****/diff/var/www
556800  /usr/lib/firmware
570876  /usr/lib/modules
574032  /var/lib/docker/overlay2/51d029d96e73b67e449f0b0570be47b6292da46c8c69b9f0dc6df35db85*****/diff/var
593840  /var/lib/docker/overlay2/51d029d96e73b67e449f0b0570be47b6292da46c8c69b9f0dc6df35db85*****/diff
593856  /var/lib/docker/overlay2/51d029d96e73b67e449f0b0570be47b6292da46c8c69b9f0dc6df35db85*****
626400  /var/lib/docker/overlay2/ae38f397c79178185e26b87a9e2c6c890b0db9d3456de6d34ae3c3b96db*****/diff/var/www/discourse/vendor/bundle/ruby/2.7.0
626404  /var/lib/docker/overlay2/ae38f397c79178185e26b87a9e2c6c890b0db9d3456de6d34ae3c3b96db*****/diff/var/www/discourse/vendor/bundle/ruby
626408  /var/lib/docker/overlay2/ae38f397c79178185e26b87a9e2c6c890b0db9d3456de6d34ae3c3b96db*****/diff/var/www/discourse/vendor/bundle
634964  /var/lib/docker/overlay2/ae38f397c79178185e26b87a9e2c6c890b0db9d3456de6d34ae3c3b96db*****/diff/var/www/discourse/vendor
845496  /var/lib/docker/overlay2/ae38f397c79178185e26b87a9e2c6c890b0db9d3456de6d34ae3c3b96db*****/diff/usr/lib
863600  /var/lib/docker/overlay2/ae38f397c79178185e26b87a9e2c6c890b0db9d3456de6d34ae3c3b96db*****/diff/var/www/discourse
863612  /var/lib/docker/overlay2/ae38f397c79178185e26b87a9e2c6c890b0db9d3456de6d34ae3c3b96db*****/diff/var/www
936876  /var/lib/docker/overlay2/ae38f397c79178185e26b87a9e2c6c890b0db9d3456de6d34ae3c3b96db*****/diff/var
1004276 /var/lib/docker/overlay2/ef92e2dc7a656c20eccbbdd40e660c76631ef48b6989f9ded3889a929eb*****/diff/var/www/discourse
1004284 /var/lib/docker/overlay2/ef92e2dc7a656c20eccbbdd40e660c76631ef48b6989f9ded3889a929eb*****/diff/var/www
1032452 /var/lib/docker/overlay2/ef92e2dc7a656c20eccbbdd40e660c76631ef48b6989f9ded3889a929eb*****/diff/var
1091584 /var/lib/docker/overlay2/ef92e2dc7a656c20eccbbdd40e660c76631ef48b6989f9ded3889a929eb*****/diff
1091604 /var/lib/docker/overlay2/ef92e2dc7a656c20eccbbdd40e660c76631ef48b6989f9ded3889a929eb*****
1426272 /var/lib/docker/overlay2/ae38f397c79178185e26b87a9e2c6c890b0db9d3456de6d34ae3c3b96db*****/diff/usr
1579980 /usr/lib
2398720 /var/lib/docker/overlay2/ae38f397c79178185e26b87a9e2c6c890b0db9d3456de6d34ae3c3b96db*****/diff
2398736 /var/lib/docker/overlay2/ae38f397c79178185e26b87a9e2c6c890b0db9d3456de6d34ae3c3b96db*****
2607528 /usr
4161292 /var/lib/docker/overlay2
4171308 /var/lib/docker
4816636 /var/lib
5509688 /var
10220684        /
1 „Gefällt mir“
6

Im verlinkten Thread sehen wir eine Situation, in der ./launcher cleanup nicht half, aber docker system prune --all --volumes --force doch half. Ich weiß nicht, warum das so ist.

Ich verstehe nicht, wie sich die Docker-Images stapeln, warum die Diff-Verzeichnisse so groß sind oder warum die Docker-Festplattennutzung deutlich höher ausfällt als die von Docker gemeldeten Größen.

Es sei jedoch darauf hingewiesen, dass die Minimierung der Festplattennutzung Aufwand erfordert: Weder Docker noch Discourse priorisieren die Minimierung der Festplattennutzung. Beide Projekte konzentrieren sich lieber auf die Verbesserung des Produkts und die Einfachheit der Abläufe.

Ich betreibe erfolgreich eine Instanz mit 20 GB. Da für Upgrades 5 GB frei gehalten werden müssen, ergibt sich daraus eine tatsächliche Obergrenze von 15 GB für genutzten Speicherplatz. In Ihrem Fall, mit einer 15-GB-Instanz, müssten Sie versuchen, bei 10 GB genutztem Speicher zu bleiben. Das dürfte schwieriger sein, vielleicht sogar unmöglich. Es gibt sicherlich ein absolutes Minimum.

Ich bin mir ziemlich sicher, dass ich einen Thread gesehen habe, in dem empfohlen wurde, Docker und Discourse vollständig zu entfernen, nur die Site-Konfiguration und die Datenbank zu belassen und dann neu zu installieren. Das würde ich nicht leichtfertig tun, und auf keinen Fall ohne ein Backup! Leider kann ich diesen Thread im Moment nicht finden.

7

Meine docker volume ls-Liste ist leer; das hängt davon ab, ob Leute Volumes gemountet haben.

Es wäre schön, wenn es eine offiziellere Spezifikation oder eine erwartete Installationsgröße gäbe. Vielleicht existiert diese irgendwo, aber ich habe sie nicht gefunden.
Ich verstehe, dass 20 GB in der heutigen Welt nicht viel sind, aber wenn es um Backups, Remote-Transfers, Duplizierung und so weiter geht, ist das eine Verschwendung von Speicherplatz, die sich vielleicht vermeiden ließe, wenn wir wüssten, wie wir diesen Speicherplatz von Anfang an sparen können.

Die Installation ohne Docker ist zwar möglich, aber soweit ich weiß, wird sie bei Problemen nicht unterstützt.

8

Und 25 GB ist genau das, was der typische Einsteiger und Nutzer mit kleinem Budget erhält, der Digital Ocean nutzt. Das ist wirklich die Zielgruppe.

Die Gruppe von Personen, die über das Fachwissen verfügt, einen Datenträger mit weniger als 25 GB zu verwalten, aber nicht das Budget für 25 GB Speicherplatz hat, ist sehr klein. Ich glaube, du bist die erste Person, die in den letzten fünf Jahren eine solche Anfrage gestellt hat.

Du könntest etwas sparen, indem du deine eigenen Backups verwaltest und sie remote sicherst. Für ein einzelnes Backup werden drei Kopien benötigt: die alte Kopie, die neue unkomprimierte Kopie und die neue komprimierte Kopie. Das ist der größte Speicherplatzgewinn, an den ich denken kann, aber ich behaupte nicht, über umfangreiches spezielles Docker-Wissen zu verfügen.

Du könntest auch versuchen, das neue Image remote auf einem temporären Server zu erstellen und es in ein Repository zu pushen. Dann bräuchtest du keinen zusätzlichen Docker-Speicherplatz lokal. Das ist wahrscheinlich deine beste Option, aber es gibt keine gut dokumentierte Methode dafür, und es wird größtenteils nicht unterstützt (obwohl mehr als bei einer Nicht-Docker-Installation). Wenn du mich beauftragen würdest, dies zu tun, würden die Kosten Jahre dessen betragen, was 10 GB Speicherplatz kosten. Ich habe über einen Service nachgedacht, bei dem ich diese Images erstelle (im Wesentlichen eine besser unterstützte Bitnami), bin aber nicht dazu gekommen, weil ich nicht glaube, dass es einen Markt gibt, der die Entwicklungszeit rechtfertigt.

9

Ich würde gerne wissen, wie viel Ihr 15-GB-Server kostet und von welchem Anbieter. Meine 25-GB-Maschine kostet mich 6 pro Monat bei Digital Ocean, und meine 20-GB-Maschine kostet 3 bei Hetzner.

Wenn Sie nicht erwarten, dass Sie das Verhalten aus Systemprotokollen debuggen müssen, können Sie die Journals sehr radikal bereinigen.

# journalctl --rotate
# journalctl --vacuum-time=1s

Ich habe jedoch die Richtlinie geändert:

/etc/systemd/journald.conf:
[Journal]
SystemMaxUse=50M

Die Festplattennutzung auf der 20-GB-Maschine, auf der sich ein sehr kleines Forum mit geringer Aktivität befindet, sieht wie folgt aus:

# df -h
Filesystem      Size  Used Avail Use% Mounted on
/dev/sda1        19G  9.9G  8.1G  56% /

Betriebssystem:

15M /bin
16M /sbin
43M /boot/
135M /var/cache/
223M /var/log
435M /lib
464M /var/lib/apt
1.1G /usr
2.1G /swapfile
4.3G total

Discourse:

# du -hs /var/discourse/ /var/lib/docker/
1.5G /var/discourse/
7.5G /var/lib/docker/

Edit: Aha, aber wir zählen doppelt. Sehen Sie stattdessen:

# du -hxs /var/discourse/ /var/lib/docker/
1.5G /var/discourse/
4.1G /var/lib/docker/

Das Forum selbst, innerhalb der obigen Werte:

201M	/var/discourse/shared/standalone/uploads
315M	/var/discourse/shared/standalone/postgres_data
930M	/var/discourse/shared/standalone/backups

Ich verwende Ubuntu 18.04, während es aussieht, als würden Sie eher eine Version wie 20.04 verwenden, die wahrscheinlich größer ist.

10

Ich nutze verschiedene VPS. Ich habe einige VMs bei Contabo und andere bei Azure. Für mich stellt sich die Frage, ob das, was ich betreibe, wie erwartet gewartet und konfiguriert ist (Größe, Bereinigung usw.).

Danke für den Tipp bezüglich der Änderung der Richtlinie für journald. Ich habe es umgesetzt (ich habe vorher bereits bereinigt, also nur eine geringe Einsparung, aber zumindest muss ich es jetzt nicht mehr prüfen).

Deine Festplattennutzung ist mehr oder weniger gleich meiner:

# du -hxs /var/discourse/ /var/lib/docker/
181M    /var/discourse/
4.0G    /var/lib/docker/

Ich würde eine Löschung von Docker und einen Neuaufbau in Betracht ziehen, aber da kein festes Volumen für Docker eingehängt ist, habe ich Sorge, bei der Löschung Forumsdaten zu verlieren. Ich werde auf ein offizielles Verfahren dazu warten.

11

Ja, es lohnt sich, nach einer Bestätigung zu suchen. Ich bin mir ziemlich sicher, dass alle Forumsdaten unter /var/discourse liegen.

Eine andere Möglichkeit, die dir vielleicht zur Verfügung steht, ist das Starten einer neuen Instanz und die frische Installation von Discourse, um zu sehen, wie es aussieht. (Man sollte sowieso seine Backups testen!)

1 „Gefällt mir“