js-controller 4.0 jetzt im BETA/LATEST!

[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

[apollon77]

@crunchip ok. Na dann viel Spaß beim weiter forschen

Eingehend JavaScript ist immer seh hoch weil ja alles rein geht bei Standard Konfiguration. Aber 1000 ausgehende ist ne Menge (ist eine 15s Messung)

[crunchip]

@apollon77 script ist in arbeit,
wenns normal läuft liegt die Instanz im Schnitt bei 1000/14

[homecineplexx]

@crunchip said in js-controller 4.0 jetzt im BETA/LATEST!:

@apollon77 script ist in arbeit,
wenns normal läuft liegt die Instanz im Schnitt bei 1000/14

ich hab 3 JavaScript Instanzen. bei 2 davon geb ich dir recht mit
-) 5680/11
-) 5702/11
aber bei der dritten
-) 5386/2642

[Diginix]

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

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

iobroker start nach js-controller Update auf 4.0.12. Wobei die Ver. wahrs. egal ist. Aber der js-controller nimmt sich da fast 3min 2 GB RAM. Da ist klar warum der bei sonst <1GB freien RAM der VM vom OOM abgeschossen wurde.

States in/out ist dabei unspektakulär.

[apollon77]

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

-) 5386/2642

Naja dann hast Du in der dritten ein Skript laufen was sehr viele "setState" oder andere Aktionen macht ... Wenn das so soll ist ja alles in Ordnung