RAM Auslastung steigt immer weiter
Eldarion85 opened this issue · comments
Describe the bug
Moin, gestern Abend hat meine Hausautomation Alarm geschlagen, weil der Arbeitsspeicher meines ioBroker über 70% ausgelastet war. In der Visualisierung habe ich gesehen, dass der Smartmeter-Adapter 22% (880 MB) des RaspberryPi 4GB belegt hat. Ich bin dann auf das Issue #247 gestoßen. Allerdings war da ein Update von Node.JS V12 auf V14 die Lösung. Ich könnte jetzt den Adapter neu installieren, ein Update auf V16 machen, oder ganz hässlich, ein Skript schreiben, was den Adapter bei einer bestimmten Auslastung des Speichers einmal neustartet. Aber evtl. seid ihr ja an einer Fehlersuche interessiert, bevor ich das mache :).
Nach dem Neustart um ca. 19 Uhr waren es dann wieder 57 MB. Allerdings hat sich das bis heute morgen innerhalb von 10 Stunden wieder auf 81 MB aufgebaut.
Wenn man sich die Kurve anschaut vermute ich, dass sich das über eine lange Zeit langsam aufbaut
Gruß
Marco
Interesant ... Bitte als erstes mal Node.js auf mindestens 16 oder gleich aktuelle 18.x updaten und dann neu beobachten ob es immer noch passiert. Wäre interessant ob. Bei mir laufen 2 instanzen dauerhaft und es gibt keine solchen Probleme ...
Evtl. würde ja auch eine Neuinstallation vom Adapter schon helfen, aber in beiden Fällen findet man danach doch nicht mehr raus woran es lag?!
Ich wollte ohnehin die Tage auf Node.js v16 hoch, weil v18 offiziell ja noch nicht freigeben ist. Aber wenn du sagst das ist kein Problem, gehe ich direkt auf die v18???
Btw ist eigentlich für ein Upgrade von Node.js nur wichtig, dass der js-Controller vom ioBroker dafür freigegeben ist, oder muss man sich die laufenden Instanzen/Adapter vorher auch alle anschauen? Anders gefragt, wenn der js-Controller für v16 freigegeben ist, kann ich mir dann sicher sein, dass die Adapter darunter auch damit klar kommen?
Besten Dank!
Was soll sich durch neuinstallation des Adapters ändern? Die Files die da kommen sind die gleichen.
Nodejs 18 ist ok, WENN js-controller 4.0.24 ist !! Sonst geh auch 16. Und ja mache die Tage den Forum thread nochmal neu
Effektiv kann es Adapter geben die in neueren versionen nicht gehen, aktuell ist aber wenig bekannt... Am Ende schau das alle Adpater die aktuellenversionen haben.. Rest mus man dann spezifisch ansehen
Moin,
ich habe gestern auf Node.js v18.13.0 und NPM 8.13.3 hochgerüstet. Erstmal vorweg, alle 13 Adapter laufen wieder. Allerdings ist die Instanz von Smartmeter wieder innerhalb von 14 Stunden von 57 MB auf 83 MB hochgelaufen. Wäre natürlich möglich das beruhigt sich da jetzt irgendwo, aber davon gehe ich nicht wirklich aus. Alle anderen Adapter liegen stabil zwischen 60-90 MB.
Hast du eine Idee woher das kommen kann oder einen Ansatz für die Fehlersuche?
Besten Dank!
Bitte beobachte es mal ... meine instanzen liegen auch bei knapp unter 100MB ... aber stabil dort ... Da fliessen halt einige Daten durch und der Garbage Collector von Node.js/Javascript räumt halt auch nur Dinge weg wenn er es für nötig hält.
Auch bei mir zieht der smartmeter Adapter immer mehr RAM. Ich starte mit 70MB und es steigt und steigt bei 400MB kille ich den adapter per Hand. Es gibt irgendwo nen Memory Leak. Das ganze passiert um so schneller um so häufiger man die Daten abfragt. Wenn ich das Datenabfrageintervall auf 1s setze - kann ich fast zusehen, wie der RAM steigt.
Hallo,
das Upgrade von Node.js hat leider nicht geholfen. Der Smartmeter-Adapter ist nach 2,5 Tagen Laufzeit wieder von 57 auf 117 MB hochgelaufen. Ich werde kommende Woche meine drei Pi´s auf einen Server mit Proxmox umziehen und komplett neu einrichten. Wenn ich vorher aber noch was prüfen soll, was dir bei der Fehlersuche hilft, sag gerne Bescheid.
Bei mir sind es sogar +75MB pro 24 Stunden... habe schon eine RAM Grenze für den Adapter festgelegt aber das scheint auch nichts zu bringen...
Ich habe die Aktualisierung auf 5 Sekunden. Bei was stehst du? Hattest ja oben geschrieben es hängt damit zusammen wo der Wert steht.
ah OK - ich habe 1s - und verwende das offizielle Docker Image - Node kann ich da eh nicht Aktualisieren.
sehr interessant ... bitte mal hier schreiben welche protokolle (Do/SML) bzw seriel read/read-write und so ihr nutzt ... muss ich mir in ruhe ansehen, kann bissl dauern
Hallo,
kurzes Update zu dem Issue!
Ich habe jetzt unter Proxmox (oben das lief noch auf einem Pi 4 über die GPIO) einen komplett neuen ioBroker (keine Backups) aufgesetzt und danach eine neue Instanz von Smartmeter installiert. Bei dem Server mit Proxmox nutze ich einen neuen Lesekopf (statt UART jetzt USB). Das Ergebnis ist das gleiche, der Arbeitsspeicher läuft immer weiter voll. Das ist jetzt bei Proxmox und 64GB RAM natürlich erstmal egal, aber irgendwo ist da ein Speicherleck.
Viele Grüße
Interessant das es dich trifft ... mein sytem ist stabil mit SML seit jahren. Wenn ich zeit finde schaue ich. Ich denke ein täglicher restart hilft dir erstmal. Und Danke für das Update!
Bei mir tritt es ebenfalls weiterhin auf. Habe nun einen Crow mit täglichen restart eingerichtet. Es ist def ein Memory leak, weil der Anstieg maßgeblich vom ausleseinterval abhängt.
Ich bin von dem Problem ebenfalls betroffen. Bis vor 2 Monaten hatte ich das D0-Protokoll verwendet. Da trat es m.E. nicht auf. Dann habe ich eine neue Instanz mit SML eingerichtet und seitdem das Memory-Problem. Die Instanz läuft auf einem ioBroker Slave. Das ist ein RasPi4. Details habe ich angehängt,
Plattform: linux
Betriebssystem: linux
Architektur: arm
CPUs: 4
Geschwindigkeit: 600 MHz
Modell: ARMv7 Processor rev 3 (v7l)
RAM: 3.7 GB
System-Betriebszeit: 37 T. 22:42:58
Node.js: v16.18.0
time: 1688380873297
timeOffset: -120
Adapter-Anzahl: 476
NPM: 8.19.2
Datenträgergröße: 29.0 GB
Freier Festplattenspeicher: 20.9 GB
Betriebszeit: 37 T. 23:20:35
Aktive Instanzen: 5
Pfad: /opt/iobroker/
aktiv:
Ok, dann muss ich wohl in die SML Lib mal tief reinschauen. Und genau das wird es dann interessant weil ich inzwischen nur noch D0 habe ist es auch nie aufgefallen. naja mal schauen. Bitte ggf einmal täglich Adaoter neu starten bis ich zeit gefunden habe da mal zu suchen
Vielen Dank für die Mühe!
Jahrelang hatte ich D0 in Verbindung mit meinem Zähler GS303 im Einsatz. memRSS war stabil bei 76 MB. Leider hat der Zähler über D0 nicht die Momentanleistung geliefert. Jetzt kam PV (nur BKW) auf's Carportdach und ich wollte bei Überschuss eine Last (Poolpumpe) zuschalten. Daher habe ich auf SML umgestellt, weil mir damit der Zähler die Momentanleistung liefert. Also reine Energieeffizienzgründe.
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs within the next 7 days. Please check if the issue is still relevant in the most current version of the adapter and tell us. Also check that all relevant details, logs and reproduction steps are included and update them if needed. Thank you for your contributions.
Dieses Problem wurde automatisch als veraltet markiert, da es in letzter Zeit keine Aktivitäten gab. Es wird geschlossen, wenn nicht innerhalb der nächsten 7 Tage weitere Aktivitäten stattfinden. Bitte überprüft, ob das Problem auch in der aktuellsten Version des Adapters noch relevant ist, und teilt uns dies mit. Überprüft auch, ob alle relevanten Details, Logs und Reproduktionsschritte enthalten sind bzw. aktualisiert diese. Vielen Dank für Eure Unterstützung.
Still valid - still an issue.
Ja, das Problem besteht nach wie vor. Bei meinen Angaben vom 3.7.2023 betrug das memRSS Wachstum ca. 17 MB pro Tag. Im August hat der Raspi4 ein Update des Betriebssystems und Node.JS erhalten. Danach liegt die Leckrate jetzt bei 6,5 MB pro Tag (linear). Die Änderung sieht man im Chart sehr schön.
Die aktuellen Systemdaten sind:
Plattform: linux
Betriebssystem: linux
Architektur: arm
CPUs: 4
Geschwindigkeit: 1500 MHz
Modell: ARMv7 Processor rev 3 (v7l)
RAM: 3.7 GB
System-Betriebszeit: 62 T. 04:45:59
Node.js: v18.17.0
time: 1697389120982
timeOffset: -120
NPM: 9.6.7
Adapter-Anzahl: 504
Datenträgergröße: 29.0 GB
Freier Festplattenspeicher: 17.5 GB
Aktive Instanzen: 4
Pfad: /opt/iobroker/
Betriebszeit: 16 T. 22:27:07
aktiv:
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs within the next 7 days. Please check if the issue is still relevant in the most current version of the adapter and tell us. Also check that all relevant details, logs and reproduction steps are included and update them if needed. Thank you for your contributions.
Dieses Problem wurde automatisch als veraltet markiert, da es in letzter Zeit keine Aktivitäten gab. Es wird geschlossen, wenn nicht innerhalb der nächsten 7 Tage weitere Aktivitäten stattfinden. Bitte überprüft, ob das Problem auch in der aktuellsten Version des Adapters noch relevant ist, und teilt uns dies mit. Überprüft auch, ob alle relevanten Details, Logs und Reproduktionsschritte enthalten sind bzw. aktualisiert diese. Vielen Dank für Eure Unterstützung.
Still valid!