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.
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
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âŠ
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.
du hast recht 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âŠ
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.
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âŠ
Du kannst die Ausgabe pipen durch anhÀngen von | sort -h. Das macht das Lesen einfacher
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.
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.
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.
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?
man lernt nie aus - danke fĂŒr den Tipp!
