Navigation

    Logo
    • Register
    • Login
    • Search
    • Recent
    • Tags
    • Unread
    • Categories
    • Unreplied
    • Popular
    • GitHub
    • Docu
    • Hilfe
    1. Home
    2. Deutsch
    3. Error/Bug
    4. Restart-Loop: History Maximum call stack size exce

    NEWS

    • Neuer Blog: Fotos und Eindrücke aus Solingen

    • ioBroker@Smart Living Forum Solingen, 14.06. - Agenda added

    • ioBroker goes Matter ... Matter Adapter in Stable

    UNSOLVED Restart-Loop: History Maximum call stack size exce

    This topic has been deleted. Only users with topic management privileges can see it.
    • K
      klassisch Most Active last edited by 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 1 Reply Last reply Reply Quote 0
      • sigi234
        sigi234 Forum Testing Most Active @klassisch last edited by

        @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?

        K 1 Reply Last reply Reply Quote 0
        • K
          klassisch Most Active @sigi234 last edited by klassisch

          @sigi234 genau diesen Speicherort. Da habe ich nichts verändert.
          ioBroker-History-storage-directory.JPG
          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 1 Reply Last reply Reply Quote 0
          • Stabilostick
            Stabilostick @klassisch last edited by 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
            
            K 1 Reply Last reply Reply Quote 0
            • K
              klassisch Most Active @Stabilostick last edited by

              @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 1 Reply Last reply Reply Quote 0
              • Glasfaser
                Glasfaser @klassisch last edited by 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 ...

                1.JPG

                K 1 Reply Last reply Reply Quote 0
                • K
                  klassisch Most Active @Glasfaser last edited by

                  @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 1 Reply Last reply Reply Quote 0
                  • Stabilostick
                    Stabilostick @klassisch last edited by 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.

                    K 1 Reply Last reply Reply Quote 0
                    • apollon77
                      apollon77 last edited by

                      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.

                      K 1 Reply Last reply Reply Quote 0
                      • K
                        klassisch Most Active @Stabilostick last edited by 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.

                        Stabilostick 1 Reply Last reply Reply Quote 0
                        • apollon77
                          apollon77 last edited by

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

                          K 1 Reply Last reply Reply Quote 0
                          • K
                            klassisch Most Active @apollon77 last edited by

                            @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

                            1 Reply Last reply Reply Quote 0
                            • K
                              klassisch Most Active @apollon77 last edited by

                              @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 1 Reply Last reply Reply Quote 0
                              • Stabilostick
                                Stabilostick @klassisch last edited by

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

                                K 1 Reply Last reply Reply Quote 0
                                • Stabilostick
                                  Stabilostick @klassisch last edited by

                                  @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

                                  K 1 Reply Last reply Reply Quote 0
                                  • K
                                    klassisch Most Active @Stabilostick last edited by

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

                                    1 Reply Last reply Reply Quote 0
                                    • K
                                      klassisch Most Active @Stabilostick last edited by

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

                                      1 Reply Last reply Reply Quote 0
                                      • First post
                                        Last post

                                      Support us

                                      ioBroker
                                      Community Adapters
                                      Donate

                                      376
                                      Online

                                      31.8k
                                      Users

                                      80.0k
                                      Topics

                                      1.3m
                                      Posts

                                      history restart windows 10
                                      5
                                      17
                                      614
                                      Loading More Posts
                                      • Oldest to Newest
                                      • Newest to Oldest
                                      • Most Votes
                                      Reply
                                      • Reply as topic
                                      Log in to reply
                                      Community
                                      Impressum | Datenschutz-Bestimmungen | Nutzungsbedingungen
                                      The ioBroker Community 2014-2023
                                      logo