Adapter frisst Speicher

[Karl_999]

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

[JoJ123]

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

[Karl_999]

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.

[JoJ123]

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

Gesendet von meinem EML-L09 mit Tapatalk

[apollon77]

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