Memory Leak
-
@claus sagte in Memory Leak:
dann kommt ein Zeitpunkt, wo auf einmal die 2GB erreicht werden.
da läuft wohl backitup
-
-
@claus sagte in Memory Leak:
zieht das so viel?
Wenn es gerade damit beschäftigt ist die Daten zu komprimieren: Ja!
Das passiert im RAM.Du kannst mal in den Tab "Instanzen" gucken, welche Instanz gerade wieviel RAM verbrät.
Oder Du postest mal die Ausgabe vontopoderhtop. -
@codierknecht sagte in Memory Leak:
Oder Du postest mal die Ausgabe von top oder htop.
Da ich compact mode nutze, tauchen die Adapter nicht einzeln auf.
top - 17:40:57 up 24 days, 2:19, 0 user, load average: 0,16, 0,17, 0,17 Tasks: 6 total, 1 running, 5 sleeping, 0 stopped, 0 zombie %Cpu(s): 1,8 us, 0,3 sy, 0,0 ni, 98,0 id, 0,0 wa, 0,0 hi, 0,0 si, 0,0 st MiB Mem : 8052,3 total, 1070,3 free, 1733,5 used, 5356,0 buff/cache MiB Swap: 0,0 total, 0,0 free, 0,0 used. 6318,8 avail Mem PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 156 iobroker 20 0 9681504 328176 48640 S 5,0 4,0 81:55.04 io.domiqbase.0 123 iobroker 20 0 9622304 259264 47616 S 1,0 3,1 24:11.16 iobroker.js-con 1 root 20 0 7408 2560 2560 S 0,0 0,0 0:00.03 bash 145 iobroker 20 0 9564016 206960 48640 S 0,0 2,5 2:04.36 iobroker.js-con 59769 root 20 0 7728 3584 3072 S 0,0 0,0 0:00.01 bash 59790 root 20 0 12160 4608 2560 R 0,0 0,1 0:00.00 topIch kann mir nicht vorstellen, dass dieses Backup den gesamten Speicher braucht.
compressed uncompressed ratio uncompressed_name 3634190 11686912 68.9% iobroker_2025_01_10-02_40_10_backupiobroker.tar -
@claus Ich höre erstmals von diesem Compact Mode. Wieso nutzt Du den noch unter den doch deutlich besseren Bedingungen?
Falls man leicht umschalten kann, würde ich den Compact Mode zumindest mal zur Diagnose abschalten. Ohne könnte es leichter sein, den Schuldigen zu finden.
An das Forum: Nutzt den Compact Mode sonst jemand?
-
@martinp
Der Compact Mode ist (war) für schwachbrüstige Hardware, wie z.B. den oben erwähnten PI2 gedacht. Unter aktuellen Hardware Voraussetzungen eigentlich nicht mehr sinnvoll.Ebenso unsinnig ist es aber auch, bei Verwendung von aktueller Hardware diese so künstlich zu beschneiden:
@claus sagte in Memory Leak:
Ich habe das jetzt auf ein PI5 umgezogen und dort 2GB RAM zugewiesen.
Klingt so als würde dort nicht nur ioBroker drauf laufen. Den PI5 hättest Du Dir auch sparen können, wenn Du dann wieder bei 2GB Speicher kastrierst.
-
@martinp sagte in Memory Leak:
Falls man leicht umschalten kann, würde ich den Compact Mode zumindest mal zur Diagnose abschalten. Ohne könnte es leichter sein, den Schuldigen zu finden.
Ich hatte ihn abgeschaltet, schon immer. Der ist nur zu Testzwecken aktiviert. Aber natürlich kann ich ihn auch wieder deaktivieren.
@Samson71 sagte in Memory Leak:
Klingt so als würde dort nicht nur ioBroker drauf laufen. Den PI5 hättest Du Dir auch sparen können, wenn Du dann wieder bei 2GB Speicher kastrierst.
Das ist ein Kubernetes Cluster, auf welchem unter anderem auch ioBroker läuft. Und ja, da laufen einige Container. Natürlich kann ich ioBroker auch 3GB zuweisen, allerdings lief es ja bis jetzt auch mit 1GB, allerdings mit Swap, Kubernetes hat keinen Swap. Ich versuche derzeit nur herauszufinden, warum ioBroker einige Tage ohne Probleme mit niedriger RAM Auslastung läuft und zu einem späteren Zeitpunkt auf einmal an Grenzen stößt.
top - 19:43:42 up 25 days, 4:22, 0 user, load average: 0,10, 0,21, 0,25 Tasks: 14 total, 1 running, 13 sleeping, 0 stopped, 0 zombie %Cpu(s): 3,2 us, 0,4 sy, 0,0 ni, 96,4 id, 0,0 wa, 0,0 hi, 0,0 si, 0,0 st MiB Mem : 8052,3 total, 934,1 free, 1807,9 used, 5417,8 buff/cache MiB Swap: 0,0 total, 0,0 free, 0,0 used. 6244,4 avail Mem PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 298 iobroker 20 0 9432736 79008 42496 S 7,0 1,0 0:22.20 io.simple-api.0 132 iobroker 20 0 9461520 242496 47616 S 1,7 2,9 0:22.08 iobroker.js-con 154 iobroker 20 0 9511632 143840 47104 S 0,7 1,7 0:04.60 io.admin.0 199 iobroker 20 0 9365168 79696 47104 S 0,3 1,0 0:05.74 io.comfoair.0 225 iobroker 20 0 9473088 119312 41984 S 0,3 1,4 0:07.23 io.zigbee.0 1 root 20 0 7408 2560 2560 S 0,0 0,0 0:00.02 bash 50 root 20 0 7568 3584 3072 S 0,0 0,0 0:00.00 bash 80 root 20 0 12160 4608 2560 R 0,0 0,1 0:00.14 top 161 iobroker 20 0 9329184 154176 41472 S 0,0 1,9 0:05.55 io.javascript.0 192 iobroker 20 0 9232672 77216 46592 S 0,0 0,9 0:02.08 io.backitup.0 210 iobroker 20 0 9430656 78976 42496 S 0,0 1,0 0:03.27 io.fronius.0 248 iobroker 20 0 9229984 70448 41472 S 0,0 0,9 0:01.77 io.discovery.0 259 iobroker 20 0 9427056 71088 41472 S 0,0 0,9 0:03.28 io.domiqbase.0 309 iobroker 20 0 9230320 70384 41472 S 0,0 0,9 0:01.54 io.simple-api.1 -
Ich würde den mem wert von io.javascript über die zeit mal beobachten.
-
@oliverio sagte in Memory Leak:
Ich würde den mem wert von io.javascript über die zeit mal beobachten.
Der Adapter ist zwar aktiv, aber es laufen keine Scripte.
-
@claus und trotzdem steigt der Speicher?
Die Vorgänger haben schon recht. Linux holts sich prophylaktisch schon mal Speicher das der schneller den Applikationen Zugewiesen werden können. Das passiert aber meiner Meinung nach über 3 Tage, wenn ansonsten immer gleicher Speicher verwendet wird.Dann mal die anderen Adapter/prozesse auf Speicher überwachen.
Irgendwo muss das doch zuordenbar sein. -
@claus
Wenn keine Skripte laufen kannst du den Adapter auch mal disablen - und abwarten.Beobacht auch mal den anscheinend von GitHub installierten domiqbase. Hab mal kurz rein gesehen und der onStateChange Bereich ist auf den ersten Blick nicht sicher zu sagen ob da nicht eine zyklische Selbstaktivierung auftreten kann. Könnte ev. den js-controller in die Knie zwingen. Zumindest bei einem schnellen Blich seh ich kein ack==false handling dafür aber ein setState in Verbindung mit einem setState im onStateChange Handler. Aber wie gesagt war nur ein extrem kurzer Blick - kann durchaus auch OK sein.
-
@mcm1957 sagte in Memory Leak:
Beobacht auch mal den anscheinend von GitHub installierten domiqbase.
Den Adapter habe ich geschrieben, da aber das Interesse nicht besonders groß war, warte ich es auch nicht besonders. Ich hatte mal gefragt, ob es ins Repo aufgenommen wird, aber offensichtlich gibt es keine potentiellen Nutzer und somit war das dann auch schnell vom Tisch.
-
OK, dann bist du ja die beste Quelle für 'nen Check. Wenn ich es beim drüberschaun richtig gesehen habe, dann subscribed der Adapter alle states - auch die eigenen. Das ist an sich OK. Er scheint nur nicht auf ack==false bei eigenen States zu filtern. Und er scheint innerhalb der onStateChange ein setState zu machen. Dieses triggert dann wieder den onStateChange ... Und das könnte zu einer Loop führen deren Timing sich durchaus mit anderen js-controlelr Versionen geändert haben könnten.
Wie gesagt alles sehr sehr wage und nur auf Grund eines kurzen Blicks in den Code. Kann gut sein, dass eh alles OK ist. Sie es nur als Anregung dort zu checken falls der Memoryanstieg beim js-controller auftritt.
-
@mcm1957 sagte in Memory Leak:
Er scheint nur nicht auf ack==false bei eigenen States zu filtern.
Danke für den Hinweis. Ich habe mir lange überlegt, wie ich das Problem lösen könnte und war leider nicht erfolgreich. Der Adapter führt einen Sync zwischen den States und dem Domiq Base durch. D.h. er schiebt State Änderungen zum Base und wenn sich im Base etwas ändert, dann aktualisiert er das auch in ioBroker. Eine Filterung passiert mittels Regex, welche man konfigurieren kann. Das hat bislang funktioniert, d.h. es lief relativ lange auf dem PI2 mit wenig Ram. Ich behalte den Adapter aber im Auge und aktualisiere ihn vielleicht auch mal.
-
@claus
Eigene Updates durch den eigenen Adapter kannst du durch den Originator des State Changes feststellen (wie das Feld genau heißt weiß ich im Moment nicht, kanns aber bei Bedarf suchen gehen) und damit Selbsttriggerungen verwerfen - falls es das mitspielen sollte. Ansonsten würd ich auch zunächst mal nichts ändern bis das Problem mehr eingegrenzt ist und überhaupt ein Verdacht existiert dass der Adapter beteiligt sein könnte. -
