js-controller 4.0 jetzt im BETA/LATEST!
-
@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 -
@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
-
@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.
-
@dolomiti Hm ... mach mal bitte im ioBroker dir ein
npm list mongodbWas kommt da raus? -
@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.
-
@apollon77 verlief fehlerfrei incl. backitup update
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 -
@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 -
@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 -
@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.
-
@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
-
@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.
-
@diginix Hm ... Was war denn in dem Zeitraum? Ist das ein Start oder zwischendrin? Ein Backup? Oder was ist da gewesen? Habe solche "Ausschläge" noch nie gesehen
-
@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.
