Läuft 3.2.0.beta4-dev ( 86da47f58d ), aber wir haben dieses Problem schon seit einiger Zeit.
Wir haben Backups konfiguriert, die direkt an S3 gehen. Verständlicherweise nimmt die Anwendung sie zuerst in den lokalen Speicher auf und lädt sie dann nach S3 hoch, was in Ordnung ist. Das Problem ist, dass sie nach dem Hochladen nicht gelöscht werden, was zu einer enormen Speicherplatznutzung führt, selbst ohne Miniaturansichten, die in den Backups gespeichert sind.
Könnte das ein Berechtigungsproblem mit dem Verzeichnis sein, möglicherweise? Ich habe es sicherlich nicht geändert.
root@forum:/var/discourse/shared/standalone/tmp/backups# ls -la
total 12
drwxr-xr-x 3 mas www-data 4096 Nov 23 06:44 .
drwxr-xr-x 4 mas www-data 4096 Nov 22 04:57 ..
drwxr-xr-x 2 mas www-data 4096 Jan 9 15:35 default
Was seltsam ist, ist, dass wir in der Liste der temporären Dateien sehen, dass der 2., 3., 7., 8. und 9. Januar Speicherplatz verbrauchen. In der Discourse-Backup-Liste in der Admin-Oberfläche sehe ich nur den 4. Januar. Vielleicht erstellt Discourse diese Backups, lädt sie aber nicht ordnungsgemäß nach S3 hoch? Das Problem mit dieser Theorie ist, dass die “Backup-Frequenz” in der Admin-Konfiguration auf 3 gesetzt ist, sodass es sowieso nicht jeden Tag versuchen sollte, ein Backup zu erstellen. Beachten Sie, dass die Backup-Protokolle in der Admin-Oberfläche leer sind, keine Protokolle dort.
Der Host hat eine Uptime von 90 Tagen und der Docker-Container eine Uptime von 6 Wochen, also keine tatsächlichen Neustarts, es sei denn, Sie sprechen von etwas innerhalb der Anwendung.
Keine manuellen Backups von mir, schon gar nicht täglich. Auch nichts in Cron etc.
root@forum:/# uptime
17:20:56 up 90 days, 1:52, 4 users, load average: 0.81, 1.71, 1.81
root@forum:/# docker ps
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
d8bc34250454 local_discourse/app \"/sbin/boot\" 6 weeks ago Up 6 weeks 0.0.0.0:80-\u003e80/tcp, :::80-\u003e80/tcp, 0.0.0.0:443-\u003e443/tcp, :::443-\u003e443/tcp app
Passiert immer noch, seufz. Ich werde wohl find -mtime +2 -delete per Cronjob ausführen. Gute Zeiten.
root@forum:/var/discourse/shared/standalone/tmp/backups/default# du -sh
14G .
root@forum:/var/discourse/shared/standalone/tmp/backups/default# ls -la
total 16
drwxr-xr-x 4 mas www-data 4096 Jan 16 06:56 .
drwxr-xr-x 3 mas www-data 4096 Nov 23 06:44 ..
drwxr-xr-x 2 mas www-data 4096 Jan 14 06:38 2024-01-14-063807
drwxr-xr-x 2 mas www-data 4096 Jan 15 06:43 2024-01-15-064337
[quote=„Wingtip, Beitrag:3, Thema:291033“]Der Host hat eine Betriebszeit von 90 Tagen und der Docker-Container hat eine Betriebszeit von 6 Wochen, also keine tatsächlichen Neustarts, es sei denn, Sie sprechen über etwas innerhalb der Anwendung.
[/quote]
Verdammt. Das war meine beste Vermutung.
[quote=„Wingtip, Beitrag:4, Thema:291033“]Passiert immer noch, seufz. Ich werde wohl einen Cronjob einrichten, der find -mtime +2 -delete ausführt. Gute Zeiten.
[/quote]
