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

[tourer4778]

@dr-bakterius sagte in Manchmal hohe CPU Last:

@tourer4778

a) Warum deaktivierst du die Instanz nicht?

Weil ich Sie vergessen habe zu deaktivieren bzw. mir nicht mehr bewust war, das ich dort kein Skript mehr laufen habe.

b) Wo siehst du wie hoch die CPU-Last der Instanz ist?

Ich hatte mal gelesen, das die Werte hinten die Vorgänge pro 15 sec sind, was natürlich das auf die Last der CPU geht.

[arteck]

@tourer4778 sagte in Manchmal hohe CPU Last:

Was mich auch wundert, das auf der Javaskript.2 auch so eine hohe Auslastung ist, obwohl dort kein Skript läuft.
Bei mir wird nur 0 & 1 verwendet

weil alle javscript adapter in einem prozess laufen.. ist so technisch..

und ja da ist was faul 6k ist zu groß´..eigebtlich alles was über 3k geht zur laufzeit..
bei start gehen die ab und an mal drüber aber dann sollte sich das unter 2k einpendeln

[tourer4778]

@arteck
Ich habe die Werte mal beobachtet und ich denke, dass ich eine Ursache eingrenzen konnte, aber nicht ganz nachvollziehen kann.
Mit Operating-Hours nehme ich die Betriebsstunden meiner Heizung auf.
Ich unterscheide Heizung, Warmwasser, Tag, Woche, Monat usw. Es kommen also ein paar Counter zusammen.
Wenn diese Counter starten, steigt meine CPU-Last um ca. 20%.
Das Skript ist aber eigentlich ganz einfach aufgebaut und sollte keine große CPU-Last erzeugen. Operating-Hours selbst steigt um ca. 2% in der CPU-Last. Übersehe ich was, ist das Skript falsch? Es wird doch nur einmal beim Start getriggert und einmal beim Beenden.
Ich habe hier nur einen Teil dargestellt.

[Codierknecht]

@tourer4778 sagte in Manchmal hohe CPU Last:

Übersehe ich was, ist das Skript falsch? ... Ich habe hier nur einen Teil dargestellt.

Daher kann man das auch schlecht beurteilen. Du zeigts halt nur einen (möglicherweise unkritischen) Teil.

Und den könnte man (nur so am Rande) auch noch etwas vereinfachen:

[tourer4778]

@codierknecht
Danke, werde ich mir genauer ansehen.
Die Anderen Netzwerke sehen genau so aus, mit anderen Countern und anderen DP zur Auslösung.
Es sind 12 Counter in diesem Skript.

[Codierknecht]

@tourer4778

1. Wozu laufen da überhaupt mehrere JS-Instanzen?
2. Loggst Du in eine Datenbank? Wo läuft die?
3. Wenn die Counter aktiv sind: Wie sieht das Loggen in die DB dann aus?

[tourer4778]

@codierknecht
Zu 1. Ich habe zwei J.Instanzen. Eine überwacht nur die Hauptinstanz.
Zu 2. Die Daten werden am ende des Tages, Woche, Monat in History abgelegt mit alles Betriebsstunden.
Zu 3. Verstehe nicht, was du meinst. Die Counter laufen immer dann mit bzw. laufen weiter, wenn die Heizung läuft.
Am ende des Tages / Woche / Monat werden die Counterwerte/ Betriebsstunden in History einzelnd abgelegt. Die Counter laufen nur, wenn auch die Heizung läuft, bzw Brauchwasser erwärmt wird.

[Codierknecht]

@tourer4778 sagte in Manchmal hohe CPU Last:

Zu 3. Verstehe nicht, was du meinst

Da die Antwort zu

Loggst Du in eine Datenbank? Wo läuft die?

"History" lautet: Zeige doch mal die Stellen im Script, die für das Schreiben der Werte zuständig sind.
Wann und wie wird das gemacht?

Wenn diese Counter starten, steigt meine CPU-Last um ca. 20%.

Das Starten der Counter allein kann wohl kaum zu erhöhter Last führen. Da werden ja lediglich ein paar Datenpunkte beschrieben. Interessanter dürfte der Teil der Scripte sein, den zu nicht zeigst.

[tourer4778]

@codierknecht
wie gesagt, das wird am ende des tages gemacht und ist in dem Moment nicht Aktiv.
Den Teil, der in History abgelegt wird, schließe ich aus, da ich diesen auch deaktiviert habe.

[Homoran]

@tourer4778 wenn ich das richtig sehe greifst du mit drei Skripten zeitgleich mehrfach auf die selben DP zu.

was steuerst du da für Geräte?

[tourer4778]

@homoran
Nein, das sind unterschiedlich DP, die sind in unterschiedlichen Ordnern.

Ich schreibe mir die Werte nur weg am Ende des Tages, Woche, Monat in History.
Gesteuert wird da nix an der stelle.

[OliverIO]

@tourer4778

Wie oft ändern sich denn diese Datenpunkte?
Wenn die Geräte das im 0,001 Bereich schon aktualisieren und das mehrfach pro sekunde, ist das oft nicht notwendig.
Ich glaube in den Datenpunkt Einstellungen kann man einen threshold ab welcher Abweichung ein Datenpunkt tatsächlich erst aufgezeichnet werden soll und damit natürlich auch getriggert

[Homoran]

@tourer4778 sagte in Manchmal hohe CPU Last:

Gesteuert wird da nix an der stelle.

warum dann "steuere"?

[OliverIO]

@tourer4778

Wie oft werden die Datenpunkte getriggert.
Wenn die Geräte Mini-Änderungen melden, und das mehrfach pro Sekunde obwohl diese Detaildaten nicht wirklich interessant sind, dann kann man bei den Datenpunkten einen trhesold eintragen. Dann werden die Daten nur geschrieben, wenn es eine Abweichung größer diesem Wert ist. Entsprechend weniger wird dann getriggert.

[tourer4778]

@homoran sagte in Manchmal hohe CPU Last:

warum dann "steuere"?

Entschuldige, (mein fehler) mein Verständnis für Steuern ist etwas anders.
An der Stelle werden halt nur die Counter in ein DP weggeschrieben zu einer bestimmten Uhrzeit.
In diesem DP ist Historie aktiv.

[tourer4778]

@oliverio
Unterschiedlich. Einmal am Tag, woche, Monat oder Jahr. Immer am Tagesende, also nicht interessant für dieses Problem.

[tourer4778]

Ich habe mal 5 Counter angelegt und lasse die nur starten und stoppen.
Die CPU Last Steigt beim starten um ca. 10%.

[Homoran]

@tourer4778 sagte in Manchmal hohe CPU Last:

Entschuldige, (mein fehler) mein Verständnis für Steuern ist etwas anders.

eher nicht!

@tourer4778 sagte in Manchmal hohe CPU Last:

werden halt nur die Counter in ein DP weggeschrieben z

dann nimm den "aktualisiere" Block!

der steuere Block ist zum steuern von Geräten über deren Adapter

[OliverIO]

@tourer4778

Wie können die Skripte dann Last erzeugen wenn sie nur einmal am Tag laufen?
Dann schaust du nach den falschen Skripte.

Bist du den sicher das die nur so selten laufen?

[tourer4778]

@homoran
Okay, danke.
"aktualisiere" zur Übergabe an History geht und teilweise umgesetzt, ändert erstmal aber nichts an der CPU Last, da ja die Übergabe am ende des Tages ist.