Navigation

    Logo
    • Register
    • Login
    • Search
    • Recent
    • Tags
    • Unread
    • Categories
    • Unreplied
    • Popular
    • GitHub
    • Docu
    • Hilfe
    1. Home
    2. Deutsch
    3. Error/Bug
    4. Steigende RAM Auslastung von Compact / Adapter Prozessen

    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 Steigende RAM Auslastung von Compact / Adapter Prozessen

    This topic has been deleted. Only users with topic management privileges can see it.
    • T
      ToGe88 Developer last edited by

      Systemdata Bitte Ausfüllen
      Hardwaresystem: Raspberry Pi3 / Pi4
      Arbeitsspeicher: 1GB / 4Gb
      Festplattenart: SD-Karte
      Betriebssystem: Raspbian Buster
      Node-Version: 10.21.0
      Nodejs-Version: 10.21.0
      NPM-Version: 6.14.4
      Installationsart: Skript
      Image genutzt: Nein
      Ort/Name der Imagedatei: /

      Hallo,

      mir ist im Verlauf der letzten Wochen bei meinen 2 ioBroker Servern folgendes Problem aufgefallen:
      Über den Verlauf von ca. 10-14 Tagen wächst die RAM-Auslastung von Compact Gruppen sowie auch Node Adapterprozessen langsam aber stetig weiter an. Dies führt dazu das die Systeme irgendwann den Swap Speicher nutzen und wenn dieser voll ist die Prozesse durch den OOM Killer beendet werden. Manchmal führt es nur zum neustart des Adapterprozesses einige male aber auch schon zum kompletten Neustart vom ioBroker. Auf dem Rpi3 mit nur 1Gb RAM tritt das Problem dementsprechend schneller auf.

      Zu Beginn hatte ich die Adapter in Compact Gruppen zusammengefasst, meine Vermutung war das dies evtl das Problem auslöst also habe ich diese aufgelöst. Durch das Protokollieren der Datenpunkte memHeapTotal, memHeapUsed und memRss für alle Adapter ist mir dann aufgefallen dass alle Adapter welche nicht zeitgesteuert gestartet werden über die Zeit immer mehr Speicher unter memRss reservieren obwohl memHeapTotal und Used eigentlich auf dem gleichen Niveau bleiben.

      Als Lösungsmöglichkeit habe ich versucht über die Expertenansicht für alle Prozesse ein RAM-Limit im Bereich der RAM-Auslastung nach ca 24 Stunden Laufzeit zu definieren. Die Node Prozesse werden auch korrekt mit dem Parameter --max-old-size gestartet, dementsprechend sollte die Garbage Collection von Node auch häufiger greifen und nicht mehr referenzierte Objekte und Variablen im Speicher freigeben. Leider führte das auch nicht zum Erfolg, die Adapterprozesse überschreiten das eingestellte Limit und wachsen weiter an mit gleichbleibender Problematik.

      Hier einige Grafiken der Auslastungsverläufe:

      Verlauf vom Alexa2 Adapter über 3 Tage (RPI4)
      alexa2.png
      Verlauf vom Broadlink Adapter über 3 Tage (RPI4)
      broadlink.png
      Verlauf vom Zwave2 Adapter über 3 Tage (RPI4), dieser Adapter scheint sich nach ca 3 Tagen einzupegeln und beansprucht dann keinen weiteren Ram! (Evtl Unterschied in der Programmierung zu anderen Adaptern? Die kleinen Einbrüche scheinen evtl. eine Art internes Speichermanagement zu sein welches dort greift.)
      zwave2.png
      Verlauf vom Nina Adapter über 3 Tage (RPI4), hier habe ich mit automatischen Neustarts des Adapter experimentiert, der starke Einbruch in der Mitte ist ein manueller Neustart via Admin Oberfläche. Wie man sieht scheinen die zeitgesteuerten Neustarts den Speicher nicht komplett wie ein manueller Neustart freizugeben.
      nina.png
      Zum Vergleich der Prozess vom JS-Controller (RPI4), hier scheint alles in Ordnung zu sein.
      js-controller.png

      Der Verlauf der gesamten Speicherauslastung vom Raspberry 3 über ca. 3 Monate, die Einbrüche sind der Moment wenn der OOM-Killer aktiv wird, dazwischen aber auch einige manuelle Neustarts.
      raspberry.png

      Vielleicht hat jemand von den Experten eine Idee was man hier tun könnte bzw. ob das Problem überhaupt am ioBroker liegt oder eher an Node selbst. (Hier findet man nämlich ähnliche Einträge im Zusammenhang mit Memory Leaks)

      Thomas Braun AlCalzone 2 Replies Last reply Reply Quote 0
      • Thomas Braun
        Thomas Braun Most Active @ToGe88 last edited by Thomas Braun

        @ToGe88
        Ich würde beide Systeme unter node12 laufen lassen.
        Und auch checken ob beide im RunLevel 3 laufen.

        T 1 Reply Last reply Reply Quote 0
        • T
          ToGe88 Developer @Thomas Braun last edited by

          @Thomas-Braun Das wäre ein Versuch, mit der aktuell genutzten Node10 Version hatte ich allerdings auch keine Probleme mehr im Internet gefunden bzgl. Memoryleaks, nur mit vorrigen versionen. Ist da was bekannt? Die System laufen beide im Runlevel 3.

          Thomas Braun 1 Reply Last reply Reply Quote 0
          • Thomas Braun
            Thomas Braun Most Active @ToGe88 last edited by

            @ToGe88
            Ich würde es auf jedenfall umstellen. Ist auf einem vernünftig konfiguriertem apt (Buster) doch auch eine Sache von 2 Minuten. Am längsten dauert der Download und der Neustart vom ioBroker.

            T 1 Reply Last reply Reply Quote 0
            • T
              ToGe88 Developer @Thomas Braun last edited by

              @Thomas-Braun So ich habe das Update auf Node12 gemacht, werde mal weiter beobachten wie es sich verhält. Schonmal danke für den Tipp!

              1 Reply Last reply Reply Quote 0
              • AlCalzone
                AlCalzone Developer @ToGe88 last edited by

                @ToGe88 sagte in Steigende RAM Auslastung von Compact / Adapter Prozessen:

                Verlauf vom Zwave2 Adapter über 3 Tage (RPI4), dieser Adapter scheint sich nach ca 3 Tagen einzupegeln und beansprucht dann keinen weiteren Ram!

                Interessant - du hast nicht zufällig Achsenbeschriftungen? 😉
                Dass es sich einpegelt könnte daran liegen, dass Geräte erst nach und nach aktuelle Werte senden. Der Adapter hält alle im RAM vor, sodass er ggf. tatsächlich erst nach 2-3 Tagen alle hat.

                Die Einbrüche wiederum können vieles sein:

                • Garbage-Collection von Node.js
                • etwas, das nach dem Aufwachen von einzelnen Geräten passiert

                Ich hatte auch mal ein ähnliches Thema, da war es tatsächlich eine Node.js-Version mit Memory-Leak. Interessanterweise hat sich dieser nur bei einem Adapter niedergeschlagen, der es quasi für alle anderen geschultert hat.

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

                Support us

                ioBroker
                Community Adapters
                Donate

                872
                Online

                31.9k
                Users

                80.1k
                Topics

                1.3m
                Posts

                adapter memoryleak ram
                3
                6
                543
                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