js-controller 4.0 jetzt im BETA/LATEST!

[apollon77]

@crunchip Nutzt Du adapter im Compact mode und da in gruppe 0?

EDIT: Ok vergiss die Frage: Diese Logzeilen sind die die der Shelly adapter ausgespuckt hatte nur nochmal "wiederholt"

[Diginix]

@apollon77 sagte in js-controller 4.0 jetzt im BETA/LATEST!:

@diginix Sehr interessant. Also das "Already running" ist einfach (und da haben Sie auch nicht geloopt!) - Der Restart passiert so schnell das die instanzen noch auf "alive" stehen, das erkennt der startende adapter und sagt "neee, da läuft schon einer". Dann stoppen Sie sich mit Fehler 7, der Controller räumt das auf bzw durch die kurze verzögerung bis zum nächsten Restart ist dann alles ok.

Wenn ich da nicht manuell eingreife geht das munter so weiter. Zumindest war das meine Beobachtung. Da man schnell wieder ein lauffähiges System möchte, bricht man halt mit iob stop alles ab. Ob sich das von allein beruhig hätte, bekommen wir so nicht raus. Eigentlich interessiert mich das OOM Killer "Problem" mehr. Wenn genug da ist, sollte kein Update diesen triggern. Mit js-controller 3.x und file db hatte ich das nie und da war der RAM sogar 2 GG weniger bei identischer Adapter Anzahl.

Also wenn ich jetzt frech sein darf frage ich dich ob DU es nachstellen kannst und wenn du es "verlässlich" hinbekommst dann wäre mal eine Idee zurück auf fileDB zu gehen um auszuschliessen das es was mit jsonl zu tun hat

Verständlich, aber selbst mit Proxmox und VMs ist das keine einfache Aufgabe. Selbst wenn ich die VM klone und darin alles auf file db zurück stelle, kann ich nicht alle Adapter laufen lassen, weil zB mqtt clients nicht an 2 Brokern hängen können. Also liefe im Klon nur ein kleiner Teil der Adapter um auch das Netzwerk nicht zu überlasten. Ob das dann noch repräsentativ wäre, weiß ich nicht. Ich beobachte vorerst mal unverändert weiter.

[apollon77]

@diginix Ich habe in meinen testsyteme auch rumexperimentiert und bei mir ist RAM technisch alles stabil ...

Die Preisfrage ist ja Wo das RAM verbraucht wird ... (und nur die Grafik darfst nicht ansehen weil Linux sich an sich RAM krallt wenns da ist und freigibt wenn nötig. also "zählt nur" free -m

[apollon77]

@diginix sagte in js-controller 4.0 jetzt im BETA/LATEST!:

Wenn ich da nicht manuell eingreife geht das munter so weiter. Zumindest war das meine Beobachtung.

sollte maxmial 30s so sein (wenn mehr als einmal)...

[Werner303]

@apollon77 Vielen Dank. Die kleine Änderung am Code hat mir sehr geholfen.

[AlCalzone]

@diginix Kannst du mal mitschneiden, was die einzelnen ioBroker-Prozesse an RAM verbrauchen? Z.B. durch History-Aufzeichnung von system.adapter.<adaptername>.0.memRss und system.host.<hostname>.memRss

Ebenfalls interessant wäre (einmalig) Anzahl Objekte, Anzahl States und input/output count der Adapter.

[Diginix]

@alcalzone memRss für alle Instanzen+Host ist nun in History aktiviert.
Objekte: 17720, Zustände: 15859
Alle in/out aller 47 Instanzen ging als Screenshot am einfachsten:
https://www.dropbox.com/s/ceafuk51rhv0om2/2022-02-17_in_out_adapter.png?dl=0

Im regulären Betrieb ist da aber auch nichts auffällig mMn. Nur bei den js-controller Updates hatte ich zuletzt einmal ein OOM Problem und heute nach Update von 5 Adaptern.

[apollon77]

@diginix sagte in js-controller 4.0 jetzt im BETA/LATEST!:

le in/out aller 47 Instanzen ging als Screenshot am einfachsten:

Neee, auch das gibts als states in system.adapter/host.NAME.*

[Diginix]

@apollon77 Davon ist doch der Screenshot super vorgefiltert
Aber selbst das lies sich nicht als html, text aus Admin raus kopieren und ich copy/paste keine 94 Werte plus Namen...
Wenn ich @AlCalzone richtig verstanden habe, wollte er es doch nur einmalig und das wahrs. menschlich lesbar aber nicht zwingend maschinenlesbar...

[apollon77]

@diginix Naja, einmalig ist einmalig ... mit Historisierung sieht man wie es sich generell verhält ... kann ja sein das der Blick auf das "JETZT" sehr irreführend ist

[Diginix]

@apollon77 Ich habe nur gemacht was @AlCalzone geschrieben hat.
Dachte er will sich erstmal ein Bild von meinem System verschaffen.
RAM wird nun mit Vorhaltezeit von 1 Monat dauerhaft mirgemeiselt. Das kann ich für in/out genau so aktivieren.

Edit:
ab sofort wird für 30 Tage rückwirkend auf der HDD persistiert:

system.adapter/host.*.*.memRss
system.adapter/host.*.*.inputCount
system.adapter/host.*.*.outputCount

[AlCalzone]

@diginix sagte in js-controller 4.0 jetzt im BETA/LATEST!:

Alle in/out aller 47 Instanzen ging als Screenshot am einfachsten:
https://www.dropbox.com/s/ceafuk51rhv0om2/2022-02-17_in_out_adapter.png?dl=0

Auf der Instanzübersicht wärs etwas kompakter gewesen

Naja gut, sieht jetzt aber nicht überlastet aus... Bin mal auf den RAM gespannt.

[apollon77]

Ok, mit letzten kleineren Optimierungen rollte die 4.0.12 an (Stable RC3):

4.0.12 (2022-02-17)

• (Apollon77) make sure to really end CLI process when they should end in error cases
• (Apollon77) catch error when streaming data to stdout and this is closed already

Also alle "stoppedList"-Fehler bei CLI Kommandos sollten jetzt weg sein, bitte generell gern nochmal CLI Kommandos testen

[Dolomiti]

@apollon77 sagte in js-controller 4.0 jetzt im BETA/LATEST!:

@dolomiti Das hat nichts mit dem Controller zu tun. Das liegt an Nodejs 14 und scheinbar einer "alten" version von node-red der eine buggy mongodb version enthalten hat und diese verursacht diese Fejhler. ALso bitte node-red aktualisieren

Node-Red war aktuell bei 2.4.2. Habe es jetzt mal deinstalliert, dann war der Fehler weg. Nach Neuinstallation von 2.4.2 aus dem latest-Zweig, als auch 2.4.1 aus dem stable-Zweig ist die Meldung wieder da.
Soll ich ein Issue bei Node-Red-Adapter machen?

Gruß

Dolomiti

[Diginix]

@apollon77 Update lief ohne OOM oder ähnliches durch. Danach noch backitup Adapter in der GUI aktualisiert, aber auch das ohne Auffälligkeiten.

[apollon77]

@dolomiti Hm ... mach mal bitte im ioBroker dir ein npm list mongodb Was kommt da raus?

[Feuersturm]

@apollon77 sagte in js-controller 4.0 jetzt im BETA/LATEST!:

Ok, mit letzten kleineren Optimierungen rollte die 4.0.12 an (Stable RC3):

4.0.12 auf Master und Slave erfolgreich aktualisiert und keine Probleme beim starten.

[crunchip]

@apollon77 verlief fehlerfrei incl. backitup update
nur das ich jetzt wieder die doppelt CPU Auslastung habe

[apollon77]

@crunchip und welcher Prozess ist es? Vllt solltest du dich mal einige Host und Adapter States mit History mitloggen das du genauer sagen kannst was sich wann wie anders verhält.

[crunchip]

@apollon77 glaub ich hab das Problem schon gefunden, scheint an javascript zu liegen, bzw eher ein Script, das Wetterwarn Script https://forum.iobroker.net/topic/30616/script-dwd-uwz-nina-warnungen-als-push-sprachnachrichten/
das war das einzige was ich die Tage aktualisiert hatte. Wenn ich das deaktiviere, geht die CPU runter
Edit
Bei der Javascript Instanz lagen die Ein/Ausgänge bei ~3500/~1000 nach dem iobroker gestartet wurde