Ich habe seit mehreren Wochen Probleme mit meinem Gladys-Backup, aber ich hatte keine Zeit, die notwendigen Überprüfungen durchzuführen.
Tatsächlich blockiert Gladys jede Nacht, wenn das Backup ausgelöst wird (keine Dashboard-Anzeige mehr, keine Szenenauslösung, …), und das dauert etwa 2 Stunden. Dann erhalte ich in Telegram die Nachricht « Gladys wurde gerade neu gestartet » (das ist das Ergebnis einer Szene, die durch « Gladys startet » ausgelöst wird), und alles funktioniert wieder.
Mit Hilfe von Claude habe ich heute Morgen das Problem untersucht. Bei einem Schritt seiner Analyse habe ich geantwortet, dass ich « eine mittlere Datenbank (einige Gigas) » habe, aber ich bin mir nicht sicher, ob ich richtig geantwortet habe. In der Historie meiner Backups sehe ich das:
Als erste Maßnahme schlug Claude mir vor, den Gladys zugewiesenen RAM zu ändern (mit dem Befehl sudo docker update --memory="6g" --memory-swap="8g" gladys), damit mein Problem nicht mehr zu einer Blockade für mehrere Stunden führt. Und tatsächlich, als ich manuell ein Backup gestartet habe, erfolgte der Absturz und das Neustarten in 3-4 Minuten. Das ist besser, um meine Hausautomation nicht zu blockieren, aber es löst das Problem des fehlgeschlagenen Backups noch nicht 
Ich nutze einen Intel NUC5PPYB Mini-PC, Prozessor N3700 4 Kerne 1.6GHz, 8GB RAM, unter Ubuntu 22.04, und Gladys wurde mit dem Standard-Befehl « docker run » installiert. Ich habe nichts anderes als Gladys auf diesem Server.
Hier ist der abschließende Bericht von Claude:
Speicherpeak / OOM-Kill während des GladysPlus-Backups
Zusammenfassung
Jedes GladysPlus-Backup (automatisch 2h-4h oder manuell) lässt den RAM des
Gladys-Containers so stark ansteigen, dass ein OOM-Kill des Node-Prozesses
ausgelöst wird, gefolgt von einem automatischen Neustart des Containers.
Umgebung
- Gladys in Docker auf Mini-PC/NUC
- Gesamter RAM des Hosts: 7,7 GB (8 GB nicht erweiterbar)
- Datenbank: mittlere Größe (einige GB)
- Container
gladysmanuell auf 6 GB RAM begrenzt (docker update --memory)
um zu verhindern, dass der OOM den gesamten Host destabilisiert (Swap-Thrashing wurde vor
der Einrichtung dieser Grenze beobachtet)
Reproduktion
Manuelles Backup ausgelöst um 09:36 Uhr.
- 09:36:01 - RSS vor Backup: 4388,77 MB, Heap 233,97/392,50 MB
- 09:36:01 - DuckDB vor Backup: Gesamt 2248,75 MB (BASE_TABLE: 2246,00 MB,
IN_MEMORY_TABLE: 2,75 MB) - 09:36:04 - Öffnen einer zweiten DuckDB-Instanz, die dem Backup gewidmet ist
(duckDbCreateBackupInstance,memory_limit=1024MB,threads=2,READ_ONLY)
zum Exportieren in einen Parquet-Ordner - 09:38 - RAM des Containers: ~6 GB (Grenze erreicht)
- 09:40 -
Out of memory: Killed process ... (MainThread) - 09:41 - Container neu gestartet, Gladys wieder funktionsfähig
Ohne die manuell festgelegte 6-GB-Grenze auf Docker-Ebene hat derselbe Vorgang
unter realen Bedingungen (automatisches nächtliches Backup) einen Swap-Thrashing-Episoden
auf dem gesamten Host von 02:23 bis 04:44 (Dashboard und Szenen nicht nutzbar) verursacht,
der RSS des Prozesses hatte 6774,54 MB vor dem Kill erreicht (dmesg:
Out of memory: Killed process 1542 (MainThread) total-vm:30424440kB, anon-rss:6774536kB).
Hypothese
Die neue DuckDB-Instanz, die für das Backup erstellt wurde (begrenzt auf 1024 MB), scheint
sich zur bereits von der Haupt-DuckDB-Instanz belegten Speicher (ca. 2,25 GB) zu addieren,
statt einen globalen Speicherbudget des Prozesses zu teilen/respektieren. Auf einer Maschine, auf der der Prozess bereits mit ~4,4 GB im Leerlauf läuft, reicht die zusätzliche Belastung von
~1 GB aus, um den verfügbaren RAM zu überschreiten.
Frage an die Entwickler
- Ist es normal, dass
BASE_TABLEfast vollständig im Speicher bleibt (2,25 GB)
im Leerlauf, außerhalb des Backups, für eine Datenbank mittlerer Größe? - Kann der
memory_limit=1024MBder Backup-Instanz reduziert werden, oder kann der
Backup-Prozess streamen/batchweise verarbeiten, anstatt so viel in den Speicher zu laden, um innerhalb einer vernünftigen Gesamtgröße zu bleiben, selbst auf Hardware mit 8 GB RAM?
(oder jemand anderes!)
