NEWS
JS-Controller ca. alle 12h out of memory Error
-
Hallo zusammen,
Ich hab seit kurzem ein Problem mit meinem ioBroker und benötige evtl. einen Tipp zur Fehlersuche.
Seit ca 2 Wochen stürzt der ioBroker fast regelmäßig alle 12h ab - mal nach 11h, mal nach 13h, auch nie auf die Minute gleich. Aber häufig nach diesem Muster.
Ausnahmen bestätigen natürlich die Regel, manchmal auch wesentlich früher/später, manchmal auf zwei mal kurz hintereinander.Da ich nicht allzuviel dran neu gemacht habe, habe ich auch schon alle Blocklyscripts deaktiviert die in letzter Zeit neu dazu kamen. Viele warens jedoch nicht, 3 Stück.
Trotzdem stürzt der ioBroker ab.Im Raspberry Log gibt es nur diesen Eintrag:
Sep 23 14:04:53 raspberrypi kernel: Out of memory: Killed process 1589480 u(iobroker.js-con) total-vm:10233820kB, anon-rss:818560k> Sep 23 14:04:54 raspberrypi systemd[1]: iobroker.service: Main process exited, code=killed, status=9/KILLWoher dieses out of memory kommt würde ich gerne versuchen zu ermitteln, weiß aber nicht wie ich das am besten anstelle.
Gibt es eine Möglichkeit zu ermitteln was im ioBroker vor so einem Crash passiert?Im Logfile von ioBroker lässt sich nichts zu einem Error in einem Blocklyscript oder ähnliches feststellen. ERROR: DB closed oder ähnliches was wohl auf den vollen Speicher zurückzuführen ist.
Den Befehl „iob fix“ hab ich ebenfalls schon ausgeführt, ändert aber nichts am Verhalten.
Mein System:
Raspberry Pi4b mit 4GB RAM
Raspberry OS Bookwork
Alle Adapter aktuell
Node.JS 20.17.0
JS-Controller 6.0.11
Neue externe SSD als HarddriveAnbei noch die Summary aus der ioBroker Diagnose:
======================= SUMMARY ======================= v.2024-05-22 Static hostname: raspberrypi Icon name: computer Operating System: Debian GNU/Linux 12 (bookworm) Kernel: Linux 6.6.31+rpt-rpi-v8 Architecture: arm64 Installation: native Kernel: aarch64 Userland: 64 bit Timezone: Europe/Berlin (CEST, +0200) User-ID: 1000 Display-Server: false Boot Target: multi-user.target Pending OS-Updates: 0 Pending iob updates: 0 Nodejs-Installation: /usr/bin/nodejs v20.17.0 /usr/bin/node v20.17.0 /usr/bin/npm 10.8.2 /usr/bin/npx 10.8.2 /usr/bin/corepack 0.29.3 Recommended versions are nodejs 20.17.0 and npm 10.8.2 Your nodejs installation is correct MEMORY: total used free shared buff/cache available Mem: 4.0G 2.8G 252M 1.3M 397M 1.1G Swap: 0B 0B 0B Total: 4.0G 2.8G 252M Active iob-Instances: 34 Upgrade policy: none ioBroker Core: js-controller 6.0.11 admin 7.1.3 ioBroker Status: iobroker is running on this host. Objects type: jsonl States type: jsonl Status admin and web instance: + system.adapter.admin.0 : admin : raspberrypi - enabled, port: 8081, bind: 0.0.0.0, run as: admin + system.adapter.web.0 : web : raspberrypi - enabled, port: 8082, bind: 0.0.0.0, run as: admin Objects: 15858 States: 12984 Size of iob-Database: 38M /opt/iobroker/iobroker-data/objects.jsonl 37M /opt/iobroker/iobroker-data/states.jsonl =================== END OF SUMMARY ====================Hat jemand einen Tipp wie man feststellen kann warum der Speicher halbwegs regelmäßig voll läuft?
evtl liegt es an einem memory leak in einem deiner skripte.
das ist allerdings nicht leicht zu finden.
gern passiert das im javascript mit setinterval/settimeout, die nicht ordentlich beednet wurden.ist zwar auf den browser bezogen, es gelten aber die selben regeln
https://auth0.com/blog/four-types-of-leaks-in-your-javascript-code-and-how-to-get-rid-of-them/ -
Hmm.. glaube nicht, dass das Stunden:Minuten:Sekunden sind.
Der mittlere Wert erhöht sich alle 10 Sekunden rum um 1.Also ich logge jetzt mal den Speicherbedarf heute Nacht mit den jeweiligen PIDs mit solange bis ein Absturz kommt.
Dann poste ich das Ergebnis nochmal welche PID mit welcher Speicherauslastung zuletzt lief und welche vom System gekillt wurde.Fakt ist, wenn ein Absturz kommt ist ioBroker kurze Zeit lang nicht erreichbar und alle Adapter starten neu.
@tobi-1 said in JS-Controller ca. alle 12h out of memory Error:
Also ich logge jetzt mal den Speicherbedarf
unter system.
gibt es im iobroker reichlich datenpunkte um speicher je maschine und auch je adapter mit dem history adapter aufzuzeichnen -
@tobi-1 said in JS-Controller ca. alle 12h out of memory Error:
Also ich logge jetzt mal den Speicherbedarf
unter system.
gibt es im iobroker reichlich datenpunkte um speicher je maschine und auch je adapter mit dem history adapter aufzuzeichnenIch hab mir ein kleines python script dazu geschrieben um losgelöst vom ioBroker zu sein.
ich verwende tatsächlich in manchen Scripts setinterval, jedoch nicht erst seit kurzem.
Und die letzten Monate wenn nicht sogar schon Jahre gabs da nie Probleme… das verwundert mich etwas. -
Ich hab mir ein kleines python script dazu geschrieben um losgelöst vom ioBroker zu sein.
ich verwende tatsächlich in manchen Scripts setinterval, jedoch nicht erst seit kurzem.
Und die letzten Monate wenn nicht sogar schon Jahre gabs da nie Probleme… das verwundert mich etwas.wenn speicherverbrauch ansteigend ist, aber du nicht immer mehr daten in irgendwelchen objektstrukturen speicherst, dann ist es ein memory leak
dann hat bisher der speicher immer noch gereicht oder du hast es aus anderen gründen nicht wahr genommen.
wenn es ein generelles problem wäre, dann würden hier ganz viele schreiben. -
wenn speicherverbrauch ansteigend ist, aber du nicht immer mehr daten in irgendwelchen objektstrukturen speicherst, dann ist es ein memory leak
dann hat bisher der speicher immer noch gereicht oder du hast es aus anderen gründen nicht wahr genommen.
wenn es ein generelles problem wäre, dann würden hier ganz viele schreiben.Ich gehe davon aus, dass es kein generelles Thema ist.
Aber ich hab auch keine Idee wie man das Problem finden kann.
Werde mir deinen Link oben noch anschauen und alle meine Scripte die einen Intervall drin haben mal deaktivieren und schauen ob es immernoch passiert.Hatte die Hoffnung jemand kennt noch einen Kniff in ioBroker um das zu diagnostizieren
-
jetzt nicht falsch verstehen, sind aber nicht 34 aktive Instanzen für 4GB RAM mehr als sportlich?
-
jetzt nicht falsch verstehen, sind aber nicht 34 aktive Instanzen für 4GB RAM mehr als sportlich?
@saeft_2003 seh ich auch so, wobei es auch auf die jeweiligen Adapter ankommt.
Laut screen werden aber schon rund 800MB allein durch Controller und Javascript belegt. -
Hallo zusammen,
Ich hab seit kurzem ein Problem mit meinem ioBroker und benötige evtl. einen Tipp zur Fehlersuche.
Seit ca 2 Wochen stürzt der ioBroker fast regelmäßig alle 12h ab - mal nach 11h, mal nach 13h, auch nie auf die Minute gleich. Aber häufig nach diesem Muster.
Ausnahmen bestätigen natürlich die Regel, manchmal auch wesentlich früher/später, manchmal auf zwei mal kurz hintereinander.Da ich nicht allzuviel dran neu gemacht habe, habe ich auch schon alle Blocklyscripts deaktiviert die in letzter Zeit neu dazu kamen. Viele warens jedoch nicht, 3 Stück.
Trotzdem stürzt der ioBroker ab.Im Raspberry Log gibt es nur diesen Eintrag:
Sep 23 14:04:53 raspberrypi kernel: Out of memory: Killed process 1589480 u(iobroker.js-con) total-vm:10233820kB, anon-rss:818560k> Sep 23 14:04:54 raspberrypi systemd[1]: iobroker.service: Main process exited, code=killed, status=9/KILLWoher dieses out of memory kommt würde ich gerne versuchen zu ermitteln, weiß aber nicht wie ich das am besten anstelle.
Gibt es eine Möglichkeit zu ermitteln was im ioBroker vor so einem Crash passiert?Im Logfile von ioBroker lässt sich nichts zu einem Error in einem Blocklyscript oder ähnliches feststellen. ERROR: DB closed oder ähnliches was wohl auf den vollen Speicher zurückzuführen ist.
Den Befehl „iob fix“ hab ich ebenfalls schon ausgeführt, ändert aber nichts am Verhalten.
Mein System:
Raspberry Pi4b mit 4GB RAM
Raspberry OS Bookwork
Alle Adapter aktuell
Node.JS 20.17.0
JS-Controller 6.0.11
Neue externe SSD als HarddriveAnbei noch die Summary aus der ioBroker Diagnose:
======================= SUMMARY ======================= v.2024-05-22 Static hostname: raspberrypi Icon name: computer Operating System: Debian GNU/Linux 12 (bookworm) Kernel: Linux 6.6.31+rpt-rpi-v8 Architecture: arm64 Installation: native Kernel: aarch64 Userland: 64 bit Timezone: Europe/Berlin (CEST, +0200) User-ID: 1000 Display-Server: false Boot Target: multi-user.target Pending OS-Updates: 0 Pending iob updates: 0 Nodejs-Installation: /usr/bin/nodejs v20.17.0 /usr/bin/node v20.17.0 /usr/bin/npm 10.8.2 /usr/bin/npx 10.8.2 /usr/bin/corepack 0.29.3 Recommended versions are nodejs 20.17.0 and npm 10.8.2 Your nodejs installation is correct MEMORY: total used free shared buff/cache available Mem: 4.0G 2.8G 252M 1.3M 397M 1.1G Swap: 0B 0B 0B Total: 4.0G 2.8G 252M Active iob-Instances: 34 Upgrade policy: none ioBroker Core: js-controller 6.0.11 admin 7.1.3 ioBroker Status: iobroker is running on this host. Objects type: jsonl States type: jsonl Status admin and web instance: + system.adapter.admin.0 : admin : raspberrypi - enabled, port: 8081, bind: 0.0.0.0, run as: admin + system.adapter.web.0 : web : raspberrypi - enabled, port: 8082, bind: 0.0.0.0, run as: admin Objects: 15858 States: 12984 Size of iob-Database: 38M /opt/iobroker/iobroker-data/objects.jsonl 37M /opt/iobroker/iobroker-data/states.jsonl =================== END OF SUMMARY ====================Hat jemand einen Tipp wie man feststellen kann warum der Speicher halbwegs regelmäßig voll läuft?
ich wuerde an deiner Stelle mal den javascript-Adapter stoppen, und die Kiste laufen lassen, wenn es dann stabil ist, liegts an einem Script.
Natuerlich ist 4GB auch nicht gerade viel und schnell ausgelastet, gerade bei 34 Instanzen, wenn du da noch eine VIS hast, ist schnell der Speicher voll.Hilft nur, der Reihe nach abschalten, beobachten.
-
Ja ich vermute fast auch, dass die 4GB RAM grenzwertig sind mittlerweile.
Habe das heute nacht mal mitgeloggt und auch mit dem Befehl sudo journalctl -xe nochmal geschaut.
Aber nichts auffälliges, der Speicherbedarf schwankt nicht sehr viel, aber wenn die großen Adapter gleichzeitig mehr benötigen wirds eng.Ein massiver Anstieg eines bestimmten Adapters konnte ich nicht sehen, trotzdem gabs dann wieder den „gewohnten“ Absturz heute Nacht.
Werde mal ein paar größere Scripte deaktivieren und schauen ob es dann besser wird.
Vermutlich wirds aber eher Zeit für einen 8GB RAM Pi. -
Ja ich vermute fast auch, dass die 4GB RAM grenzwertig sind mittlerweile.
Habe das heute nacht mal mitgeloggt und auch mit dem Befehl sudo journalctl -xe nochmal geschaut.
Aber nichts auffälliges, der Speicherbedarf schwankt nicht sehr viel, aber wenn die großen Adapter gleichzeitig mehr benötigen wirds eng.Ein massiver Anstieg eines bestimmten Adapters konnte ich nicht sehen, trotzdem gabs dann wieder den „gewohnten“ Absturz heute Nacht.
Werde mal ein paar größere Scripte deaktivieren und schauen ob es dann besser wird.
Vermutlich wirds aber eher Zeit für einen 8GB RAM Pi.@tobi-1 mach einfach mal SWAP größer. 100 MB ist zu wenig. Mach ruhig mal 2GB. Wenn wirklich vom System was gebraucht wird, sollte auch was da sein.
@tobi-1 sagte in JS-Controller ca. alle 12h out of memory Error:
Vermutlich wirds aber eher Zeit für einen 8GB RAM Pi.
Durchaus.
Ro75.
-
@tobi-1 mach einfach mal SWAP größer. 100 MB ist zu wenig. Mach ruhig mal 2GB. Wenn wirklich vom System was gebraucht wird, sollte auch was da sein.
@tobi-1 sagte in JS-Controller ca. alle 12h out of memory Error:
Vermutlich wirds aber eher Zeit für einen 8GB RAM Pi.
Durchaus.
Ro75.
-
@ro75 swap ist jetzt 2GB groß, schauen wir was passiert.
Danke für eure Hinweise und Unterstützung 🙂
bevor du einen neuen raspi kaufst, würde ich überlegen ob deine Installation noch weiter wachsen wird und ob noch so Sachen wie grafana, influxDB usw... dazu kommen könnten.
Falls ja würde ehr ein NUC mit proxmox Sinn ergeben, als ein raspi.
821
Online32.6k
Benutzer81.9k
Themen1.3m
Beiträge