Festplatte voll wo sind die Daten

Hallo,

ich habe auf meinem Proxmox 8.0 mehrere LXCs und VMs, die Problemlos vor sich hin laufen. Eine VM davon ist, eine Nextcloud Instanz. In der Instalz sind neben Nextcloud, Docker und Mysql installiert.
Mysql bzw. MariaDB ist nur für Nextcloud eingerichtet.

Mein Problem ist, dass das System mitteilt. dass der Speicherplatz auf “/” zu 100% belegt ist. Vor ein paar Tagen habe ich rund 30 GB hinzugefügt und dachte, dass damit das Problem behoben sei.
Aber heute schaue ich auf meine Nextcloud und siehe da, selbes Problem wie vor ein paar Tagen.
Aufgrund der Probleme habe ich vor kurzem auf Nextcloud 27.1.3 upgedated.

image

Wenn ich nun die beiden Dateisystem ausschließe, erhalte ich folgende Speicherbelegung:


Das ist unlogisch.
Wo ist der Speicher? Er kann nur innerhalb von /proc/ irgnedwo sein.
Aber wo?
Mit “du” bekomme ich das nicht raus.
Hat jemand eine Idee? oder vielleicht sogar die Lösung, dass der Speicher auch wieder geleert wird?
Noch etwas, mir ist aufgefallen, dass MYSQL Zeitweise sehr viel CPU braucht.
Auch ist mir aufgefallen, dass im Ordner “/tmp/” mehrere .MAD und .MAI Dateien liegen, diese sind allerdings insgesamt nur 11 GB groß und sind im obigen “du” bericht schon enthalten. Trotzdem fehlen noch etwa 80GB.

Ich hab eben ca 10GB frei gemacht, und nach ein paar Augenblicken waren diese schon wieder belegt.

Weiß einer wie ich das Problem lösen kann? oder hat zumindest einer einen Tipp wie ich auf die Lösung kommen könnte?
In den Log-Files

Danke

Hallo,

neue Info:

ein Neustart bewirkt wunder.
Nachdem ich heute Nacht neu gestartet habe, ist nun wieder 34GB frei, aber wie gesagt, da sind noch einige GB die ich nicht finde.

Kann mir jemand sagen, wie ich die fehlenden ca. 35GB finde und damit das Leck?

noch eine Info:
Das Dateisystem füllt sich bis es voll ist, dann wird automatisch wieder gelöscht, währenddessen ist der MYSQL Prozess mehrere Male aktiv und braucht auch ziemlich viel CPU.
Während die CPU so belastet ist, ist das Arbeiten mit der Nextcloud sehr träge.
Könnte es sein, dass MYSQL im Hintergrund irgendetwas macht, das die Festplatte füllt?

der Befehl du -h --max-depth=1 ist nicht sehr aussagekräftig weil du die Verzeichnisse nicht komplett scannst. Wenn etwas mit der (my)SQL Datenbank gemacht wird schreibt der Prozess s.g. “transaction logs”. Diese logs dienen der Integrität der DB und können durchaus gross werden (alle Schreibvorgänge werden dort zusätzlich abgelegt). Da du einen Zusammenhang mit der SQL DB vermutest würde ich mit auf dei DB Verzeichnisse konzentrieren - speziell transaction logs.

Es könnte z.B. sein dass du bei mehreren Usern grosse externe Speicher eingebunden hast - dann werden die Daten mehrfach in die DB eingelesen (und beanspruchen beim einlesen viel Resourcen)… sollte mE aber auch nicht viele Gigabytes brauchen… ich würde aber erst schauen ob die Annahme stimmt bevor man weiter spekuliert…

Hallo wwe,

danke für deine Antwort.
Da nur 2 User auf der Nextcloud arbeiten und das nur ein oder zweimal wöchentlich, kann das mit den Transaktionslogs nicht wirkich sein, oder?
Was den Befehtl “du -h --max-depth=1” angeht, muss ich dir wiederspreichen, da der Befehl nur die Anzeige auf eine Ebene beschränkt, nicht aber den Inhalt. Die Ordner werden schon alle durchgescannt. Ich habe auch schon mit dem Befehl “ncdu” gescannt, der macht im Prinzip dasselbe wie “du” nur auf eine GUI-Art in der Konsole.
Von daher kann ich jedenfalls bestätigen, dass der Speicherplatz immer wieder gefüllt wird, und dann kann der PC/VM ihn irgendwie nicht mehr leeren. Wenn der Speicherplatz wiedermal zu 100% gefüllt ist, hilft nur ein Neustart.
Das einzige das ich heute gemacht habe ist, mich eingeloggt, von Dateien zu den Apps gewechselt, geschaut ob es Updates gibt und wieder zurück zu den Dateien gewechselt. Das war vor ca. 4 Stunden, nun ist der Speicherplatz zu 100% gefüllt und ich habe keine Ahnung wo der Speicherplatz hin ist. Heute morgen waren rund 70GB frei. Laut “du -h” sind vom System 21GB von 100GB belegt. Mir fehlen da 80 GB.
Siehe da, nach dem Neustart sind 79GB frei.

Was die externen Speicher angeht. Ja für mich habe ich einen großen externen Speicher eingebunden, aber ist nicht mal gemountet. Nur innerhalb von Nextcloud verbunden. Wenn der lokalen Speicher brauchen würde müsste der doch irgendwo angezeigt werden.

irgendwelche Ideen?
Danke

du hast recht :see_no_evil: man lernt nie aus - danke für den Tipp!

die Grundaussage steht noch - finde erst mal raus was den Platz wegnimmt… evtl. ist auch --exclude-docker der Fehler… wenn ein container den Platz verwendet siehst du das nicht…

hallo,

Weder Nextcloud noch Mysql ist in Docker installiert. In Docker sind andere Dienste wie Bittwarden und Collabora. Außerdem ist Docker in einem eigenen Dateisystem.
Wie finde ich raus wer den Speicherplatz verbraucht, wenn der Speicherplatz scheinbar physisch nicht ersichtlich ist?
Ich sehe in meiner Überwachung, dass nicht ganz einmal pro Stunde der Speicher sich füllt.

ich bin auch kein Crack im Linux… aber das PRoblem hat mE nichts mit Nextcloud zu tun. Wenn du Ausgabe die Files und DB der Nextcloud konstant gross anzeigt scheint das Problem woanders zu sein… wo es genau ist kann ich dir nicht helfen - ich denke deine Frage ist in einem reinen Proxmox Forum besser aufgehoben.

Nutzt Du ZFS? Maybe Snapshots? Wie ist das Setup genau? In einer VM oder einem lxc? Wo liegt deine Datenbank?
Du nutzt docker - welches image?
Zeig mal die config von dem Teil - also cat docker-compose.yml
So fehlen da einfach zu viele Infos um dir zu helfen.

Hallo Martin_Ho,

danke für diene Antwort.
Es handelt sie hier um eine VM. In dieser VM ist Nextcloud (27.1.3) und Mysql(10.3.39-MariaDB-0+deb10u1 Debian 10) (liegt lokal, amselben Server) installiert, nicht in Docker.
In Docker sind diese Container: Vaultwarden, Collabora, Watchtower, Portainer und Guacamole.
Das Dateisystem ist ext4, Snapshots werden hier keine gemacht.
Welche Infos können noch hilfreich sein?

die Frage ist immer noch gleich - was füllt die Disk mit Daten? wenn du keinen Weg findest die Daten im Filesystem sichtbar zu machen aber merkst dass die Disk schnell gefüllt wird kannst du mit tools wie iotop rausfinden welche Prozesse die Disk nutzen - und dort mit dem genaueren Troubleshooting weiter machen

Ok, dann hab ich das setup zumindest jetzt halbwegs verstanden.
Generell - aber nicht themenspezifisch: spring ruhig auf debian 12 - ist stable und läuft.

Dein Ansatz über du -ha --max-depth=1 zu gehen war schon passend denke ich, ist auch mein weg.

Wie du schon sagtest, wird dein temp ordner mit mai und mad dateien geflutet die riesig sind. Und hier ist glaube ich genau das Problem, denn soweit ich das kurz nachgelesen hab, sind das dateien von MariaDB, die bei fehlern erstellt werden.
Also mal ins Blaue geschossen: dein Setup der Datenbank ist nicht ideal, insbesondere nutzt du wahrscheinlich nicht innodb.
Also schau dir da mal die konfig an oder alternativ: clone die VM, installier dir postgres und zieh direkt komplett auf postgres um und spar die die manuellen korrekturen.

Falls Du bei MariaDB bleiben willst: schau wie gesagt mal nach innodb. Welche Version von mariaDB nutzt Du? ggf. ist die auch schon etwas in die tage gekommen…

Kommentare zu den Einsatz von du:

  1. Du kannst die Ausgabe pipen durch anhängen von | sort -h. Das macht das Lesen einfacher :wink:
  2. Du solltest nur auf dem einen Laufwerk schauen. Dazu kannst du -x zusätzlich setzen. Das ganze exclude wurde ich lassen, immerhin taken for Daten auch irgendwie dazu.

Es ist auch sicher die Position in /, die Probleme macht? Ggf mit df -h prüfen.

Kannst du den Container klonen? Ggf hilft das auch zum debuggen und dann Mal die Dienste stückweise deaktivieren, bis das Problem verschwindet.

Hallo christianlupus,

danke für die Antwort, und sorry für meine späte Antwort.

ja es handelt sich sicher um die Partition /.
Ich habe inzwischen auch herausgefunden, dass Mysql/MariaDB das Problem ist. Warum, das kann ich nicht sagen. Ich date jetzt mal auf Debian 12 up und schaue mir dann die Mirgration auf Postgresql an.
Hoffentlich ist damit das Problem dann gelöst

sobald ich damit durch bin, medle ich mich mit dem Resultat.

bis dahin…

Guten morgen.

OK, wenn das Update das Problem beseitigen sollte: Top, dann sind wir “fertig”.

Wenn es nicht helfen sollte: Ich habe die Vermutung, dass irgend ein Logging Daten akkumuliert. Wenn das die Ursache ist, dann wird das Update wahrscheinlich nicht helfen, da die Konfiguration ja nicht zurückgesetzt wird.

Ansonsten, hast du einmal die Ursache räumlich näher einschränken können als /var/lib/mysql (meine Vermutung)? Da gibt es ein paar Unterverzeichnisse und die haben unterschiedliche Aufgaben…
Du könntest auch das Tool qdirstar-cache-writer nutzen, um zu einem Zeitpunkt von einem Verzeichnis einen “Schappschuss” zu speichern. Dann 2 Tage später noch einmal und dann kannst du mit qdirstat -c <Datei> die Schappschüsse lesen und manuell auf Zuwachs vergleichen. Wenn es im GB-Bereich ist, dürfte das gehen.

Hallo christianlupus,

danke für deinen Input.
Den Ort, wo die “vielen Daten” abgelegt werden, habe ich zwar immer noch nicht gefunden, aber ich habe den/die Prozess/e identifiziert die läuft, wenn plötzlich soviele Daten produziert werden. Es ist definitiv MariaDB der Verursacher. Dank des Tools iotop habe ich den Schuldigen identifiziert.
Ich kann mir aber leider immer noch keinen Reim daraus machen wo die Daten abgelegt werden denn laut df -h ist das root Dateisystem (/) zeitweise mit 100% belegt aber wenn ich das ganze mit du --max-depth=1 eingrenzen will, kommen da ganz was anderes raus.
Außerdem wenn ich den Dienst mysql stoppe wird der Speicherplatz freigegeben, also muss das mit mysql zu tun haben… oder?

Gerade eben ist der Speicher wieder weniger geworden und ich hab natürlich gleich unter /var/lib/mysql nachgeschaut, aber da ist der belegte Speicher immer noch gleich. Der belegte Platz ist bei 19%. Inwischen ist er bei 92%, steigend.

Das Update von Debian Buster auf Bookworm hat jedenfall noch nichts gebraucht. Hatte ich ehrlich gesagt auch nicht erwartet.
Dann werde ich jetzt mal von Mysql/MariaDB auf Postgresql umstellen. Mal schauen ob das was bringt. Heute hat sich noch niemand an der Nextcloud angemeldet. Ich sehe auf meinem Monitoring, dass mindestens einmal die Stunde der Speicherplatz komplett verbraucht wird.

Wie gesagt im Dateisystem selber finde ich den verbrauchten Speicher aber nicht. Das ist sehr merkwürdig.
Ich habe grad einen du -h -x --max-depth=1 und gleich im Anschluss ein df -h und die stimmen nicht zusammen. Laut du verbraucht das System 38GB laut df aber 68GB.
In /tmp ist sehr viel drin, 20GB .MAI und .MAD Datein. Wobei dieses Verzeichnis wird größer. Kann das an einem Datenbankfehler liegen?
Gibt’s eine Möglichkeit die Datenbank zu überprüfen bzw. zu reparieren?

Danke für die Hilfe