Iobroker.js-controller stürzt ab
-
Hast Du auch probiert, die memoryLimitMB in /opt/iobroker/iobroker-data/iobroker.json zu setzten?
Ich hatte auch Stabilität Problemen und das Swap würde nach weniger uptime verwendet. Seit heute morgen laufe ich mit memoryLimitMB und auch Limits für alle Online Adapters und ich bin ganz zufrieden:
` > top - 00:40:39 up 13:27, 3 users, load average: 0.26, 0.25, 0.30
KiB Mem: 948140 total, 844220 used, 103920 free, 89676 buffers
KiB Swap: 2097148 total, 0 used, 2097148 free. 304324 cached Mem `
Mal sehen ob das noch in den nächsten Tagen weiter so gut funktioniert aber so weit das Swap nicht verwendet wird ist eine sehr gute Signal.
-
hallo vegettto, danke, das war mal ein wertvoller Hinweis.
js-controller (und node) sind echte Resourcen-Fresser, das wird schnell klar mit dem Befehl "top".
weitere Infos hier http://forum.iobroker.net/viewtopic.php … 138#p18531
auch der Hinweis zur node-version hier http://forum.iobroker.net/viewtopic.php ... 138#p18543 erklärt so einiges.
meine Probleme haben mit der Verwendung von node 0.12.6 angefangen.
-
So mal zusammenfassend meine bisherigen Erfahrungen:
Swapiness:
Habe ich aktuell auf 20 gesetzt - Die Swap-Nutzung ist aber damit auch < 1 MB (Swapfile Größe 1 GB)
Sollte also auch für SSD's kein problem sein, da die Schreiboperationen sehr gering sind
Speichergröße im Admin pro Adapter setzen:
Das bringt etwas, bei mir aber nicht so durchschlagenden Erfolg im freien Hauptspeicher.
Aber wie es aussieht läuft das System schon deutlich stabiler
Speichergröße in /opt/iobroker/iobroker-data/iobroker.json
Das hat bei mir den signifikantestesten Effekt für die Speichernutzung
Ich habe aktuell 80 MB eingetragen:
"system": { "memoryLimitMB": 80 },Meine PI's laufen jetzt mit diesen 3 Parametern seit 16 Stunden stabil. Auch der SQL-Adapter !
Ich halte Euch auf dem Laufenden, ob damit die Stabilitätsprobleme gelöst sind.
Grüße
Thomas
-
Da ich diese Abstürze des Contollers auch habe, würde ich diese Swap Parameter auch mal ändern wollen. Allerdings ist das neu für mich. Wo muss ich da was ändern?
Danke und Gruß
Holger
-
@tom57:Meine PI's laufen jetzt mit diesen 3 Parametern seit 16 Stunden stabil. Auch der SQL-Adapter !
Ich halte Euch auf dem Laufenden, ob damit die Stabilitätsprobleme gelöst sind. `
Naja, wenn 16 Stunden schon ein Erfolg sind. Das Teil soll eigentlich Monate laufen, genau für sowas benötige ich das.
Ich werd mal swappiness von 0 auf >0 setzen, mal schauen ob es was bringt. Zumindest solange ich einen Ersatz für den Pi gefunden hab.
-
Nach der Änderung der Swapiness auf 20 läuft der controller jetzt erstmal durch (seit gestern 13 Uhr - ca 20 Stunden).
RSS vom controller hat sich auf ca 100 MB eingependelt.
Ich weiß zwar nicht, was ich damit ausgelöst habe, aber es scheint zu wirken
Gruß
Holger
-
bei mir reichte Swappiness 10 - allerdings nehme ich an, dass Swappiness 1 oder sogar 0 ganz bewusst zum Schutze der SD-Karten so eingestellt war. Deshalb finde ich die Heraufsetzung des Wertes nicht ganz so befriedigend.
-
Bei mir läuft der Banana auf einer SSD. Ist dann aber auch nicht so dolle
-
Seit eine Woche mit max memory Setting bei dem controller und alle Adaptern habe ich kein Problem mehr gehabt und die Anzahl von frei Speicher bleibt konstant
Ich verwende swappines = 0.
-
So mal eine Statusmeldung.
Ich hab nachwievor Swapiness bei 20. Der Swap-Bvereich wird aber im Normalbetrieb gar nicht genutzt.
Wenn ich allerdings Adapter installiere oder update, dann braucht der NPM-Prozess Speicher und bei mir bis zu 120 MB Swap.
Ich habe die Swap-Space auf 1 GB eingestellt. Meine PI's laufen mit USB3 Stick.
Habe auch eine SSD getestet, die bringt aber keine Vorteile, da der USB2-Anschluss am Pi den Engpass darstellt.
Ich habe aber jetzt die MQTT-Adapter rausgeschmissen und laufe im Multihost Modus.
Und siehe da, alle Speicherprobleme sind weg.
Seltsamerweise brauchen die js-controller nun auch wesentlich weniger Speicher als vorher.
Alles andere ist gleich geblieben. Der js-controller braucht nur noch < 60 MB anstatt 120 MB - und MQTT mit 60-80 MB fällt weg.
Ich habe nun das Memory-Limit aus der js-controller config rausgenommen.
Nun läuft bei mir auf dem 2.Pi auch MySQL mit 128 MB InnoDB Buffer im Memory ohne Probleme.
Ich schreibe ca. 50.000 Sätze pro Tag und bin erstaunt wie performant MySQL dabei ist.
50.000 Records (Numerisch bzw. Boolean) bedeuten nur ca. 3 MB Datenbankgröße.
Es sind also leicht 1,5 Monate im InnoDB Puffer im Ram zu halten.
Jetzt laufen die Langzeittests…...
-
Auch hier ein Status:
System läuft seit Dienstag. Speichernutzung ca 500 MB.
@ Tom: Mqtt Adapter lief bei mir noch nie. Glaube deshalb nicht dass es daran lag.
Auf meinem Banana mit SSD läuft jetzt:
ccu-historian
iobroker (Adapter: sql, web, admin, rega, javascript, fritzbox, node-red, history, rpc, dwd)
mysql (DB knapp 20 MB)
Gruß
Holger
