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

[klassisch]

Systemdata	Bitte Ausfüllen
Hardwaresystem:	i5-5300U; 8GB RAM; 500GB; Lenovo X250
Arbeitsspeicher:	5GB
Festplattenart:	500GB SSD
Betriebssystem:	Windows 10 Pro 1903 aktuell
Node-Version:	10.16.3
Nodejs-Version:	v10.16.3
NPM-Version:	6.9.0
Installationsart:	Installer @Stabilostick
Image genutzt:	Installer
Ort/Name der Imagedatei:	Installer 1.5.14

Vorgeschichte:

• Vor einigen Tagen einige zusätzliche Datenpunkte zu hystory aufgenommen. Lief aber alles
• Heute wegen update Rechner und damit ioBroker neu gestartet

Problem
Neustart wird unendlich wiederholt.
Irgedwann erscheint im Log die Meldung

admin.0	2019-10-26 08:12:47.241	info	terminating http server on port 8081

Auffälligkeit:

history.0	2019-10-26 08:11:29.571	error	exception by stop: Cannot read property 'push' of undefined
history.0	2019-10-26 08:11:29.571	error	Cannot store file c:/ioBroker-data/History/20191026/history.hm-rpc.0.*LEQ0122987.1.STATE.json: Error: ENOENT: no such file or directory, open 'c:/ioBroker-data/History/20191026/history.hm-rpc.0.*LEQ01
history.0	2019-10-26 08:11:29.571	error	Cannot store file c:/ioBroker-data/History/20191026/history.hm-rpc.0.*LEQ0122987.1.INSTALL_TEST.json: Error: ENOENT: no such file or directory, open 'c:/ioBroker-data/History/20191026/history.hm-rpc.0
history.0	2019-10-26 08:11:29.571	error	Cannot store file c:/ioBroker-data/History/20191026/history.hm-rpc.0.*LEQ0035264.1.STATE.json: Error: ENOENT: no such file or directory, open 'c:/ioBroker-data/History/20191026/history.hm-rpc.0.*LEQ00
history.0	2019-10-26 08:11:29.571	error	Cannot store file c:/ioBroker-data/History/20191026/history.hm-rpc.0.*LEQ0035264.1.INSTALL_TEST.json: Error: ENOENT: no such file or directory, open 'c:/ioBroker-data/History/20191026/history.hm-rpc.0
history.0	2019-10-26 08:11:29.571	error	Cannot store file c:/ioBroker-data/History/20191026/history.hm-rpc.0.*IEQ0509515.1.STATE.json: Error: ENOENT: no such file or directory, open 'c:/ioBroker-data/History/20191026/history.hm-rpc.0.*IEQ05
history.0	2019-10-26 08:11:29.571	error	Cannot store file c:/ioBroker-data/History/20191026/history.hm-rpc.0.*IEQ0509515.1.INSTALL_TEST.json: Error: ENOENT: no such file or directory, open 'c:/ioBroker-data/History/20191026/history.hm-rpc.0
history.0	2019-10-26 08:11:29.571	error	RangeError: Maximum call stack size exceeded at tryParse (C:\Program Files\iobroker\ioBrMain2\node_modules\socket.io-parser\index.js:336:12) at decodeString (C:\Program Files\iobroker\ioBrMain
history.0	2019-10-26 08:11:29.570	error	uncaught exception: Maximum call stack size exceeded```
code_text

Die Fehlermeldungen wegen der "*" in den Verknüpfungsnamen der Rauchmelder sind normal. Die hatte ich immer, obwohl ich das Sonderzeichenskript schon habe durchlaufen lassen.
Aber die anderen, insbes Stack overflow sind neu.
Das scheint dann zu einer Restart loop zu führen.
Wenn ich History 1.8.6 disable läuft ioBroker wieder und die Restart-Loop ist beendet.
History 1.8.6
Datenbasis: Objekte: 9052, Zustände: 7094
Was kann ich tun?

[sigi234]

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

c:/ioBroker-data/History/

Ist das Richtig?
Was hast du im History Adapter für einen Speicherort eingegeben?

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