NEWS
Steigende RAM Auslastung von Compact / Adapter Prozessen
-
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)
Verlauf vom Broadlink Adapter über 3 Tage (RPI4)
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.)
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.
Zum Vergleich der Prozess vom JS-Controller (RPI4), hier scheint alles in Ordnung zu sein.
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.
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)
-
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)
Verlauf vom Broadlink Adapter über 3 Tage (RPI4)
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.)
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.
Zum Vergleich der Prozess vom JS-Controller (RPI4), hier scheint alles in Ordnung zu sein.
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.
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)
@ToGe88
Ich würde beide Systeme unter node12 laufen lassen.
Und auch checken ob beide im RunLevel 3 laufen. -
@ToGe88
Ich würde beide Systeme unter node12 laufen lassen.
Und auch checken ob beide im RunLevel 3 laufen.@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 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.
@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. -
@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. -
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)
Verlauf vom Broadlink Adapter über 3 Tage (RPI4)
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.)
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.
Zum Vergleich der Prozess vom JS-Controller (RPI4), hier scheint alles in Ordnung zu sein.
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.
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)
@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.
Support us
662
Online32.6k
Benutzer82.3k
Themen1.3m
Beiträge