controller.js frist Ram und javascript.X bei >90%

[tasuanetrukiat]

Es scheint tatsächlich irgendwie mit dem valuetracker zusammen zu hängen. Ich habe nun erst mal alle Überwachten Objekte abgeschaltet. Mit max. 30 Stück fand ich das eigentlich nicht so viele. Aber nun haben sich die CPU Werte ohne gestartete java-Skripte auf > 1% eingependelt.

Hat jemand eine Idee wann wann der valuetracker anfängt so rum zu spinnen?

[paul53]

@tasuanetrukiat sagte: beide Javascript-Prozesse hier viel CPU-Last generieren.

Gibt es Skripte in der Gruppe "global" (Expertenmodus)?

[tasuanetrukiat]

@paul53 sagte in controller.js frist Ram und javascript.X bei >90%:

@tasuanetrukiat sagte: beide Javascript-Prozesse hier viel CPU-Last generieren.

Gibt es Skripte in der Gruppe "global" (Expertenmodus)?
Also ich habe da nie rum gefummelt und nie den Expertenmodus verwendet.

[paul53]

@tasuanetrukiat sagte: da nie rum gefummelt und nie den Expertenmodus verwendet.

Vielleicht hat der Adapter "valuetracker" Skripte unter "global" erstellt?

[tasuanetrukiat]

@paul53 sagte in controller.js frist Ram und javascript.X bei >90%:

@tasuanetrukiat sagte: da nie rum gefummelt und nie den Expertenmodus verwendet.

Vielleicht hat der Adapter "valuetracker" Skripte unter "global" erstellt?
Sieht nicht so aus:

[BananaJoe]

@tasuanetrukiat sagte in controller.js frist Ram und javascript.X bei >90%:

Was mich auch wundert ist das beide Javascript-Prozesse hier viel CPU-Last generieren. Ich hatte eher damit gerechnet das nur einer solche Probleme macht.
Wenn ich alle Skripte stoppe dann sinkt auch die CPU Last nicht sehr sondern bleibt auf hoher Nutzung bis ich den Docker-Container neu starte.
Was mir aber gerade aufgefallen ist: Im Instanzscreen werden beide Prozesse immer wieder rot:

Ich würde stark vermuten das du Amok-Laufende Skripte hast.
Beispielsweise ein Skript welches viele oder sogar endlos neue Trigger erzeugt - und dann statt wie geplant 1 Trigger dann gleich 50 anspringen die alle das gleiche machen.

Was für eine CPU steckt in deinem XEN-Server Host?

valuetrackerovertime ist ein eigener Adapter und sollte somit getrennt in der CPU-Auslastung auftauchen. Und keine Wechselwirkung mit den JavaSkript-Adapter-Instanzen haben. Außer wenn du mit Skripten darauf reagierst

[tasuanetrukiat]

@bananajoe sagte in controller.js frist Ram und javascript.X bei >90%:

@tasuanetrukiat sagte in controller.js frist Ram und javascript.X bei >90%:

Was mich auch wundert ist das beide Javascript-Prozesse hier viel CPU-Last generieren. Ich hatte eher damit gerechnet das nur einer solche Probleme macht.
Wenn ich alle Skripte stoppe dann sinkt auch die CPU Last nicht sehr sondern bleibt auf hoher Nutzung bis ich den Docker-Container neu starte.
Was mir aber gerade aufgefallen ist: Im Instanzscreen werden beide Prozesse immer wieder rot:

Ich würde stark vermuten das du Amok-Laufende Skripte hast.
Beispielsweise ein Skript welches viele oder sogar endlos neue Trigger erzeugt - und dann statt wie geplant 1 Trigger dann gleich 50 anspringen die alle das gleiche machen.

Was für eine CPU steckt in deinem XEN-Server Host?

Steht oben im iobroker log:

"model":"AMD EPYC 7251 8-Core Processor"

Sollte eigentlich nicht sein. Vor allem wenn ich gar keine Skripte starte sollte die CPU nicht bei nahe 100 % arbeiten, oder?

[paul53]

@tasuanetrukiat sagte: Sieht nicht so aus:

Dann vermute ich, dass du Skripte hast, die Amok laufen, sobald sie auf Datenpunkte von "valuetracker" zugreifen / triggern.

[tasuanetrukiat]

@paul53 sagte in controller.js frist Ram und javascript.X bei >90%:

@tasuanetrukiat sagte: Sieht nicht so aus:

Dann vermute ich, dass du Skripte hast, die Amok laufen, sobald sie auf Datenpunkte von "valuetracker" zugreifen / triggern.

Ja, ich habe wohl das eine oder andere Skript das mal auf einen Wert vom valuetracker zugreift. Aber wenn das skript gar nicht gestartet wird, sollte es dann doch auch nicht wild laufen, oder?

[paul53]

@tasuanetrukiat sagte: wenn ich gar keine Skripte starte sollte die CPU nicht bei nahe 100 % arbeiten, oder?

Nachdem alle Skripte gestoppt wurden, kann es sehr lange dauern, bis alle gepufferten Ereignisse abgearbeitet sind. Da hilft nur ein anschließender Neustart von ioBroker.

[tasuanetrukiat]

@paul53 sagte in controller.js frist Ram und javascript.X bei >90%:

@tasuanetrukiat sagte: wenn ich gar keine Skripte starte sollte die CPU nicht bei nahe 100 % arbeiten, oder?

Nachdem alle Skripte gestoppt wurden, kann es sehr lange dauern, bis alle gepufferten Ereignisse abgearbeitet sind. Da hilft nur ein anschließender Neustart von ioBroker.

Das hatte ja trotz gestoppter Skripte auch nicht geholfen. Erst das stoppen des valuetracker hat gezeigt das es irgendwo damit zusammen hängt.
Dann hatte ich alle getrackten Werte im VT abgeschaltet und den VT selber wieder eingeschaltet und bisher sind auch keine hohen Werte zu beobachten.

[tasuanetrukiat]

Aber das mit einem Trigger den ich immer wieder starte kann tatsächlich noch zusätzlich sein, da ich das mit den Blockly Skripten noch nicht vollständig verstanden habe.

Da sollte ich aber einen eigenen Tröt für machen.

[Codierknecht]

@tasuanetrukiat sagte in controller.js frist Ram und javascript.X bei >90%:

da ich das mit den Blockly Skripten noch nicht vollständig verstanden habe

Lesestoff: https://forum.iobroker.net/topic/70481/blockly-for-dummies-starthilfe-und-tipps

Ganz wichtig: "Trigger in Trigger" - nicht machen, niemals, never ever!