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

[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?

[smhrambo]

@marc-berg said in JS-Adapter startet ständig neu: heap out of memory:

Und du erwartest jetzt, dass der MQTT Adapter Objekte entfernt, wenn du die Retained Messages in deinem Broker löschst?

Ja, Grundsätzlich bin ich davon ausgegangen, dass der MQTT Adapter Objekte von Nachrichten und die dazu gehörigen Topics löscht, wenn diese nicht mehr vorhanden sind (nur bei Retained Messages).
Bei allem anderen wäre das nicht wünschenswert, besonders wenn Clients offline gehen und man die Objekte für etwas benutzen will.

Vielleicht bin ich auch von anderen Systemen die ich kenne (nicht nur im Smarthome Bereich) etwas verwöhnt. In Systemen, in denen man die Topics selber definiert und kontrolliert, ist dies vielleicht noch eine einfache Sache, aber in dynamischen Systemen, die sich durch z.B. Software-Updates ständig erweitern oder ändern, ist das ein Muss, sonst hat man ganz schnell Probleme.

Ich habe während des Studiums mal an einem Telemetriesystem für Satelliten gearbeitet,
da war diese Sache ein Hauptbestandteil.
Wenn man sich als Client schon alles speichert, was auf dem Broker passiert, könnte man auch ab und zu über die Topics gehen und feststellen ob ein Topic was mit einer Retained Message versehen war weg gefallen ist. Grundsätzlich abonniere ich alles was da ist und arbeite dann mit Autodiscovery. Gezieltes Abonnieren ist mir zu aufwändig.

So habe ich das damals umgesetzt, das ist kein muss.
Vielleicht gibt es im MQTT Adapter die Möglichkeit bestimmte Topics vom Abonnieren auszuschließen, das würde ja schon helfen.

Und was hat das mit „clean session“ zu tun?

"Cleansession=false" ist nur die "Anmelde Option" die dem Broker mitteilt, das die Session über die Onlinephase hinaus aktiv bleibt und dass der Client alle Nachrichten von einem Topic gerne später nachgereicht haben möchte.
Hierbei handelt es sich um eine andere Art der Nachrichten/Topic Erhaltung.
Der Broker speichert alle Werte zwischen und sobald der wieder Client online kommt, werden ihm alle Werte die er während seiner "Offlinephase" verpasst hat zur Verfügung gestellt.
Hierbei werden auch Topic und Nachrichten zwischengespeichert die, wenn irgendetwas schief läuft vom Broker wieder gelöscht werden müssen.

Du hast mir ja unterstellt ich würde das MQTT-Protokoll nicht verstehen, obwohl ich damit schon eine Zeit lange arbeite (15+ Jahre). Deshalb wollte ich nur versuchen, dir klar zu machen, was ich mit meiner Aussage gemeint habe und dass man so gesehen schon Topics und ihre Nachricht vom Broker "löschen" kann bzw. auch muss.

Grundsätzlich verbleibt eine Nachricht nur solange auf dem Broker bis alle Clients die das Topic abonniert haben, diese empfangen haben. (Ausnahmen bestätigen die Regel siehe QoS, Retained Messages und persistent storage)

Ich finde es witzig, welche Richtung dieses Gespräch eingeschlagen hat und dass ich jemanden erklären muss, dass ich ein Protokoll schon verstanden habe, aber er anscheinend mit meiner Aussage ein Problem hat. Das hat einen gewissen Troll-Faktor. Nicht böse gemeint.

Aber eine einfache Antwort wie, "Leider bietet der MQTT Adapter so eine Funktion nicht an" hätte ausgereicht.

Versteh mich nicht falsch, ich mag ioBroker, aber ursprünglich komme ich aus der openHAB Ecke.
Ich habe riesige Automatisierungsskripte geschrieben,
die aber so ausgeartet sind, dass ich für meine Familie etwas Intuitiveres gesucht habe (Shuttercontrol ;-)).

Jede Software ist anders und setzt Sachen anders um.

Ich sehe die Vorteile vom Objektsystem in ioBroker, man muss diese nicht selber erstellen und hat alles schön in einem Baum. Andererseits kann dies aber recht Ressourcen schluckend sein.

Keine Software ist perfekt, meine eigene auch nicht.

Ich habe hier nun mal einen Edge-Case und vielleicht haben Andere das gleiche Problem.
Wenn einer der Entwickler Lust hat, kann er für diesen Edge-Case eine Option einbauen oder vielleicht gibt es schon eine Option, nur ich kenne sie noch nicht.

Nach 3 Jahren, ist dies das erste Mal, dass dieser Fehler bei mir aufgetreten ist und wenn ich alles wüsste, müsste ich die Community nicht bemühen.

Und jetzt führe ich solche Gespräche wie diese hier oder ob Docker auf einem Pi absoluter Bullshit ist.

Ich bin vielleicht nicht der erste und bestimmt nicht der Letzte, der die genauen internen Funktionen von ioBroker und seinen Adaptern nicht kennt.

Das Problem kann demnach auch jeder andere Adapter verursachen, sogar Adapter die gar nicht mehr installiert sind und Datenreste in der Objektdatenbank hinterlassen haben. Bei mir war es nun mal der MQTT Adapter mit der HA Autodiscovery Funktion von bestimmten Clients.
Der Fehler hätte auf jedem System mit zu wenig RAM auftreten können.

Dieses Thema soll anderen helfen, sollten diese vielleicht mal vor demselben Problem stehen.

Der MQTT Adapter war bei mir nun mal ausschlaggebend,
deshalb werde ich das weiter beobachten und vielleicht selber eine Lösung finden.

Für jeden anderen der beim Starten des JS Adapters ein „heap out of memory“ Fehler bekommt, kann ich nur raten, prüft eure Objektdatenbank auf verwaiste Objekte und räumt diese auf.

[Marc Berg]

@smhrambo
Ui, was ein Vortrag. Ich habe mir mal die Mühe gemacht, die 2% rauszufiltern, die auf meine Frage eingehen.

Wenn du dir die Mühe machen würdest, die Konsequenzen dessen zu durchdenken, was der MQTT Adapter an Magie leisten soll, würdest du vielleicht merken, dass deine Erwartungen nicht erfüllbar sind.

VG,

Dein Troll

[arteck]

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

Das Problem kann demnach auch jeder andere Adapter verursachen, sogar Adapter die gar nicht mehr installiert sind und Datenreste in der Objektdatenbank hinterlassen haben.

na jetzt erzählst du aber quatsch.. rechne mal nach wie viel von dem Müll da übrig bleiben müsste um ein OOM zur verursachen.. bei wie viel Speicher..

ok Raspi Docker -> jo da vielleicht. wobei auch nicht.. pack die object und states in die redis ..sache erledigt

und übrigendt rabbitMQ ist für was anderes konzipiert als MQTT Müll zur verwalten.. nur mal neben bei. aber jedem das seine.

HA ist in diesem Fall eher ein Smarthome Standard,

diese Aussage ist auch ulkig.. ist so als ob ich sagen würde Zigbee ist im SmartHome Standard.

der MQTT Adapter macht das was es soll.. wie ein Broker nimmt der Daten entgegen.(wenn man den im Server/Client MOdus betreibt)
was du damit machst ist deine Sache.. kannst auf bestimmte topics lauschen.. wozu dann soll es denn diese Daten auch löschen..
wir sind hier nicht im telemetrie Bereich,wo du Milliarden an Daten bekommst.. wobei diese bestimmt auch nicht gelöscht werden sondern auch zusätzlich zwecks Auswertung geschoben werden..

kurz und knapp
dein OOM ist ein Konstrukt deiner Hardware/Software.. sei es denn eine Installation des BS..mit zusatz Paketen bei dir halt Docker..
oder der Pi hat einen wech..was auch dazu führen kann .. dass bei vorbeit kommen des Bits dieser umschlägt und ..bääää OOM

[smhrambo]

@arteck said in JS-Adapter startet ständig neu: heap out of memory:

na jetzt erzählst du aber quatsch.. rechne mal nach wie viel von dem Müll da übrig bleiben müsste um ein OOM zur verursachen.. bei wie viel Speicher..

kurz und knapp
dein OOM ist ein Konstrukt deiner Hardware/Software.. sei es denn eine Installation des BS..mit zusatz Paketen bei dir halt Docker..
oder der Pi hat einen wech..was auch dazu führen kann .. dass bei vorbeit kommen des Bits dieser umschlägt und ..bääää OOM

Das Klingt so, als ob der Fehler einzig und alleine nur bei mir und meinem System passieren könnte.
In meinem Fall war es der JS Adapter der beim Start eben über alle Objekte in der Datenbank geht und erst in diesem Zeitpunkt diesen Fehler erzeugt.

Also bei mir waren es rund 3000 Objekte zu viel.
Hauptausschlaggebend war bei mir der MQTT Adapter.
Ich hatte aber auch woanders rund 1000 Objekte, deren letzte Aktualisierung vor über einem Jahr waren.

Kannst du ausschliessen, das nur ich dieses Problem hatte und kein anderer es haben könnte.
Kann auch sein, dass jemand anders dieses Problem auch hatte und aus Frust das System einfach neu aufgesetzt hat.
Aber in 3 Jahren hat er das Problem vielleicht wieder.
Theoretisch reicht es schon aus nur einen Adapter, den man aus Spaß oder mal zum ausprobieren drauf hatte, zu entfernen(Wenn dieser so viele Objekte aus der Datenbank frei gibt, das genug Speicher zur vergügng steht).

Und was haben zu viele verweisste Objekte im MQTT Adapter mit docker zu tun.
Bitswap ist für meinen Fall auch ganz schön weit aus der Luft gegriffen.

übrigendt rabbitMQ ist für was anderes konzipiert als MQTT Müll zur verwalten.. nur mal neben bei. aber jedem das seine.

rabbitMQ ist nicht NUR für MQTT designed.
Es ist ein message broker und erfüllt diese Aufgabe, nur unterstütz dieser unterscheidliche Protokolle.

Und lies dir mal deine Aussage zum MQTT Adapter.
rabbitMQ erledigt seine Aufgabe als MQTT Broker genauso wie Mosquitto oder euer mqtt-Adapter,
denn er ist als message broker konzipiert, vielleicht etwas überdimensioniert für den Einsatz im Smarthome, aber genau so wie es das Protokoll vorgibt.

diese Aussage ist auch ulkig.. ist so als ob ich sagen würde Zigbee ist im SmartHome Standard.

Das hier meine Aussagen immer auf die Goldwaage gelegt werden ist ulkigere, besonders wenn sie aus den Kontext gerissen werden und die Hälfte des Satzes weggelassen wird.
Die genaue Erklärung für meine Aussage kommt im Nebensatz, der nach dem Komma kommt.
Ich habe auch nicht geschrieben, dass es DER STANDART im Smarthomebereich ist.

Es gibt nun mal einige opensource Projekte die das HA Discovery einsetzten.
Ich denke, dass es die Verwaltung recht einfach macht und ein sich um eine gut durchdachtes Methode handelt.

wir sind hier nicht im telemetrie Bereich

Das mag angehen, aber hier wird eine Software/Protokoll für die Telemetrie eingesetzt (MQTT = Message Queuing Telemetry Transport).
Also darf ich vielleicht dem anderen Forumposter auch sagen, dass ich diesbezüglich gewisse Vorstellungen haben und das ich das Protokoll verinnerlicht habe.
Und das es sehr wohl möglich ist Topics und ihre Nachrichten vom MQTT Broker zu löschen.

@marc-berg
Und wenn du dir die Mühe gemacht hättest und etwas mehr über meine Aussage nach gedacht hättest, hättest du feststellen können, dass man sehr wohl Topics und Nchrichten vom Broker löschen kann.

[OliverIO]

@smhrambo

puh, jetzt wird es aber anstrengend

[smhrambo]

@oliverio Sorry, habe gerade viel Zeit(Corona) und hatte eben dieses Problem.
Eigentlich wollte ich nun, nachdem alles geklärt wurde, anderen eine Hilfestellung geben.
Stattdessen habe ich das Gefühl die heilige Kuh beleidigt zu haben, aber so ist das manchmal.

Falls die Community der Meinung ist, es handelt sich wirklich um einen fluke können sie den Server von diesem Thread befreien bzw. auf das nötigste runterdampfen.

Over and out.

[arteck]

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

Stattdessen habe ich das Gefühl die heilige Kuh beleidigt zu haben, aber so ist das manchmal.

ne ich will nur dass du verstehst das 3k an objekten kein problem verursachen kann.. bei 300k würde ich nochmal nachfragen...

aber komm ist ggut.. mir egal.. ich bin raus hier....