NEWS
js-controller 4.0 jetzt im BETA/LATEST!
-
@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.*
@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 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... -
@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
@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 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=0Im 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.
@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=0Auf der Instanzübersicht wärs etwas kompakter gewesen :)

Naja gut, sieht jetzt aber nicht überlastet aus... Bin mal auf den RAM gespannt.
-
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 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
@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
-
@apollon77 Update lief ohne OOM oder ähnliches durch. Danach noch backitup Adapter in der GUI aktualisiert, aber auch das ohne Auffälligkeiten.
-
@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
-
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
@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.
-
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
@apollon77 verlief fehlerfrei incl. backitup update:wink:
nur das ich jetzt wieder die doppelt CPU Auslastung habe -
@apollon77 verlief fehlerfrei incl. backitup update:wink:
nur das ich jetzt wieder die doppelt CPU Auslastung habe -
@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.
@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 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 -
@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) ;-)
@apollon77 script ist in arbeit,
wenns normal läuft liegt die Instanz im Schnitt bei 1000/14 -
@apollon77 script ist in arbeit,
wenns normal läuft liegt die Instanz im Schnitt bei 1000/14@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/14ich hab 3 JavaScript Instanzen. bei 2 davon geb ich dir recht mit
-) 5680/11
-) 5702/11
aber bei der dritten
-) 5386/2642 -
@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=0Auf der Instanzübersicht wärs etwas kompakter gewesen :)

Naja gut, sieht jetzt aber nicht überlastet aus... Bin mal auf den RAM gespannt.
@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.
-
@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/14ich hab 3 JavaScript Instanzen. bei 2 davon geb ich dir recht mit
-) 5680/11
-) 5702/11
aber bei der dritten
-) 5386/2642@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 :-)
-
@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.
@diginix sagte in js-controller 4.0 jetzt im BETA/LATEST!:
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.
D.h. der Peak ist der Controller-Start? Wenn ja, magst du mir mal deine objects.jsonl, states.jsonl und iobroker.json schicken, dass ich das nachstellen kann? Schick dir nen Upload-Link per PN.
-
@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.
-
@diginix sagte in js-controller 4.0 jetzt im BETA/LATEST!:
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.
D.h. der Peak ist der Controller-Start? Wenn ja, magst du mir mal deine objects.jsonl, states.jsonl und iobroker.json schicken, dass ich das nachstellen kann? Schick dir nen Upload-Link per PN.
@alcalzone sagte in js-controller 4.0 jetzt im BETA/LATEST!:
@diginix sagte in js-controller 4.0 jetzt im BETA/LATEST!:
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.
D.h. der Peak ist der Controller-Start? Wenn ja, magst du mir mal deine objects.jsonl, states.jsonl und iobroker.json schicken, dass ich das nachstellen kann? Schick dir nen Upload-Link per PN.
Ja der peak war bei/ab "iobroker start" nach dem js-controller Update auf 4.0.12.
Dateien sende ich dir.