Skip to content
  • Home
  • Recent
  • Tags
  • 0 Unread 0
  • Categories
  • Unreplied
  • Popular
  • GitHub
  • Docu
  • Hilfe
Skins
  • Light
  • Brite
  • Cerulean
  • Cosmo
  • Flatly
  • Journal
  • Litera
  • Lumen
  • Lux
  • Materia
  • Minty
  • Morph
  • Pulse
  • Sandstone
  • Simplex
  • Sketchy
  • Spacelab
  • United
  • Yeti
  • Zephyr
  • Dark
  • Cyborg
  • Darkly
  • Quartz
  • Slate
  • Solar
  • Superhero
  • Vapor

  • Default (No Skin)
  • No Skin
Collapse
ioBroker Logo

Community Forum

donate donate
  1. ioBroker Community Home
  2. Deutsch
  3. Skripten / Logik
  4. JavaScript
  5. CPU Auslastung des JavaScript Adapters steigt kontinuierlich

NEWS

  • Jahresrückblick 2025 – unser neuer Blogbeitrag ist online! ✨
    BluefoxB
    Bluefox
    17
    1
    3.5k

  • Neuer Blogbeitrag: Monatsrückblick - Dezember 2025 🎄
    BluefoxB
    Bluefox
    13
    1
    1.1k

  • Weihnachtsangebot 2025! 🎄
    BluefoxB
    Bluefox
    25
    1
    2.5k

CPU Auslastung des JavaScript Adapters steigt kontinuierlich

Scheduled Pinned Locked Moved JavaScript
8 Posts 5 Posters 720 Views 5 Watching
  • Oldest to Newest
  • Newest to Oldest
  • Most Votes
Reply
  • Reply as topic
Log in to reply
This topic has been deleted. Only users with topic management privileges can see it.
  • M Offline
    M Offline
    mfroeschl
    wrote on last edited by mfroeschl
    #1

    Hallo,

    ich habe seit einigen Monaten das Problem, dass der JavaScript Adapter nicht mehr stabil läuft. Bisher habe ich mich damit beholfen, den Adapter alle 2-3 Tage neu zu starten, das nervt aber allmählich. Vorweg noch als Info, auch eine komplette Neuinstallation und anschließendes Restore des iobroker hat den Fehler nicht behoben. Der Fehler liegt also möglicherweise in einem Blockly-Skript das ich gebaut habe.

    Ich zeichne seit gestern Abend mit SQL die CPU Auslastung des Javascript Adapters auf:
    36fb99d1-bb04-42da-9cee-4eeb5b991148-grafik.png

    Die Auslastung steigt kontinuierlich an bis der Adapter bzw. die Skripte nach ca. 2 Tagen Laufzeit mit einer deutlichen Zeitverzögerung reagieren und schließlich gar nicht mehr funktionieren.

    Wie geht ich da jetzt ran um den Fehler zu finden? Ich habe insgesamt 25 Skripte die teils auch etwas länger sind. Gibt es einige "übliche Verdächtige" für diesen Fehler? Kann mir jemand weiterhelfen wenn ich die Skripte hier poste?

    Grüße
    Michael

    crunchipC arteckA 2 Replies Last reply
    0
    • M mfroeschl

      Hallo,

      ich habe seit einigen Monaten das Problem, dass der JavaScript Adapter nicht mehr stabil läuft. Bisher habe ich mich damit beholfen, den Adapter alle 2-3 Tage neu zu starten, das nervt aber allmählich. Vorweg noch als Info, auch eine komplette Neuinstallation und anschließendes Restore des iobroker hat den Fehler nicht behoben. Der Fehler liegt also möglicherweise in einem Blockly-Skript das ich gebaut habe.

      Ich zeichne seit gestern Abend mit SQL die CPU Auslastung des Javascript Adapters auf:
      36fb99d1-bb04-42da-9cee-4eeb5b991148-grafik.png

      Die Auslastung steigt kontinuierlich an bis der Adapter bzw. die Skripte nach ca. 2 Tagen Laufzeit mit einer deutlichen Zeitverzögerung reagieren und schließlich gar nicht mehr funktionieren.

      Wie geht ich da jetzt ran um den Fehler zu finden? Ich habe insgesamt 25 Skripte die teils auch etwas länger sind. Gibt es einige "übliche Verdächtige" für diesen Fehler? Kann mir jemand weiterhelfen wenn ich die Skripte hier poste?

      Grüße
      Michael

      crunchipC Away
      crunchipC Away
      crunchip
      Forum Testing Most Active
      wrote on last edited by crunchip
      #2

      @mfroeschl sagte in CPU Auslastung des JavaScript Adapters steigt kontinuierlich:

      Wie geht ich da jetzt ran

      50/50 Prinzip
      Die Hälften der Scripte deaktivieren, beobachten, dann die andere Hälfte um sich so langsam ranzutasten welches der Scripte das Problem verursachen könnte.

      Irgendwelche gebauten Schleifen, nicht beendete timeouts können dies z.b verursachen

      umgestiegen von Proxmox auf Unraid

      M 2 Replies Last reply
      0
      • M mfroeschl

        Hallo,

        ich habe seit einigen Monaten das Problem, dass der JavaScript Adapter nicht mehr stabil läuft. Bisher habe ich mich damit beholfen, den Adapter alle 2-3 Tage neu zu starten, das nervt aber allmählich. Vorweg noch als Info, auch eine komplette Neuinstallation und anschließendes Restore des iobroker hat den Fehler nicht behoben. Der Fehler liegt also möglicherweise in einem Blockly-Skript das ich gebaut habe.

        Ich zeichne seit gestern Abend mit SQL die CPU Auslastung des Javascript Adapters auf:
        36fb99d1-bb04-42da-9cee-4eeb5b991148-grafik.png

        Die Auslastung steigt kontinuierlich an bis der Adapter bzw. die Skripte nach ca. 2 Tagen Laufzeit mit einer deutlichen Zeitverzögerung reagieren und schließlich gar nicht mehr funktionieren.

        Wie geht ich da jetzt ran um den Fehler zu finden? Ich habe insgesamt 25 Skripte die teils auch etwas länger sind. Gibt es einige "übliche Verdächtige" für diesen Fehler? Kann mir jemand weiterhelfen wenn ich die Skripte hier poste?

        Grüße
        Michael

        arteckA Offline
        arteckA Offline
        arteck
        Developer Most Active
        wrote on last edited by
        #3

        @mfroeschl sagte in CPU Auslastung des JavaScript Adapters steigt kontinuierlich:

        Der Fehler liegt also möglicherweise in einem Blockly-Skript das ich gebaut habe.

        nicht möglicherweise sondern BESTIMMT

        schalte erstmal die Scripte aus die du im verdacht hast.. so wie @crunchip schon geschrieben hat

        zigbee hab ich, zwave auch, nuc's genauso und HA auch

        1 Reply Last reply
        0
        • crunchipC crunchip

          @mfroeschl sagte in CPU Auslastung des JavaScript Adapters steigt kontinuierlich:

          Wie geht ich da jetzt ran

          50/50 Prinzip
          Die Hälften der Scripte deaktivieren, beobachten, dann die andere Hälfte um sich so langsam ranzutasten welches der Scripte das Problem verursachen könnte.

          Irgendwelche gebauten Schleifen, nicht beendete timeouts können dies z.b verursachen

          M Offline
          M Offline
          mfroeschl
          wrote on last edited by
          #4

          @crunchip Alles klar, ich versuche das fehlerhafte Skript nach der obigen Methode zu finden.

          1 Reply Last reply
          0
          • crunchipC crunchip

            @mfroeschl sagte in CPU Auslastung des JavaScript Adapters steigt kontinuierlich:

            Wie geht ich da jetzt ran

            50/50 Prinzip
            Die Hälften der Scripte deaktivieren, beobachten, dann die andere Hälfte um sich so langsam ranzutasten welches der Scripte das Problem verursachen könnte.

            Irgendwelche gebauten Schleifen, nicht beendete timeouts können dies z.b verursachen

            M Offline
            M Offline
            mfroeschl
            wrote on last edited by
            #5

            @crunchip said in CPU Auslastung des JavaScript Adapters steigt kontinuierlich:

            Irgendwelche gebauten Schleifen,

            Hab den Fehler gefunden. Ich habe bei einem längeren Blockly-Skript versehentlich einen Trigger in einem Trigger platziert. Dies führt dann scheinbar zu dem schleichendem Anstieg der CPU-Last bishin zum Absturz des Javascript Adapters.

            b541fe6e-6112-49b0-a5a2-92b7dbd3f4f2-grafik.png

            Wäre vielleicht eine mögliche Verbesserung des Adapters wenn hier eine Warnung ausgegeben würde oder man irgendwie anderweitig darauf hinweist dass das so nicht möglich ist - zumal der Fehler erst nach Tagen des scheinbar fehlerfreien Betriebs auftritt.

            Danke an euch für die Tipps zur Fehlersuche.

            OliverIOO 1 Reply Last reply
            0
            • M mfroeschl

              @crunchip said in CPU Auslastung des JavaScript Adapters steigt kontinuierlich:

              Irgendwelche gebauten Schleifen,

              Hab den Fehler gefunden. Ich habe bei einem längeren Blockly-Skript versehentlich einen Trigger in einem Trigger platziert. Dies führt dann scheinbar zu dem schleichendem Anstieg der CPU-Last bishin zum Absturz des Javascript Adapters.

              b541fe6e-6112-49b0-a5a2-92b7dbd3f4f2-grafik.png

              Wäre vielleicht eine mögliche Verbesserung des Adapters wenn hier eine Warnung ausgegeben würde oder man irgendwie anderweitig darauf hinweist dass das so nicht möglich ist - zumal der Fehler erst nach Tagen des scheinbar fehlerfreien Betriebs auftritt.

              Danke an euch für die Tipps zur Fehlersuche.

              OliverIOO Offline
              OliverIOO Offline
              OliverIO
              wrote on last edited by OliverIO
              #6

              @mfroeschl
              Bei blockly weiß ich nicht, aber bei JavaScript kann sowas durchaus möglich sein.
              Da blockly intern auch wieder zu JavaScript übersetzt wird gilt das aber dennoch
              Allerdings kann die js Engine von gewollt und nicht gewollt nicht unterscheiden
              Problem ist der Entwickler ist dafür verantwortlich die Events aufzuräumen und auch den dafür verwalteten Speicher frei zu geben.

              Die beste Lösung dafür wäre, das der JavaScript Adapter je Script den verbrauchten Speicher und ggfs. auch den CPU Anteil je Script in datenpunkten aufzuzeichnen
              Aktuell geht das nur für den gesamtspeicher des Adapters
              Ich weiß leider nicht ob dies die zugrundeliegende Bibliothek vm2 das kann.

              Meine Adapter und Widgets
              TVProgram, SqueezeboxRPC, OpenLiga, RSSFeed, MyTime,, pi-hole2, vis-json-template, skiinfo, vis-mapwidgets, vis-2-widgets-rssfeed
              Links im Profil

              W 1 Reply Last reply
              0
              • OliverIOO OliverIO

                @mfroeschl
                Bei blockly weiß ich nicht, aber bei JavaScript kann sowas durchaus möglich sein.
                Da blockly intern auch wieder zu JavaScript übersetzt wird gilt das aber dennoch
                Allerdings kann die js Engine von gewollt und nicht gewollt nicht unterscheiden
                Problem ist der Entwickler ist dafür verantwortlich die Events aufzuräumen und auch den dafür verwalteten Speicher frei zu geben.

                Die beste Lösung dafür wäre, das der JavaScript Adapter je Script den verbrauchten Speicher und ggfs. auch den CPU Anteil je Script in datenpunkten aufzuzeichnen
                Aktuell geht das nur für den gesamtspeicher des Adapters
                Ich weiß leider nicht ob dies die zugrundeliegende Bibliothek vm2 das kann.

                W Online
                W Online
                Wildbill
                wrote on last edited by
                #7

                @oliverio Trigger in Trigger kann ja eigentlich nicht gewollt sein. Ergibt ja irgendwie auch keinen Sinn?!

                Gruss, Jürgen

                OliverIOO 1 Reply Last reply
                0
                • W Wildbill

                  @oliverio Trigger in Trigger kann ja eigentlich nicht gewollt sein. Ergibt ja irgendwie auch keinen Sinn?!

                  Gruss, Jürgen

                  OliverIOO Offline
                  OliverIOO Offline
                  OliverIO
                  wrote on last edited by OliverIO
                  #8

                  @wildbill
                  hm mir würde da schon was einfallen.
                  du hast einen ein und Ausschalter
                  und nur wenn der an ist, dann willst du auf bestimmte datenpunkte horchen?

                  klar kann man das auch anders lösen, dann müsste man auf jedes Ereignis der betroffenen datenpunkte horchen und prüfen ob der ein und Ausschalter gesetzt ist. wenn da aber sehr viele Ereignisse auftreten ist es ressourcenschonender wenn man den/die trigger erst mit EIN setzt.

                  Wenn man sorgsam ist, dann geht das schon.
                  viele node bibliotheken sind so programmiert
                  bspw siehe beispiel bei
                  https://nodejs.org/api/http.html#httprequesturl-options-callback
                  dort wird async der request eröffnet (1.trigger) und danach hörst du optional auf weitere trigger/events (data,error,end,etc)
                  daher musst du am ende auch noch end aufrufen um das alles wieder aufzuräumen.

                  wie oben schon gesagt, weiß ich nicht wie sich das in blockly auswirkt bzw. wie man in blockly einen trigger wieder deaktiviert bzw. sorge dafür trägt, das man sich die trigger signatur merkt um sie wieder abzustellen.

                  Meine Adapter und Widgets
                  TVProgram, SqueezeboxRPC, OpenLiga, RSSFeed, MyTime,, pi-hole2, vis-json-template, skiinfo, vis-mapwidgets, vis-2-widgets-rssfeed
                  Links im Profil

                  1 Reply Last reply
                  0
                  Reply
                  • Reply as topic
                  Log in to reply
                  • Oldest to Newest
                  • Newest to Oldest
                  • Most Votes


                  Support us

                  ioBroker
                  Community Adapters
                  Donate

                  702

                  Online

                  32.7k

                  Users

                  82.4k

                  Topics

                  1.3m

                  Posts
                  Community
                  Impressum | Datenschutz-Bestimmungen | Nutzungsbedingungen | Einwilligungseinstellungen
                  ioBroker Community 2014-2025
                  logo
                  • Login

                  • Don't have an account? Register

                  • Login or register to search.
                  • First post
                    Last post
                  0
                  • Home
                  • Recent
                  • Tags
                  • Unread 0
                  • Categories
                  • Unreplied
                  • Popular
                  • GitHub
                  • Docu
                  • Hilfe