Für Info, ich habe einige Tests mit ChatGPT durchgeführt. Ich habe insbesondere den Gladys-Produktionscontainer mit der folgenden Option neu gestartet, um Snapshots zu erstellen.
Daher, mit Gladys ausgeschaltet, habe ich 4,03 GB Speicherverwendung.
Sobald Gladys fertig gestartet ist, habe ich 5,7 GB Speicher (15:43 Uhr).
Bis 16:00 Uhr bleibe ich in diesem Rahmen, mit nur wenigen Schwankungen. Aber man sieht, dass der Speicher gut freigegeben wird.
Um 16:00 Uhr wurde die Berechnung der Verbräuche/Kosten tatsächlich mit einem leichten Anstieg des Speichers durchgeführt, aber sofort wieder freigegeben. Das bestätigt, dass es nicht das ist. Aufgaben abgeschlossen.
1 Minute später gehe ich zum Dashboard (ich kann nicht sagen, ob es der Auslöser ist) und puff, ich bin sofort auf 8,82 GB gesprungen: Die Spalte « RES » (= reservierter Speicher) geht von 1748 MB auf 4995 MB. => Nichts wird freigegeben
Ich zeige dir hier die rohen Daten von ChatGPT, und wir sehen dann, ob du noch etwas anderes möchtest (Gespräch: ChatGPT)
Ja. Hier sieht man klar, was passiert, und Sie hatten von Anfang an recht: Es ist kein JS-Heap-Leak, es ist ein Speicherausbruch im nativen Bereich (außerhalb von V8), ausgelöst durch eine punktuelle Operation.
Ich gebe Ihnen eine präzise, faktische Analyse, basierend auf dem „Spitzenwert“-Report, den Sie gerade bereitgestellt haben.
Was der Report zum Zeitpunkt des Spitzenwerts sagt (bezahlte Beweise)
JS-Heap (V8)
"usedMemory": 252011200 ≈ 240 MB
"externalMemory": 25243016 ≈ 24 MB
Heap perfekt stabil, fast identisch mit den vorherigen Snapshots.
Kein JS-Leak.
Gesamtprozessspeicher
"rss": 6198140928 ≈ 5,77 GB
"maxRss": 6374838272 ≈ 5,93 GB
+4 GB außerhalb des JS-Heap sind plötzlich aufgetreten.
Linux-Seite (/proc)
RssAnon: 5 089 920 kB ≈ 4,85 GB
RssFile: 59 392 kB
Private_Dirty: 5 090 240 kB
Privater anonymer Speicher
Nicht auf Datei abgebildet
Nicht nachträglich freigegeben
Typische Signatur:
Massive native Allokationen (malloc / new auf C/C+±Seite)
Was es NICHT ist (wichtig)
Nicht:
- V8
- Garbage Collector
- JS-Objekte, die gehalten werden
- Timer oder blockierte Event-Loop
- Klassischer Node-Leak
Ihre Snapshots beweisen:
Der Heap bleibt bei ~260 MB, während der RSS auf ~6 GB explodiert.
Was es ist (fast sicher in diesem Stadium)
Schauen wir uns die geladenen nativen Bindings an:
"/src/server/node_modules/duckdb/lib/binding/duckdb.node"
"/src/server/node_modules/sqlite3/lib/binding/node_sqlite3.node"
"/src/server/services/usb/.../bindings-cpp.node"
"/src/server/services/bluetooth/.../bluetooth_hci_socket.node"
Hauptverdächtiger Nr. 1: DuckDB
Das ist DER Hauptverdächtige, aus mehreren Gründen:
-
DuckDB alloziert massiv im nativen Bereich
-
Verwenden:
- vectorisierte Ausführung
- Spaltenpuffer
- Zwischen-Caches
-
Gibt nicht immer sofort Speicher an das OS zurück
-
Kann bei einer einzigen Abfrage um mehrere GB ansteigen
Und vor allem:
Der Spitzenwert ist sofort da, hoher CPU, Speicher geht nie zurück
→ genau das beobachtete Verhalten.
Warum es nicht zurückgeht
Sehr wichtig zu verstehen:
Also:
Es ist kein unendlicher Leak
Es ist ein unumkehrbarer Anstieg in Stufen
Der wahrscheinlichste Auslöser bei Ihnen
Angesichts Ihrer Gladys + Energy Monitoring + Historien-Konfiguration:
-
Energieaggregation
-
Zeitberechnungen
-
analytische Abfragen
-
möglicherweise:
- tägliche Konsolidierung
- Aggregationen pro Phase / Gerät
- Historien-Nachberechnung
Eine schwere DuckDB-Abfrage wurde gestartet (Cron, interner Job, UI-Aktion).
Das passt zu:
- CPU arbeitet
- RAM-Anstieg in 1 Sekunde
- keine sichtbare JS-Erstellung
Absolute Bestätigung (wenn Sie zu 100% sicher sein wollen)
Beim nächsten Spitzenwert, führen Sie sofort aus:
docker exec gladys bash -lc '
cat /proc/1/smaps | awk "
/duckdb.node/ {f=1}
/^$/ {f=0}
f && /Rss:/ {print}
"
'
Wenn Sie Hunderte von MB / GB sehen, die mit DuckDB verbunden sind → endgültiges Urteil.
Was man konkret tun kann (realistische Lösungen)
Option A – DuckDB begrenzen (empfohlen)
In Gladys (Code):
- Größe der Abfragen begrenzen
- Vermeiden Sie globale Aggregationen über die gesamte Historie
- Chunking nach Zeitraum (Tag / Woche)
Option B – Node-Speichergrenze erzwingen
Das behebt nicht die Ursache, aber verhindert OOM des Hosts:
-e NODE_OPTIONS="--max-old-space-size=2048 ..."
Achtung: begrenzt nicht das native, aber verhindert, dass beide übereinander gestapelt werden.
Option C – Geplanter Neustart (pragmatisch)
Wenn die Spitzenwerte selten, aber zerstörerisch sind:
docker restart gladys
- wöchentlich
- oder nach schwerer Aufgabe
Das ist sehr üblich für DuckDB in der Produktion.
Klare und deutliche Schlussfolgerung
Ihre Daten sind exzellent
Die Diagnose ist jetzt solide
Es gibt keinen JS-Speicherleak
Der RAM wird durch native Allokationen verbraucht (wahrscheinlich DuckDB)
Der Speicher geht nicht zurück, weil er im nativen Arena bleibt
Wenn Sie möchten, nächster möglicher Schritt:
- Identifizieren Sie welche Gladys-Abfrage den Spitzenwert auslöst
- Oder helfen Sie Ihnen, Gladys zu patchen / zu umgehen (SQL-Log, Throttle, Split)
Bis bald!
Man muss herausfinden, welcher Teil von Gladys dafür verantwortlich ist.
