js-controller 4.0 jetzt im BETA/LATEST!

[AlCalzone]

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

Mich stören die Auffälligkeiten nicht und ich kann damit leben, aber wollte es eben gemeldet haben.

Wir würden es schon gerne finden, aber dazu müssen wir es entweder verstehen oder nachstellen können. Ich versuch mich nachher auch nochmal dran.
Ist sonst noch irgendwas auffälliges während dem Update? z.B. hohe input/output counts in der Instanzübersicht während dem Update?

[Diginix]

@alcalzone Keine Auffälligkeiten bei in/out beim Controller. 15min nach dem Ausreißer gestern war in mal bei 73 statt <50 wie normal. Aber das ist ja sicher weit unter dem Radar.

Im Diagramm sehe ich gerade, dass sich der js-controller heute 7:41 Uhr vollkommen unbemerkt zeitweise auch wieder >2 GB gegönnt hat. Zu der Zeit war der iobroker einfach nur im Leerlauf. Kein Backup Cron, kein gar nichts.

[Diginix]

@AlCalzone HA!

Ändert man die Diagrammdarstellung und zoomt rein, sieht man doch etwas:

Immer wenn der RAM hochschnellt bekommt der js-controller ein Vielfaches an in states (>200 bei sonst <50).

[apollon77]

@diginix Interessant. Sind das controller eingehend oder ausgehend changes? Ansonsten: War das während dem Update auch so so?

Könntest DU während wir das versuchen zu analysieren den controler bitte auf info loglevel stellen ?

[Diginix]

@apollon77 Nur die eingehenden Events schnellen hoch. Das obere Diagramm mit >200 in Events war bei dem Update
Das untere Diagramm ist von heute morgen wo eigentlich keine Aktivitäten waren.
Loglevel ist auf info umgestellt.

[apollon77]

@diginix Wirklich "inputCount"?

[Diginix]

@apollon77 Ja, system.host.iobroker.inputCount geht von normal ca 40 auf >200

Die Entprellzeit für die Erfassung war sogar 5000 ms. Habe nun mal 1000 eingestellt, falls es mal in unter 5 Sek hochschnellt, bekäme man es sonst gar nicht mit.

Nun würde mich ja mal brennend interessieren woher die inEvents kommen (können)?

[AlCalzone]

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

Nun würde mich ja mal brennend interessieren woher die inEvents kommen (können)?

Magst du vielleicht noch die inputs/outputs für die bekannterweise etwas gesprächigeren Adapter aktivieren?
d.h. Javascript, Shelly (?), Influxdb, mihome-vacuum?

mihome-vacuum hab ich zur Sicherheit mit drin, weil der es bei mir auch mal geschafft hat mit tausenden Logs meinen Pi zum Absturz zu bringen.

[apollon77]

@diginix Ja ich denke es ist nicht direkt"diese Events" weil das sind viel zu wenige. Und die Zahl sagt auch nur das bei den (recht wenigen) States die der Controller selbst als Updates bekommt es mehr wurde ... Was nebenher ggf noch in der DB pot los ist ist damit nicht sichtbar.

Aber generell ists komisch, prüfe nochmal deine skripte ob davon ggf welche "spammen" könnten ... und ja die Idee mehr Adapterprozesse (alle?) mitzuloggen ist auch gut.

Setz nur das Reporting Interval nicht zu weit runter ...

[Diginix]

@apollon77 Allein der iobroker Neustart wegen Loglevel Umstellung hat 10 Uhr auch wieder diese Anomalie:

Somit müsste es sich doch eigentlich auch bei euch mit meinen Dateien nachstellen lassen? Hat es ja aber anscheinend nicht.

[apollon77]

@diginix Naja dann müsste man es mal schaffen es komplett nachzustellen - aber auch das tat ja bei dir letztens nicht ... Weil wenn du es nachstellen könntest dann wäre ne Idee mal unterschiedliche Adapter zu deaktivieren um zu schauen ob es passiert wenn mit denen was ist und und und

[Diginix]

@apollon77 Für den Javascript Adapter hatte ich in/out Events schon mit in der history habe nun noch influx, shelly, mihome-vacuum dazu genommen.

Zumindest gibt es bei in/out beim javascript Adapter zeitliche Zusammenhänge:

Die Spitzen alle 15min muss ich noch prüfen. Da läuft mind. 1 Cron in einem Skript, aber warum da dann >3000 Events fliegen, verstehe ich gerade noch nicht. Habe den einzigen 15min Cron den ich finden konnte mal auskommentiert. Bin gespannt ob die Spitzen dann weg sind.

Ganz rechts sieht man auch noch eine "out" Spitze vom Skript Adapter mit >260 kurz nachdem alle Skripte wieder liefen nach iobroker restart.

[Moko]

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

@moko Also nein kann damit nichts zu tun haben ... und ja Backitup 2.3.3 ist noch im Latest ... wie auch der controller 4

https://repo.iobroker.live/sources-dist.json (ist in iobroker als stable hinterlegt) zeigt mir auch die 2.3.3 an, iobroker selbst meint
"Installierte Instanzen: 1
Verfügbare Version: 2.2.3
Installierte Version: 2.2.3"

[Diginix]

@moko Wo steht da 2.3.3?

[Moko]

@diginix latestVersion "2.3.3"

P.S. ich habe nicht behauptet dass die 2.3.3 als stable angezeigt wird.
Bei mir ist die letzte 2.2.3

P.S. mein Fehler: habe latest mit stable verwechselt.

[Diginix]

@moko Wenn du auf stable bist, wird dir keine latest Ver. angeboten.

[Diginix]

@AlCalzone Ich bin nun schon die ganze Zeit auf der Suche nach der Ursache für die Eventspitzen beim Javascript Adapter.
Alle Skripte zusammen haben laut Logausgabe <80 subscriptions. Wenn ich die javascript Instanz starte und somit auch alle Skripte, gibt es schon mal eine Spitze von 263 Event ausgehend. Wie wird dieser Wert ermittelt bzw. was zählt da mit rein?

Die Spitzen bei den eingehenden Events alle 15 min kann ich mir auch noch nicht erklären. Bin aber noch am Testen durch Deaktivieren von einzelnen Skripten die States von Adapter nutzen, die nur alle 15 min laufen (dwd, daswetter).

[AlCalzone]

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

Alle Skripte zusammen haben laut Logausgabe <80 subscriptions. Wenn ich die javascript Instanz starte und somit auch alle Skripte, gibt es schon mal eine Spitze von 263 Event ausgehend. Wie wird dieser Wert ermittelt bzw. was zählt da mit rein?

Jede State-Änderung jedes Wertes auf den du subscribest zählt da mit rein. By default subscribed der JS-Adapter aber alle States, selbst die die du nicht nutzt. So ermöglicht er, dass getState und setState trotz asynchroner DB synchron sind.

---

Ich hab grade nochmal versucht das nachzustellen. Testinstanz mit latest controller, die Adapter Web/WS/VIS, ein Skript welches 1000 changes/s generiert (also 15000 in- und out-events), und dabei fleißig Adapter aktualisiert. Nix... Der Controller dümpelt auf 180 MB RAM herum.

[Diginix]

@alcalzone Hm, ich werde mit meiner Analyse auch nicht schlauer.
Ich habe alle javascripte angehalten die ein "schedule" enthalten. Trotzdem habe ich weiterhin alle 15 min diese Spitzen.

Die gibt es wahrs. schon immer und machen auch keine direkten Probleme, aber nun habe ich mich durch das Erfassen der in/out Events bis dahin vorgearbeitet und wüsste gern den Ursprung.
Wenn ich den javascript Adapter anhalte kommt die ausgehende Spitze im Bild markiert. Sind aber nur 230, also ganz andere Skalierung. Meine Skripte schreiben beim Beenden keine states. Jedenfalls nicht wissentlich.

[e-i-k-e]

@apollon77

So siehts aus.

pi@raspberrypi-display2:~ $ iobroker upgrade self
internal/modules/cjs/loader.js:905
  throw err;
  ^

Error: Cannot find module '/opt/iobroker/node_modules/iobroker.js-controller/iobroker.js'
    at Function.Module._resolveFilename (internal/modules/cjs/loader.js:902:15)
    at Function.Module._load (internal/modules/cjs/loader.js:746:27)
    at Function.executeUserEntryPoint [as runMain] (internal/modules/run_main.js:75:12)
    at internal/main/run_main_module.js:17:47 {
  code: 'MODULE_NOT_FOUND',
  requireStack: []
}