Viele SetStates global schädlich?
-
Der Javascrit Adapter überwacht ja seit Version 6.? ob mehr als 1000 SetStates pro Minute gemacht werden und schaltet dann das Skript ab um das System zu schützen.
Ist das auch bei anderen Adaptern schädlich? Wenn ich z.B. einen Leistungsmesser habe, dann aktualisiert der ja auch z.T. sekündlich und wenn ich 16 Steckdosen überwache komme ich auch auf mehr als 1000 Datenpunktänderungen pro Minute. (Zumal ja of neben der Leistung auch die Stromstärke etc. gleich mit übermittelt wird). -
@wolfgangfb sagte in Viele SetStates global schädlich?:
Ist das auch bei anderen Adaptern schädlich?
Was heißt schädlich?
Das ist nur ein Indikator dafür, dass man SEHR viel schreibt. Das Limit kann man in der Instanz vom JavaScript-Adapter ja auch hochsetzen. Ob das sinnvoll ist, hängt vom Anwendungsfall ab.
-
@haus-automatisierung
Na ja, ich habe festgestellt, dass wenn tatsächlich ein Skript bei mir schlecht programmiert war und eben mehr aals 1000 Schreibvorgänge gemacht hat, das System tatsächlich ausgebremst worden ist. Von daher frage ich mich wie "schädlich" es z.B. bei einem Sensor in ESPHome das update_interval auf eine niedrige Zeit zu stellen. -
@wolfgangfb sagte in Viele SetStates global schädlich?:
wenn tatsächlich ein Skript bei mir schlecht programmiert war und eben mehr aals 1000 Schreibvorgänge gemacht hat
Wieviele denn pro Sekunde? Wenn man z.B. eine While-Schleife baut, und mit voller Rechenleistung Datenpunkte schreibt, dann ist das sicher nicht gut.
"Mehr als 1.000" wären aber z.B. auch 2.000 pro Minute - und das sollte jedes System locker packen.
Es gibt ja auch die Benchmark-Auswertungen für diverse Systeme: https://forum.iobroker.net/topic/50634/beantwortet-iobroker-benchmark-und-nun/14?_=1692183497724
Ein NUC8 mit Intel i5 schafft z.B. 3500 setState pro Sekunde. Also 210.000 pro Minute. Modernere Systeme nochmal deutlich mehr.
-
ich glaube 1000 setStates pro Minute für 1 Skript ist schon eine recht hohe Zahl
die Überschreitung dürfte meist wirklich nur auf einen Skriptfehler zurückzuführen zu sein.
Gerade mit den Timern (setInterval/setTimeout) holt man sich bei verschachtelten Funktionsaufrufen schon gleich immer mehr rein, diese verbrauchen Ressourcen und wenn man sich den Timerhandle nicht speichert, kommt man da nicht mehr dran.Die Frage ist auch mit welcher hohen Auflösung den Daten tatsächlich aufgezeichnet werden müssen. Nur weil ein Gerät evtl. Temperaturschwankungen mehrmals pro Sekunde meldet, ist das dann wirklich sinnvoll?
Wenn ein Skriptprogrammierer dann tatsächlich mal mehr pro Minute schreiben will, dann kann er ja das Limit explizit anpassen (evtl bei den Skripten, die aus JSON mehrere Datenpunkte beschreiben. Aber auch hier 1000 ist eine verdammt hohe Zahl dafür. -
@oliverio sagte in Viele SetStates global schädlich?:
Aber auch hier 1000 ist eine verdammt hohe Zahl dafür.
Genau, in den meisten Fällen hat dann man einfach etwas falsch gemacht oder schlecht umgesetzt. Das heißt aber nicht, dass die 1000 Schreibvorgänge das System an das Limit bringen würden.
Bei der Grenze geht es ja mehr darum, dass man als Benutzer nochmal genauer hinschaut und darauf Aufmerksam wird.
-
also mit dem limit.,
ich hatte mal in einem widget zu meinen adapter einen fehler eingebaut,
bei dem sich das schreiben der datenpunkte hochgeschaukelt hat.
da ist dann nach einer weile der web adapter abgestürzt und wurde neu gestartet. das wiederholte sich dann immer wieder.
ist zwar kein skript des javascript adapters gewesen, aber der gleiche effekt.
es kann zwar nix physisch kaputt gehen, aber iobroker kann dann schon wegen Auslastung nicht mehr richtig benutzbar werden, insbesondere auf schwächeren systemen wie raspberrydas schreiben eines states im iobroker ist ja nicht einfach nur das ändern eines wertes in einer speicherposition. da der iobroker ein middlewaresystem ist, prüft es dann ja auch gleich wer die die states abonniert hat und informiert diese geräte dann über die änderungen.
das ist ein ständiges hin und her an informationen, deren Abarbeitung dann gestört ist
