JS-Adapter startet ständig neu: heap out of memory

[smhrambo]

@homoran Auf welche Daten greift der JS Adapter aber zu, dass er so RAM benötigt.
Kein anderer Adapter scheint diese Daten zu benötigen oder der JS Adapter interpretiert die Daten falsch.
Ich habe eine Idee, dehalb meine Frage wie ich die Objekte von bestimmten Daten befreien kann.

Ich habe versucht eine Art semantisches Modell meines Hauses zu erzeugen.

Den JS Adapter habe ich die letzten Monate nicht benutzt,
weil ich die Hardware für die ich die Skripte brauche reparieren musste.
Nun ist Weihnachten und der JS Adapter soll mein Weihnachtsprogramm laufen lassen und nun läuft er nicht mehr.
Also habe ich inzwischen den Verdacht, dass es an der Zuordnung in der ioBroker Aufzählungen liegen könnte.

Ganz wilde Theorie:
Vielleicht gibt es durch die Zuordnung eine Schleife, da ich mit Stockwerken und Räumen gearbeitet habe.

[Homoran]

@smhrambo sagte in JS-Adapter startet ständig neu: heap out of memory:

Auf welche Daten greift der JS Adapter aber zu, dass er so RAM benötigt.

Ich kann vollkommen daneben liegen, aber ih denke hier liegt dein Denkfehler.
Wer sagt dir dass der Adapter so viel RAM benötigt, wenn der js HEAP für alle javascript Aktionen (auch im Grundsystem) gilt?

[smhrambo]

@homoran Kannst du mir deinen Gedankengang näher erläutern.

Also wenn ich den JS Adapter aktiviere, startet dieser nach ein paar Sekunden neu und im Log stehen die oben genannten Fehlermeldungen.
Die Log Meldungen wiederholt sich bei jedem Absturz und Neustart vom JS Adapter.
Dementsprechend habe ich für die Fehlermeldung den JS Adapter im Verdacht.
Ist der JS Adapter deaktiviert, kommt die Fehlermeldung nicht.

[Marc Berg]

@ro75 sagte in JS-Adapter startet ständig neu: heap out of memory:

Aus meiner Sicht:

wenn du weiterhin mit Docker arbeiten willst/musst dann brauchst du mehr RAM

Die 3 Punkte unter dem Gesichtspunkt, dass du mit Docker arbeiten willst. Alternativ verzichte auf Docker (zumindest ohne ioBroker, nur für andere Projekte).

Wenn der RAM knapp wird, hilft natürlich jeden Megabyte mehr. Trotzdem glaube ich, dass der Overhead durch Docker überschätzt wird.
Habe das gerade mal auf einer VM nachgestellt

1. ioBroker nativ installiert
2. ioBroker unter Docker installiert

Jeweils mit identischer Installation (frisch aufgesetzt mit Admin+Backitup Adapter) ergibt sich ein Unterschied von ca. 75 MB.

nativ

unter Docker

[OliverIO]

@smhrambo

Ich weiß es zwar nicht genau, aber der hohe speicherverbrauch beim Start ist nicht der Iobroker selbst sondern der jit Compiler der v8 Maschine.

Hat eigentlich mal jemand probiert Iobroker mit deno oder bun zu starten?

[smhrambo]

@marc-berg Deshalb glaube ich auch nicht das es an Docker liegt.
Besonders schon deswegen, das es nur beim einspielen des Backups auftritt.

Ich versuche so viel Strom wie möglich zu sparen und das System lief 3 Jahre ohne Probleme.
Beim Verbrauch ist ein Pi sehr optimal, besonders dann wenn man so wie ich über GPIO einiges an Zusatzmodulen dran hat.

Ich Betreibe mehrere Server die aber nur nach Bedarf aktiv werden.
Meine NAS (Synology), die infrage kommen würde, ist leider in ihrere Konfiguration und IO sehr eingeschränkt(Es sind keine VLANs mit VM Betrieb möglich).
Ich betreibe hier ein Netzwerk im ZeroTrust Verfahren mit 13 Subnetzen und VLANs. Aufgrund der eingesetzten Software kommt für mich nur MACVLAN per Docker infrage.
Es gibt leider Software, auch im IoT und Smarthome Bereich, die eine Änderung der Ports oder der IP nicht zulassen(Raspberrymatic, diyhue, ...). Um diese auf dem selben Host laufen zu lassen müssen diese entweder in einer VM laufen (absoluter overkill) oder eben in einem Container mit MACVLAN.
Zudem ist mein Pi komplett Autark, es ist für die Bereitstellung von WLAN, DHCP usw. im IoT Subnetz verantwortlich und hat seine eigene Stromversorgung gegen Netzausfall.
Das kann so Tage weiter operieren.
Bei einer NAS die 100W zieht, ist das nicht so einfach möglich.

[smhrambo]

@oliverio
Da bin ich leider raus, JS ist nicht meine Stärke.
Was ist bun bzw. deno und wie startet man ioBroker damit.

[OliverIO]

@smhrambo
Alternativen für Node
Deno wurde vom ursprünglichen Erfinder von Node gestartet.

[smhrambo]

@oliverio Ich glaube daraus wird leider nichts, da deno aktuell nur für Mac als arm64 vorliegt.
Ich müsste es erst für das Pi kompilieren.

[OliverIO]

@smhrambo

Sorry ich dachte du meinst es liegt nur für mac vor.

Ja für raspi muss man es wohl kompilieren. Geht aber wohl
Aber keine Ahnung ob das für Iobroker überhaupt geht.
Diese Maschinen haben wohl Performance Vorteile.
Evt nutzt Iobroker aber spezifisches von Node.
Daher hochexperimentiell

[smhrambo]

So ich konnte das Problem eingrenzen.
Ich habe den funktionierenden JS Adapter in silly loggen lassen.
Dabei ist mir aufgefallen, das der JS Adapter beim Start alle Objekte und alle State anfordert.

So wie es aussieht, werden dabei für jedes Objekt eine Art Callback erzeugt.
Beim loggen des JS Adapters ist mir aufgefallen, das dieser auf absolute jede Änderung in den Objekten reagiert, nicht nur für die die man in seinen Skripts benutzt.

Keine Ahnung ob das geht, aber ich würde den JS Adapter eher dazu bringen, bei Skripten mit on(["..."], function (data) {..." nur für nötigen Objekte einen Callback anlegen zu lassen.

Ich habe mir den Quellcode noch nicht angeguckt.

Beim Vergleich der Objekt Datenbanken von der Installation die funktioniert und die die nicht funktioniert ist mir aufgefallen, dass die die nicht funktioniert mehr als doppelt so viele Objekte besitzt und fast 3 mal so viele States hat.

Im meinem MQTT Adapter waren ca. 6000 Objekte drin.
Nach dem Löschen der Objekte, läuft der JS Adapter ohne Probleme.

Stellt sich immernoch die Frage wie es dazu gekommen ist.

[OliverIO]

@smhrambo
Da gibt es in den Einstellungen was damit der js Adapter nicht alle Datenpunkte abonniert

[smhrambo]

@oliverio Lol, danke.

Ich werde jetzt spaßeshalber noch mal das Backup einspielen, die Option aktivieren und gucken.

[ticaki]

@oliverio sagte in JS-Adapter startet ständig neu: heap out of memory:

@smhrambo
Da gibt es in den Einstellungen was damit der js Adapter nicht alle Datenpunkte abonniert

In dem fall mußt du aber die getStateAsync versionen verwenden oder mit callback arbeiten und die Aufrufe dürfen mehr Zeit/Rechpower brauchen.

[smhrambo]

Leider hat es nicht geholfen diese Einstellung im JS Adapter zu aktivieren.
Aber ich konnte das MQTT Topic ausmachen, welches diesen Fehler verursacht hat.
Es war der homeassistant Topic für die Bekanntmachung von Geräten usw.
Nachdem der gelöscht war, lief das System ohne Probleme.

Für mich ist das Thema damit eigentlich erstmal durch.
Ich werde die Sache auf jeden Fall beobachten,
wobei sich bei mir folgende Fragen stellen:

1. Warum steigt der homeasstant Topic auf über 3000 Objekte an.
   Es könnte sich um folgende Probleme handeln:
   • MQTT Adapter entfernt die Objekte nicht richtig, nachdem diese vom Broker gelöscht wurden (ich setze rabbitMQ ein und habe vor kurzem alles gelöscht gehabt)
   • ioBroker Objektsystem (unwahrscheinlich)
   • Implementierung von einem MQTT Client(ems-esp, esphome, valetudo, zigbee2mqtt)
2. "Warum"(Wenn kein RAM, dann kein RAM) reagiert das JS System von ioBroker so darauf, wenn der JS Adapter gestartet wird und gibt es Möglichkeiten dies zu verhindern bzw. abzudämpfen.

Das ganze passier auf jeden Fall zwischen diesen Aktionen vom JS Adapter:
requesting all states
requesting all objects
received all states
----UND----
received all objects

[Marc Berg]

@smhrambo sagte in JS-Adapter startet ständig neu: heap out of memory:

Warum steigt der homeasstant Topic auf über 3000 Objekte an.

das musst du wohl HA fragen

MQTT Adapter entfernt die Objekte nicht richtig, nachdem diese vom Broker gelöscht wurden (ich setze rabbitMQ ein und habe vor kurzem alles gelöscht gehabt)

So funktioniert das nicht, es gibt unter MQTT kein Löschen von Topics.

[paul53]

@smhrambo sagte: Das ganze passier auf jeden Fall zwischen diesen Aktionen vom JS Adapter:

requesting all states
requesting all objects
received all states
----UND----
received all objects

Das ist erforderlich, da der JS-Adapter alle Objekte und Zustände puffert, um die synchronen Versionen von z.B. getState(id) und getObject(id) zu ermöglichen.

[smhrambo]

@paul53 Das ist mir klar.
Dies wird gebraucht wenn man dynamisch auf die Objekte zugreifen will.
Zum Beispiel wenn man bestimmte Objekte sucht und diese vorher nicht kennt und den State von Objekten zum selben Zeitpunkt braucht.
Wenn man vorher weiss auf welche Objekte zugreift und wenn man diese Objekte vorher angeben kann, wäre dies nicht notwenig(wie bei meinen kleinen Skript aus dem ersten Post), da man die Objekte die benötigt werden zum Kompilerzeitpunkt vormerkt und beim Start addressieren könnte.

Hier habe sich die Programmierer eben dafür entscheiden alle Fälle über diesen Weg abzudecken. Ist bei mir nun eben ein Speziallfall, es gibt nicht die perfekte Software, die jeden Fall abdecken kann. Es gibt bestimmt work arounds, aber solange es läuft habe ich damit kein Problem, ich muss es eben beobachten. Es lief ja 3 Jahre ohne Probleme.

Ich habe inzwischen Frameworks gesehen die das anders lösen,
diese sind aber eben nicht für ein Smarthomesystem gewesen.
Compilerbau lässt grüßen.

[smhrambo]

@marc-berg HA ist in diesem Fall eher ein Smarthome Standard, auf den viele Smarthomegeräte inzwischen zurückgreifen um ihre Fähigkeiten bekann zu geben(z.B. Z2MQTT usw.). Selber betreibe ich keine HA Instanz bei mir. Wenn die Clients ihre Struktur änder wie es z.B. bei ems-esp geschehen ist, kann es passieren, dass dort Definitionen zurück bleiben, die es so aber gar nicht mehr gibt (Retained Messages!!!).

Zudem:

RabbitMQ und Mosquitto können so eingestellt werden, das sie Topics und Informationen vorhalten solange ein Client nicht online ist(cleansession = false).
Durch Updates und andere Änderungen ist es bei mir schon mal vorgekommen,
dass der Broker die Daten beibehält obwohl sich der Client wieder eingeloggt hat.

Dann musste ich manuell im Broker die Daten löschen (Topics löschen).

Manchen Brokern konnte man sogar dazu animieren, diese Daten für alle anzuzeigen.
Ist manchmal ganz praktisch, wenn das Netzwerk etwas unbeständig ist und man den Verlauf braucht.

Ich benutze rabbitMQ in der Beta für MQTT 5 und bin vor kurzem von Mosquitto umgestiegen.
Ich brauchte für die Verwaltung ein UI, da jetzt immer mehr Geräte dazu kommen.

Kurz um ich nenne das Löschen von Retained Messages und Message persistence -> Topics löschen.

[Marc Berg]

@smhrambo sagte in JS-Adapter startet ständig neu: heap out of memory:

Kurz um ich nenne das Löschen von Retained Messages und Message persistence -> Topics löschen.

Und du erwartest jetzt, dass der MQTT Adapter Objekte entfernt, wenn du die Retained Messages in deinem Broker löschst?
Und was hat das mit „clean session“ zu tun?