UPDATE 31.10.: Amazon Alexa - ioBroker Skill läuft aus ?

[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:wink:
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 :-)