SOLVED [Gelöst] Speicherlecks im ioBroker?
-
@Ritter Bei Windows geht die Spangezeigte Speichernutzung immer rauf. Und irgendwann kommt der Garbage Collector oder sowas und räumt wieder auf. Dann gibt es wieder mehr freien Speicher udn das ganze Spiel beginnt von Neuem.
Wenn Du keine sichtbaren Probleme hast, dann Lass Windows nur machen, das kann das schon. Mein ioBroker läuft sehr stabil unter Win 10. Habe den Info Adapter mittlerweile pausiert und mache mir einfach keine Sorgen mehr. -
Habe jetzt den Runlevel mit
systemctl set-default multi-user.targetauf das "alte" Runlevel 3 gestellt und nodejs geupdatet
artur@ioBroker:~$ nodejs -v v12.20.0Der aktuelle Speicherverbrauch liegt laut ioBroker bei:
also es sind ca. 66% freiartur@ioBroker:~$ free -m total used free shared buff/cache available Mem: 3885 1213 2189 6 482 2439 Swap: 4027 0 4027 artur@ioBroker:~$ who -r Runlevel 3 2020-12-27 00:18 artur@ioBroker:~$ node -v v12.20.0 artur@ioBroker:~$ nodejs -v v12.20.0 artur@ioBroker:~$Bin jetzt mal gespannt wie der Speicher morgen aussieht
-
@LoxDUS Warum ist dein swap file eigentlich so groß? Das ist ja mehr als dein RAM? Ich hab das bei mir auf 100 MB laufen:
pi@raspberrypi:/opt/iobroker $ free -h total used free shared buff/cache available Mem: 3,8Gi 895Mi 2,1Gi 9,0Mi 783Mi 3,0Gi Swap: 99Mi 0B 99Mi -
@Thomas-Braun sagte in Speicherlecks im ioBroker?:
@LoxDUS Warum ist dein swap file eigentlich so groß? Das ist ja mehr als dein RAM? Ich hab das bei mir auf 100 MB laufen:
Swap-Partition unter Linux sollte ca. doppelt so groß wie der RAM sein. Das ist doch der Sinn einer Swap-Partition, dass der Inhalt des RAM auf die Festplatte ausgelagert werden kann.
-
@a200 Ja, in alten Zeiten war das mal die Faustregel. Mach ich aber bei Systemen mit mehr als 2GB RAM nicht mehr.
-
Hmmmm, habe den "default" Vorschlag bei der Installation von Linux gelassen.
Habe im Netz foglendes gefunden:
Ich habe ein debian System am laufen:
artur@ioBroker:~$ uname -a Linux ioBroker 4.9.0-8-amd64 #1 SMP Debian 4.9.144-3.1 (2019-02-19) x86_64 GNU/LinuxIch könnte das natürlich runter drehen. Wäre vielleicht auch für die verlöteten SSD Module nicht schlecht um eine längere Lebensdauer zu bekommen (ich weiß, ist eine Art Mythos
)Ich schaue jetzt mal wie sich der freie Speicher verhält. Für die "Applikation" ioBroker dürfte der SWAP-Speicher ja aber keine Auswirkung haben, oder liege ich da falsch?
Viele Grüße,
Artur
-
Zwischenstand nach ein paar Stunden:
Nur noch 61% frei
Also in ca. 3h von 66% auf 61%Mal sehen was morgen Früh noch so übrig ist....
-
@LoxDUS Ist doch gut wenn der RAM genutzt wird?!
Alles im grünen Bereich. -
@LoxDUS Im nächsten Test-Durchgang deaktiviert doch mal alle skripte im javascript adapter
und vergleiche dann. -
... und da sind es nur noch 24%
@OliverIO
"...deaktiviere mal alle skripte im javascript adapter..." - Ja, werde ich machen. Ich kann das aber nur einzeln machen weil das ganze Haus damit gesteuert wird und ohne bestimmte Skripte leider nicht mal mehr das Licht an und aus geschaltet werden kann.Ich fange heute mal an die unwichtigen Skripte wie die ganzen Komfortfunktionen und nice to have skripte zu deaktivieren.
Bleibe am Ball und beriecht morgen wieder.
-
-
@LoxDUS
parallel kannst du mal den artikel lesen. insbesondere den abschnitt mit timers und callbacks.
evtl hast du da in deinen skripten etwas davon eingebaut.
https://auth0.com/blog/four-types-of-leaks-in-your-javascript-code-and-how-to-get-rid-of-them/ -
@OliverIO
habe mir den Artikel mal durchgelesen. Kann mir durchaus vorstellen das in meinem Code da einige Fälle enthalten sind die zutreffen. Sehe aber im Moment den Wald vor lauter Bäumen nicht mehr:Habe z.B. folgenden Code der den Ventilator im WC steuert.
Über den Parameter t kann ich beim Aufrufen z.B. mitgeben ob der Aufruf von dem Bewegungsmelder im WC kommt.
Über einen Dialog in der VIS, kann ich den Modus für den Ventilator einstellen: 0, 1, auto (siehe Zeile 5)var LTVentilatorGaesteWC; // Nachlauftimer für Ventilator function VentilatorWC(t) { var sLichtDecke = getState(DE_K_LGAST_1).val; // Deckenlampe WC var mVent = getState(MVentWC).val; // Modus für Ventilator var sVent = getState(DE_K_VGAST_1).val; // Status Ventilator switch(mVent) { case 0: // Ventilator AUS setState(DE_K_VGAST_1, false); clearTimeout(LTVentilatorGaesteWC); // Timer beenden break; case 1: // Ventilator EIN setState(DE_K_VGAST_1, true); clearTimeout(LTVentilatorGaesteWC); // Timer beenden break; case 2: // Ventilator Automatisch steuern if(sLichtDecke==true || t==2) { setState(DE_K_VGAST_1, true); // Ventilator wird eingeschaltet sobald ein Licht eingeschaltet wird oder der Bewegungmelder schaltet if(t!=2) { clearTimeout(LTVentilatorGaesteWC); // Timer beenden } else { // Befehl kommt von Bewegungsmelder den Ventilator einzuschalten .. wird immer wieder neu getriggert (teilweise im Sekundenabstand je nachdem wieviel sich der Gast bewegt) clearTimeout(LTVentilatorGaesteWC); // Timer beenden und anschließend neu setzen (solange jemand im WC soll der Ventilator laufen) LTVentilatorGaesteWC = setTimeout(function(){setState(DE_K_VGAST_1, false)}, 360000); // Nach 6Minuten ausschalten } } else { if(sVent == true) //Ist Ventilator an? { // Ventilator ist an und soll ausgeschaltet werden. Jetzt die Nachlaufzeit abwarten und dann ausschalten LTVentilatorGaesteWC = setTimeout(function(){setState(DE_K_VGAST_1, false)}, 360000); // Nach 6Minuten ausschalten } } break; } }Wenn ich mir den Code jetzt genauer ansehe, auch mit dem Hintergrundwissen aus dem von Dir verlinkten Artikel, vermute ich jetzt, dass die Callback-Funktion aus Zeile 25 und 30 doch jedes mal, wenn ich den Timer eigentlich neu Triggern möchte (mit der Kombination von clearTimeout() (Zeile 24) und setTimeout() (Zeile25) ) im Speicher bleibt und es keine Referenz mehr darauf gibt und mir so den Speicher voll donnere weil der bei der Garbage Collection nicht erfasst wird...?
Zusätzlich habe ich gaaaaaanz viele const definitionen am Anfang jedes Scriptes um die ganzen Datenpunkte "oben" zu definieren (ähnlich #define in C-Dateien), Beispiel:... const DG_K_LPHBE_2 = 'hm-rpc.1.OEQ0862609.15.STATE'; const DG_K_LPHBE_1 = 'hm-rpc.1.OEQ0862609.16.STATE'; const DG_K_SPHBE_1 = 'hm-rpc.1.OEQ0862609.19.STATE'; ...klaut das viel Ram weil es "globale Variablen" sind? Kann ich mir nicht vorstellen...
@Thomas-Braun
Du hast glaube ich recht. mit htop konnte ich sehen das sich der io.javascript immer weiter aufgebaut hat. Ich habe jetzt mal einen Großteil der Scripte beendet und nur noch die lebensnotwendigen Scripte am laufen - und diese auch total runtergestript. Im Moment steht der javascript wert bei 205M.
mal schauen wie er in ein paar Stunden aussieht.@Thomas-Braun und @OliverIO
Ich befürchte fast das ihr recht habt mit den javascript. Ich komme aus der C-Programmierung für Microcontroller, JavaScript ist mir manchmal zu suspekt wie es mit Speicher und den ganzen Objekt-Jedöns umgeht.Vielen Dank schonmal,
Artur
-
@LoxDUS
Prüfe mal den Zweig bei case 2:
Da stehen ja einige IFs.
Das kommt mir so vor, als das es hier Fälle gibt, bei denen clearTimeout vor erneutem Setzen des Timers nicht aufgelöst wird. Speziell da wo sVent==true ist -
So, nach weiteren 6h sieht es so aus, dass der io.javascript sich nicht weiter vergrößert hat:
Es ist ja aber auch nicht viel hier im Haus passiert während der Nacht.@OliverIO
Du hast Recht. das ist alles Murks wie ich das gemacht habe. Ich werde mir heute mal einen besseren Code überlegen. Aber vielleicht darf ich auf Deinen Erfahrungsschatz mit Javascript und Timern zurück greifen (Ich habe ganz viele Timer im Einsatz)Wenn ich es richtig verstanden habe, so ist der gültigkeitsbereich eines Objektes (in diesem Fall eines Timer-Objektes), ähnlich wie in C oder C++, doch wenn ich es in einer Funktion deklariere nur solange die Funktion existiert (ausgeführt wird). Sobald die Funktion verlassen wird, kann der Speicher den das Objekt belegt freigegeben werden (es sein denn man baut sich die Callback-Funktionen. Die werden erst, z.B. bei Timern aufgerufen wenn der Timer abläuft und verlieren dann ihre Gültigkeit.
Aus diesem Grund habe ich das Timer-Objekt ausserhalb der Funktionen definiert. Mein Verständnis ist nun das mit ClearTimeout() das zuvor erzeugte Timer-Objekt gelöscht wird und zwar auch die zuvor erzeugten Callback Funktionen. Wenn ich anschließend mit setTimeout() das Timer Objekt neu definiere , wird auch die Callback Funktion neu erstellt.
Nehmen wir mal folgendes Konstrukt an:var TimerObjekt; function foo1() { clearTimeout(TimerObjekt); TimerObjekt = setTimeout(function(){ // Hier jetzt irgendwas machen var Ein_Neues_Callback_Objekt = 'Ich bin neu'; }, 1000); } function foo2() { clearTimeout(TimerObjekt); }wird, wenn ich zunächst foo1() aufrufe und innerhalb der 1000ms dann foo2() die zuvor definierte Callbackfunktion mit all seinen Child Objekten (Ein_Neues_Callback_Objekt) aufgeräumt und für den Garbage Collector sichtbar oder habe ich jetzt eine Leiche im "globalen" Speicher die als Speicherleck für immer da bleiben?
Oder anders gefragt: Muss ich wenn ich einen Timer neu setzen will (also retriggern will) vorher ein clearTimeout() machen damit die "alte" Callback Funktion gelöscht wird?
Edit 28.12.2020 Artur: Habe gerade unter
Stack Overflow
diesen Post gelesen. Demnach wird durch clearTimeout() die Callbackfunktion vom Stack gelöscht. Aber verschwinden dann auch die Referenzen der ganzen Child-Objekte in der Callback Funktion?Wie löst ihr das mit Timern eleganter?
In Deinem Link mit den Speicherlecks steht ja sowas wie das man auch die einzelnen ChildObjekte löschen soll. In diesem Fall oben also Ein_Neues_Callback_Objekt.... Oh man, ich weiß, das geht hier wahrscheinlich zu weit und ich werde mich mal ein wenig in Javascript Foren austoben.
Vielen Dank,
Artur
-
Erst mal vielen Dank an @Thomas-Braun und @OliverIO !
Meine Speicherlecks kommen sicherlich aus meinen Javascript Programmen.
So wie ich es jetzt verstehe ist/war das Problem das die Speicherlecks durch die z.T. fehlerhafte Nutzung von Timer Funktionen entstehen. Es werden Objekte erzeugt die plötzlich keine Referenz mehr haben und auch durch den Garbagne Collector nicht gefunden werden. Dadurch wird immer mehr Speicher verbraucht. Aktuell sieht es "normal aus"
Ca. in der Mitte des Diagramms bin ich auf mein "Fallbacksystem" mit den zusätzlichen Einstellungen die mir @Thomas-Braun empfohlen hat (Runlevel ändern) umgezogen ca. 11Uhr. Da sich der Speicherverbrauch aber trotzdem gesteigert hat (Man sieht das an der roten Linie (io.Javascript) dort versucht der garbage Collector ein paar mal aufzuräumen) habe ich dann um ca. 0:00Uhr viele meiner Javascript Programm gestoppt. Seit dem Zeitpunkt ist es recht ruhig in dem Javascript-Instanzen geworden (schöne glatte Linie). über "htop" sehe ich das sich der io.Javascript Prozess nicht mehr Speicher klaut und stabil ist. Das System ist jetzt seit einigen Stunden bei ca. 26% freiem Speicher :Ich werde später ioBroker nochmal neu durchstarten und dann Schritt für Schritt die ganzen Javascripte nach möglichen Speicherlecks durchforsten und korrigieren.
Vielleicht noch eine letzte Frage:
Wie löst ihr das in euren Programmen wenn ihr retriggerbare Timer für z.B. Lichter im Treppenhaus die nach einer gewissen Zeit wieder ausgehen sollen, aber immer wieder neu getriggert werden sollen?Vielen Dank nachmal an alle Mitwirkenden.
Artur
-
@LoxDUS sagte in Speicherlecks im ioBroker?:
Wie löst ihr das in euren Programmen wenn ihr retriggerbare Timer für z.B. Lichter im Treppenhaus die nach einer gewissen Zeit wieder ausgehen sollen, aber immer wieder neu getriggert werden sollen?
-
Die direkte Antwort wird Dir nicht gefallen: Ich nutze das z.B. in der Küche mit Retriggerung durch einen Bewegungsmelder.
Aber da habe ich einen Shelly Schalter verbaut und bürde diesem die Timeraufgabe auf. Der wird so konfiguriert, daß er nach x Minuten ausgeht. Wird Bewegung erkannt, dann sende ich ihm wieder ein Einschaltsignal. Das geht bei den Shelly gut, weil WiFi und damit spielt der Traffic (häufiges "unnötiges" Einschalten) keine so große Rolle. Bei Homematic wäre das nicht so gut.
Edit: Dieser Teil der antwort mag lieblos klingen, ist aber so nicht gemeint. Ansteuerbare Aktoren haben meist eine auto-timout Funktion und die wird dann auch generell genutzt. Und wenn sie auf z.B. 8h gesetzt wird. Schadensbegrenung bei vergessenen Lichtern. -
Die folgende Antwort geht eher in die von Dir intendierte Richtung:
Wo ich keine HW-Unterstützung habe, verwende ich etliche Watchdogs, all nach dem Strickmuster von @paul53 siehe dort: https://forum.iobroker.net/topic/8961/watchdog-fuer-sensoren-in-js-millis-odertimer-gesucht/2
-
-
@klassisch
Danke für die Antwort. Als Aktoren benutze ich einige Homematic Wired IO Module die keinerlei Zusatzfunktionen wie Timer o.ä. haben. Am Anfang hatte ich nur diese Wired Module. Auch die Javascripte waren in ioBroker noch überschaubar. Mit der Zeit sind dann verschiedenste Sensoren über Zigbee, Wlan und dem Funk-Homatic dazugekommen. Das sind dann die Bewegungsmelder die mittlerweile in jedem Flur oder Bad/WC in den Ecken kleben oder eben Temperatur/Luftfeuchtigkeit und Luftdrucksensoren.
Mit diesen Sensoren sind dann auch die Javascripte bei mir immer komplexer geworden weil ich versucht habe jede Anmerkung der Familie ( "...Morgens soll die Zeit Licht-An-Zeit im Treppenhaus länger sein als Nachmittags..." usw.) irgendwie in die "Intelligenz" des Hauses einzuarbeiten. - Und genau das habe ich anscheinend in diesem Jahr total übertrieben (Man war ja mehr Zuhause ...
In vielen Fällen, wo ich Timer nutze mache ich das Ähnlich wie in dem von Dir geposteten Link beschrieben - Bis auf dsa ich bei einem clearTimeout() vorher nicht prüfe ob noch ein gültiges Objekt da hinterlegt ist (der Timer also noch läuft).
Ich gehe jetzt durch meine Scripte und räume da mal auf. Dann sollte ich die Speicherlecks, die ich eingebaut habe, hoffentlich wegbekommen.Viele Grüße,
Artur
-
@LoxDUS Ja, die alten HM-wired Geräte sind schon recht basic. Aber so lange sie laufen....
[Teils-OT]
Ja, das Optimierungsthema treibt uns um - sonst würde wir wohl nicht automatisieren. Als Vorschulbub hatte ich mal einen Unimog mit Anhänger, so ca. 4cm lang die einzelnen Teile. Aber damals eines meiner vornehmsten Spielzeuge, war halt eine andere Zeit. Zwischen Unimog und Hänger gab es eine Kupplung. Eine einfache Blechzunge. Manchmal hat die etwas geklemmt. Die habe ich so gebogen, daß sie viel besser ging. Aber noch nicht ganz perfekt. Also weiter gebogen und justiert. Bis die Blechzunge ab war. Eine damals sehr schmerzhafte, aber langfristig wertvolle Lehre fürs Leben: Irgendwann wird Optimierung kontraproduktiv. Seither beschäftigt mich immer die Frage "angemessen, gut genug?"
Manchmal hat das Wort "fertig" was befreiendes -
@klassisch
100%ige Zustimmung
Ich hoffe das nach den Aufräumarbeiten in den Javascripten auch alles wieder stabil läuft.
