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

[klassisch]

@Glasfaser Danke, ja bei dem Gros der Objekte habe ich den Haken bei "Nur Änderungen aufzeichnen" drin. Es gibt einige Ausnahmen, vor allem RFLink 433MHz Billig Bewegungsmelder oder Tür-Fenser-Kontakte oder Wassermelder, weil die nur true senden, wenn sie getriggert werden.
An normalen Tagen - also nicht wenn ioBroker in der Restart-Loop hängt - kommen ca. 3 bis 10MByte zusammen. Das ist also kein Problem, das verkraftet die Notebook-HW problemlos.
Ich vermute, daß es irgendeine "Schallmauer" für die Gesamtzahl der Objekte oder der Suscriptionen gibt, die ich überschritten hatte.

[Stabilostick]

@klassisch

Bei dem Fehler „RangeError: Maximum call stack size exceeded at tryParse“ handelt es sich um ein Problem, das u.a. bei exzessiven rekursiven Funtionsaufrufen auftreten kann.

Bitte prüfe, bei welchem History-Datenpunkt Du z.B. alle 10s einen Wert schreibst, also die Menge an Datenpunktänderungen „sehr groß“ wird. Wie viel ist bei Dir „groß“ (z.B. Anzahl pro 24h)? Eventuell kannst Du das Problem an genau einem historisierten Datenpunkt festmachen.

Ich schlage vor, dass Du den history-Adapter vorübergehend auf „debug“ stellst und den Fehler weiter einkreist.

Eventuell kann hier auch @apollon77 etwas dazu sagen, wenn Du mehr Infos hast.

[apollon77]

Hey, also auch wenn die Liga seeeeehr rar sind (restart Loop sehe ich nirgendwo und so ....) ist meine Vermutung das der History Adapter nicht mehr hinterherkommt.
Da es ein Windows System ist gehe ich mal nicht von sd Karten aus also hätte ich erwartet das die schreib Performance nicht der Grund ist. Aber ich könnte mir vorstellen das I/o hier mit limitiert.

Ich hab eine Idee wie man das ggf verbessern kann. Bitte mal GitHub issue anlegen.

[klassisch]

@Stabilostick sagte in Restart-Loop: History Maximum call stack size exce:

@klassisch

Bei dem Fehler „RangeError: Maximum call stack size exceeded at tryParse“ handelt es sich um ein Problem, das u.a. bei exzessiven rekursiven Funtionsaufrufen auftreten kann.

Bitte prüfe, bei welchem History-Datenpunkt Du z.B. alle 10s einen Wert schreibst, also die Menge an Datenpunktänderungen „sehr groß“ wird. Wie viel ist bei Dir „groß“ (z.B. Anzahl pro 24h)? Eventuell kannst Du das Problem an genau einem historisierten Datenpunkt festmachen.

Alle 10 Sekunden habe ich nicht wissentlich und willentlich eingestellt. Vielleicht war das ein eventgesteuerter Eintrag. History generiert bei mir 3 bis 10 MByte pro Tag. In jenen paar Stunden waren es bereits 22MByte

Ich schlage vor, dass Du den history-Adapter vorübergehend auf „debug“ stellst und den Fehler weiter einkreist.

Da das mein Produktivsystem betraf habe ich mittlerweile ein Backup eingespielt und das Thema war vorbei. Damit ist natürlich auch die Forensik stark eingeschränkt. In den letzten 2 Tagen schrieb History ca. 3 bis 4 MByte pro Tag. Das ist "keine Last". Ich hatte auch Zeiten mit >50 MByte pro Tag an denen das System stabil lief.

Eventuell kann hier auch @apollon77 etwas dazu sagen, wenn Du mehr Infos hast.

Bei der Sichtung der History Daten ist mir etwas sehr seltsames aufgefallen.
Edit: Stop, da muß ich nochmals genauer nachschauen. sorry.

[apollon77]

Ps: du könntest auch mal js-Controller 2.0 versuchen. Da sollte das Problem nicht auftreten.

[klassisch]

@apollon77 sagte in Restart-Loop: History Maximum call stack size exce:

Hey, also auch wenn die Liga seeeeehr rar sind (restart Loop sehe icAh nirgendwo und so ....) ist meine Vermutung das der History Adapter nicht mehr hinterherkommt.

An der HW sollte das nicht liegen. i5-5300u 8GB RAM. und ich hatte schon deutlich größere Datenmengen pro Tag und das System war stabil.

Da es ein Windows System ist gehe ich mal nicht von sd Karten aus also hätte ich erwartet das die schreib Performance nicht der Grund ist. Aber ich könnte mir vorstellen das I/o hier mit limitiert.

SSD Crucial MX500 500GB und >500MB/s lesen und schreiben sequentiell lt CrystalDiskMark

Ich hab eine Idee wie man das ggf verbessern kann. Bitte mal GitHub issue anlegen.

Mach ich - gleich ... morgen. Sorry, heute bekomme ich das nicht mehr unter

[klassisch]

@apollon77 sagte in Restart-Loop: History Maximum call stack size exce:

Ps: du könntest auch mal js-Controller 2.0 versuchen. Da sollte das Problem nicht auftreten.

Danke für den Tipp. Ja, mache ich gerne. Sobald der neue Windows-Installer draussen ist. Oder gibts eine andere Möglichkeit den 2.0 auf Windows zu bekommen?

[Stabilostick]

@klassisch

Halt ein einzelnern (neuen) Datenpunkt, in dem Du z.B. >50.000 Ereignisse innerhalb von 24h geschrieben hast? kann ja auch ein irr gelaufenes JavaScript gewesen sein. Suche nach der größten Datei im history-Ordner und zähle die Zeilen ;-) Dann diesen DP deaktivieren, die Files löschen usw. zur Fehlereingrenzung - wenn das wieder passiert.

[Stabilostick]

@klassisch sagte in Restart-Loop: History Maximum call stack size exce:

andere Möglichkeit den 2.0 auf Windows

ioBroker Experimental: https://forum.iobroker.net/post/313664

[klassisch]

@Stabilostick Ja, genau das habe ich versucht. Aber dann waren es einfach nur viele mittelgroße <100kbyte. Keiner, der irgendwie besonders auffällig war. Und daß bei einer Restart Loop fast alle Datenpunkte zigmal angefaßt werden ist auch klar.
Noch mysteriös.

[klassisch]

@Stabilostick Vielen Dank! Dann werde ich das mal testen. Aber heute wird es nichts mehr. Und bei einer Testversion wäre ich gerne die ersten Stunden vor Ort. Also wahrscheinlich erst am WE.