Skip to content
  • Home
  • Aktuell
  • Tags
  • 0 Ungelesen 0
  • Kategorien
  • Unreplied
  • Beliebt
  • 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

  • Standard: (Kein Skin)
  • Kein Skin
Einklappen
ioBroker Logo

Community Forum

donate donate
  1. ioBroker Community Home
  2. Deutsch
  3. Entwicklung
  4. Adapter frisst Speicher

NEWS

  • Weihnachtsangebot 2025! 🎄
    BluefoxB
    Bluefox
    24
    1
    1.4k

  • UPDATE 31.10.: Amazon Alexa - ioBroker Skill läuft aus ?
    apollon77A
    apollon77
    48
    3
    9.3k

  • Monatsrückblick – September 2025
    BluefoxB
    Bluefox
    14
    1
    2.6k

Adapter frisst Speicher

Geplant Angeheftet Gesperrt Verschoben Entwicklung
5 Beiträge 3 Kommentatoren 626 Aufrufe
  • Älteste zuerst
  • Neuste zuerst
  • Meiste Stimmen
Antworten
  • In einem neuen Thema antworten
Anmelden zum Antworten
Dieses Thema wurde gelöscht. Nur Nutzer mit entsprechenden Rechten können es sehen.
  • K Offline
    K Offline
    Karl_999
    schrieb am zuletzt editiert von
    #1

    Heute habe ich meinen Adapter einmal einem kleinen Stresstest unterworfen und den Speicherverbrauch beobachtet.

    top sagt mir, dass in einer Stunde der unter VIRT gemeldete Speicher um ca. 1MByte gestiegen ist (von ca.130.000 auf 131.000).

    Das ist natürlich unschön und ich würde gerne die Ursache finden und beheben.

    Der Adapter läuft als Dämon und pollt zyklisch externe Werte.

    Dazu nehme ich folgendes Konstrukt (habe ich aus dem Solarlog-Adapter entnommen)

    adapter.on('ready', function() {
    
    	adapter.subscribeStates('disablePeriod');    
    	adapter.log.debug('[INFO] Starting adapter');
    
        let pollingTime = (adapter.config.pollCycle * 1000) || 300000;
    
        adapter.log.debug('[INFO] Configured polling cycle: ' + pollingTime);
    	if (!polling) {
    		polling = setTimeout(function repeat() { // poll states every [30] seconds
    			main();
    			setTimeout(repeat, pollingTime);
    		}, pollingTime);
    	};
    });
    
    

    Meine js-Erfahrungen sind nicht so wahnsinnig toll ausgeprägt.

    Wenn ich dieses Konstrukt am Ende betrachte, so ist das doch ein rekursiver Aufruf, der zunächst nach dem Timeout main() aufruft und danach wieder nach dem Timeout sich selbst und danach nach dem Timeout …

    Ansonsten wäre das Programm ja auch nach kurzer Zeit am Ende angelangt.

    Wenn das so wäre, dann kann ich mir den Effekt des wachsenden Speicherbedarfs natürlich erklären.

    Liege ich da richtig?

    Falls ja, wie macht man diese Poll-Schleife denn "richtig"?

    1 Antwort Letzte Antwort
    0
    • J Offline
      J Offline
      JoJ123
      schrieb am zuletzt editiert von
      #2

      Warum machst du den Adapter nicht so, dass er die Daten beim Ausfuhren einmal abruft und nutzt dann die Zyklische Ausführung die für jede Instanz einstellbar ist?

      Gesendet von meinem EML-L09 mit Tapatalk

      1 Antwort Letzte Antwort
      0
      • K Offline
        K Offline
        Karl_999
        schrieb am zuletzt editiert von
        #3

        Anfänglich hatte ich den Adapter als Schedule implementiert.

        Das hatte auch problemlos geklappt und vermeidet ein solches Problem.

        Allerdings kann ich dann den Adapter nur schwer steuernd nutzen (Absetzen von Kommandos).

        Dazu muss er einfach als Daemon laufen, um auf Ereignisse in vernünftiger Zeit reagieren zu können.

        Ich vermute, dass dieses Anforderung sicher viele Adapter haben: Reaktion auf Kommandos und (mehr oder weniger) zyklisches Lesen von Daten.

        1 Antwort Letzte Antwort
        0
        • J Offline
          J Offline
          JoJ123
          schrieb am zuletzt editiert von
          #4

          Du könntest auch setInterval verwenden, aber ob das wirklich besser ist weiß ich nicht genau.

          Gesendet von meinem EML-L09 mit Tapatalk

          1 Antwort Letzte Antwort
          0
          • apollon77A Offline
            apollon77A Offline
            apollon77
            schrieb am zuletzt editiert von
            #5

            setInterval ist Problematisch wenn externe Kommunikation stattfindet. setTimeout ist besser weil erst der nächste Zyklus geplant wird wenn der davor wirklich fertig ist.

            Aber mal zurück zum "Problem": Wo ist das eigentlich? EIne Stunde reicht nicht um hier Dinge zu testen. nodejs macht Garbage collection wie es will bzw wie es nötig ist, also erstmal alles ok.

            Weiterhin: Welche nodejs version? ALles <8.12 hat ein memory Leak :-)

            Das beste ist mal auf die heap/rss Datenpunkte unter system.adapter.name.x ein Logging (History(SQL/Influxdb) zu setzen und dann mal nach nem Tag mit Last zu schauen :-)

            Beitrag hat geholfen? Votet rechts unten im Beitrag :-) https://paypal.me/Apollon77 / https://github.com/sponsors/Apollon77

            • Debug-Log für Instanz einschalten? Admin -> Instanzen -> Expertenmodus -> Instanz aufklappen - Loglevel ändern
            • Logfiles auf Platte /opt/iobroker/log/… nutzen, Admin schneidet Zeilen ab
            1 Antwort Letzte Antwort
            0
            Antworten
            • In einem neuen Thema antworten
            Anmelden zum Antworten
            • Älteste zuerst
            • Neuste zuerst
            • Meiste Stimmen


            Support us

            ioBroker
            Community Adapters
            Donate

            725

            Online

            32.5k

            Benutzer

            81.7k

            Themen

            1.3m

            Beiträge
            Community
            Impressum | Datenschutz-Bestimmungen | Nutzungsbedingungen | Einwilligungseinstellungen
            ioBroker Community 2014-2025
            logo
            • Anmelden

            • Du hast noch kein Konto? Registrieren

            • Anmelden oder registrieren, um zu suchen
            • Erster Beitrag
              Letzter Beitrag
            0
            • Home
            • Aktuell
            • Tags
            • Ungelesen 0
            • Kategorien
            • Unreplied
            • Beliebt
            • GitHub
            • Docu
            • Hilfe