Jahresrückblick 2025 – unser neuer Blogbeitrag ist online! ✨

[klassisch]

@sigi234 genau diesen Speicherort. Da habe ich nichts verändert.

Histoy hat ja auch jede Menge Datenpunkte subscribiert bevor "Maximum call stack size exceeded" gemeldet wurde. Das Logfile war nach wenigen Zehnminuten bei >22MByte.
Ich habe mittlerweile ein 3 Tage altes Backup eingespielt und damit den Zustand vor meiner Erweiterung der zu archivierenden Datenpunkten wieder hergestellt. Jetzt läuft wieder alles ganz normal.
War leider nicht anders möglich. Man kann die Archivierung der Datenpunkte ja nur abwählen, wenn History läuft. Sobald History lief, wurde aber nach ein oder zwei Minuten ioBroker neu gestartet.
Anscheinend hatte ich den Rubicon von History überschritten.
Die nichtfunktionierende Größe war ja
Objekte: 9052, Zustände: 7094
Jetzt bin ich bei
Objekte: 8942, Zustände: 6984
Also nicht wirkich weit weg.
Das heißt ich muß mich jetzt wohl langsam nach einer Datenbanklösung umsehen....

[Stabilostick]

@klassisch

Das "*" im Dateinamen (weil State so heißt?) könnte Probleme bereiten... ist aber als Sonderzeichenbehandlung im Hosters-Adapter hinterlegt.

c:/ioBroker-data/History/20191026/history.hm-rpc.0.*LEQ01

[klassisch]

@Stabilostick Ja, das ist lästig und stört, war und ist nach dem bakup wieder, von lokaler Natur. Das wird angemeckert und in _LEQ geändert.
Das sind Rauchmedergruppen der alten HM Rauchmeder. An denen hatte ich auch nichts geändert.
Es gab mal ein Skript, um solche Sonderzeichen zu entfernen. Habe ich drüberlaufen lassen, hat aber nicht dauerhaft geholfen.
Habe es soeben nochmals appliziert

javascript.0	2019-10-27 02:58:59.187	info	script.js.common.Sonderzeichen: Found 0 problems
javascript.0	2019-10-27 02:58:59.187	info	script.js.common.Sonderzeichen: Checked 5900 devices, 6155 channels, 6962 states 

Vermute, daß die * aber wieder von HM rübergeschoben werden.

[Glasfaser]

@klassisch

Kann das sein , das du den gesamten Verlauf des Zustandes aufnimmst und nicht nur eine Änderung .

Dadurch wird die Datenbank auch sehr groß.

Hast du hier einen Haken drin ...

[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.