Memory Leak
-
Seit einiger Zeit frisst ioBroker den Speicher weg. Es lief in einer älteren Version sehr lange problemlos auf einem PI2, danach PI3, nicht sehr schnell, aber es ging. Ein Update führte dann dazu, dass nach 1-2 Tagen der RAM aufgebraucht war. Der Anstieg erfolgte allerdings nicht stetig, sondern recht plötzlich. Ich habe das jetzt auf ein PI5 umgezogen und dort 2GB RAM zugewiesen. Läuft länger, aber irgendwann passiert wieder das Gleiche. Ich habe den letzten hinzugefügten Adapter (ESPHome) mal deaktiviert, glaube aber nicht, dass er es war.
Ich habe auch noch auf compact mode umgestellt, im Normalbetrieb läuft ioBroker mit 600MB Ram.
-
@claus sagte in Memory Leak:
im Normalbetrieb läuft ioBroker mit 600MB Ram.
Was läuft denn da? 600 ist sehr wenig
@claus sagte in Memory Leak:
auf ein PI5 umgezogen und dort 2GB RAM zugewiesen
Weshalb?
Was läuft sonst noch?Ansonsten die Ausgabe von
iob diagZeigen
-
Meist liegt das nicht am iobroker selbst.
Meist ist es ein Javascript mit nicht richtig verwendeten triggern.
Das wirkt sich, je nachdem wie oft die trigger aufgerufen werden nicht sofort aus, sondern kann sich auch über Tage hinziehen.
Also am besten in die Skripte reinschauen, die Trigger verwenden und öfters aktiviert werden. -
@crunchip sagte in Memory Leak:
Was läuft denn da? 600 ist sehr wenig
Adapter State + system.adapter.admin.0 : admin : iobroker-0 - enabled, compact enabled (group 2), port: 8081, bind: 0.0.0.0 (SSL), run as: admin + system.adapter.backitup.0 : backitup : iobroker-0 - enabled, compact enabled (group 1) + system.adapter.comfoair.0 : comfoair : iobroker-0 - enabled, compact enabled (group 1), port: 8899 + system.adapter.discovery.0 : discovery : iobroker-0 - enabled, compact enabled (group 1) + system.adapter.domiqbase.0 : domiqbase : iobroker-0 - enabled, compact enabled (group 1), port: 4224 system.adapter.dwd.0 : dwd : iobroker-0 - enabled, compact disabled system.adapter.esphome.0 : esphome : iobroker-0 - disabled, compact enabled (group 1) + system.adapter.fronius.0 : fronius : iobroker-0 - enabled, compact enabled (group 1) + system.adapter.javascript.0 : javascript : iobroker-0 - enabled, compact enabled (group 1) + system.adapter.simple-api.0 : simple-api : iobroker-0 - enabled, compact enabled (group 1), port: 8087, bind: 0.0.0.0 (SSL), run as: admin + system.adapter.simple-api.1 : simple-api : iobroker-0 - enabled, compact enabled (group 1), port: 8089, bind: 0.0.0.0, run as: admin + system.adapter.zigbee.0 : zigbee : iobroker-0 - enabled, compact enabled (group 1), port: /dev/ttyACM0 + instance is alive Enabled adapters with bindings + system.adapter.admin.0 : admin : iobroker-0 - enabled, compact enabled (group 2), port: 8081, bind: 0.0.0.0 (SSL), run as: admin + system.adapter.comfoair.0 : comfoair : iobroker-0 - enabled, compact enabled (group 1), port: 8899 + system.adapter.domiqbase.0 : domiqbase : iobroker-0 - enabled, compact enabled (group 1), port: 4224 + system.adapter.simple-api.0 : simple-api : iobroker-0 - enabled, compact enabled (group 1), port: 8087, bind: 0.0.0.0 (SSL), run as: admin + system.adapter.simple-api.1 : simple-api : iobroker-0 - enabled, compact enabled (group 1), port: 8089, bind: 0.0.0.0, run as: admin + system.adapter.zigbee.0 : zigbee : iobroker-0 - enabled, compact enabled (group 1), port: /dev/ttyACM0Weshalb?
Was läuft sonst noch?Noch einige Dinge, die nichts mit ioBroker zu tun haben. Aber wie schon erwähnt, es lief über einen sehr langen Zeitraum mit 1GB Ram ohne jegliche Probleme.
Zeigen
iob fix habe ich laufen lassen. Es gibt da Berechtigungsprobleme mit temp Dateien, die allerdings nicht gefixt werden.
======================= SUMMARY ======================= v.2024-10-19 Model : Raspberry Pi 5 Model B Rev 1.1 Kernel : aarch64 Userland : arm64 Docker : v10.0.0 Installation: Docker Kernel: aarch64 Userland: 64 bit Timezone: CET +0100 User-ID: 0 Display-Server: false Pending OS-Updates: 0 Pending iob updates: 3 Nodejs-Installation: /usr/bin/nodejs v20.18.1 /usr/bin/node v20.18.1 /usr/bin/npm 10.8.2 /usr/bin/npx 10.8.2 /usr/bin/corepack 0.29.4 Recommended versions are nodejs 20.18.1 and npm 10.8.2 nodeJS installation is correct MEMORY: total used free shared buff/cache available Mem: 8.4G 1.7G 1.1G 11M 5.7G 6.8G Swap: 0B 0B 0B Total: 8.4G 1.7G 1.1G Active iob-Instances: 11 Upgrade policy: none ioBroker Core: js-controller 7.0.6 admin 7.1.5 ioBroker Status: iobroker is running on this host. Objects type: jsonl States type: jsonl Status admin and web instance: + system.adapter.admin.0 : admin : iobroker-0 - enabled, compact enabled (group 2), port: 8081, bind: 0.0.0.0 (SSL), run as: admin Objects: 1381 States: 1203 Size of iob-Database: 12M /opt/iobroker/iobroker-data/objects.jsonl 1.5M /opt/iobroker/iobroker-data/states.jsonl ********************************************************************** Some problems detected, please run iob fix and try to have them fixed ********************************************************************** Unknown release codenamed ''. Please check yourself if the Operating System is actively maintained. =================== END OF SUMMARY ==================== -
@claus sagte in Memory Leak:
Ein Update führte dann dazu, dass nach 1-2 Tagen der RAM aufgebraucht war.
@claus sagte in Memory Leak:
es lief über einen sehr langen Zeitraum mit 1GB Ram ohne jegliche Probleme.
mit alten Versionsständen?
von welchem Update ist denn die Rede?
mit nem aktuellen OS und aktuellen Iobrokerversionen wird es generell mit nur 1GB Ram sehr sehr eng -
@crunchip sagte in Memory Leak:
mit alten Versionsständen?
von welchem Update ist denn die Rede?
mit nem aktuellen OS und aktuellen Iobrokerversionen wird es generell mit nur 1GB Ram sehr sehr engJa, die Version war etwas älter. Ich habe dann alle Updates nachgeholt. Mir wurde dann schon klar, dass mein PI2 dafür bei weitem nicht mehr ausreichend war, deshalb habe ich ja auf ein PI5 migriert. Über weite Strecken ist der Ram Verbrauch sehr stabil bei 600MB, dann kommt ein Zeitpunkt, wo auf einmal die 2GB erreicht werden.
600MB erreiche ich durch den Compact Mode, kann man mögen oder nicht, war aber ein Versuch, das Problem in den Griff zu bekommen.
-
@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.
