Iobroker.js-controller stürzt ab
-
steigender RAM-Bedarf kann schon sein (memory leak?) jedenfalls hatte ich früher mit dem Bananapi und node 0.10.22 keine Probleme. iobroker lief darauf klaglos - bis nach einer Neu-Installation diese Probleme auftraten. Abstürze waren es weniger, viel eher gezielte "kills" durch das System, weil der Speicherplatz knapp wurde. Siehe dazu den betr. syslog-ausschnitt:
Feb 4 12:09:02 bananapi2 /USR/SBIN/CRON[4250]: (root) CMD ( [ -x /usr/lib/php5/maxlifetime ] && [ -x /usr/lib/php5/sessionclean ] && [ -d /var/lib/php5 ] && /usr/lib/php5/sessionclean /var/lib/php5 $(/usr/lib/php5/maxlifetime)) Feb 4 12:17:01 bananapi2 /USR/SBIN/CRON[4261]: (root) CMD ( cd / && run-parts --report /etc/cron.hourly) Feb 4 12:30:05 bananapi2 kernel: [37486.312663] lowmemorykiller: Killing 'iobroker.js-con' (3962), adj 0, Feb 4 12:30:05 bananapi2 kernel: [37486.312681] to free 139264kB on behalf of 'node' (4270) because Feb 4 12:30:05 bananapi2 kernel: [37486.312686] cache 5736kB is below limit 6144kB for oom_score_adj 0 Feb 4 12:30:05 bananapi2 kernel: [37486.312691] Free memory is -1792kB above reserved Feb 4 12:30:05 bananapi2 kernel: [37486.369313] lowmemorykiller: Killing 'io.admin.0' (3969), adj 0, Feb 4 12:30:05 bananapi2 kernel: [37486.369334] to free 119780kB on behalf of 'node' (4273) because Feb 4 12:30:05 bananapi2 kernel: [37486.369339] cache 5764kB is below limit 6144kB for oom_score_adj 0 Feb 4 12:30:05 bananapi2 kernel: [37486.369344] Free memory is -2408kB above reserved -
Auf welchen Wert steht bei Dir swappiness?
-
hallo aquapro - swappiness steht auf 1 - dazu muss ich sagen, dass ich eine SSD verwende. Aber ich kann den Wert zumindest versuchsweise höher stellen. Welchen Wert empfiehlst Du denn?
-
Sorry, bin selber auf der Suche nach einem Wert, da ich fast nur am Speicherkampf bin. Im Image steht im Standard 0!
Nach paar Tagen Laufzeit kommt es zu ersten Ausfällen und im schlimmsten Fall reißt es die CCU.
In einem anderen post hab ich schon geschrieben, dass ich iobroker für Produktivsystem erstmal aufgebe. Aber ich teste fleißig weiter. Will ja auch bei der Weiterentwicklung helfen.
Vielleicht bekomme ich die tage ein größeres System an den Start (mehr RAM), dann versuch ich es damit.
-
naja, mir ist aufgefallen, dass zur gleichen Zeit system cronjobs (cleanup) gestartet werden, deshalb habe ich die iobroker crons anders verteilt - vielleicht bringt das was …. wir werdens sehen.
> In einem anderen post hab ich schon geschrieben, dass ich iobroker für Produktivsystem erstmal aufgebe.kann ich irgendwie verstehen. ich kämpfe zeitgleich auch noch mit occ - da hänge ich völlig in der Luft z.Zt. aber vielleicht bin ich auch zu ungeduldig. Für Produktiveinsatz ist es m.M. wohl noch zu früh. Als Optimist würde ich sagen: der Weg ist das Ziel
-
Hallo Bluefox,
nachdem mich jetzt 3 Tage die js-controller Probleme mit VIS, Flot und Rickshaw beschäftigt haben
(diese sind seit der neuen Version von Dir seit gestern Abend gelöst)
zurück zum Absturz des js-controllers beim SQL-Adapter.
Dieser ist nachwievor da. Nach ca. 1 Stunde Laufzeit stürzt der js-contoller ab.
iobroker stop funktioniert nicht:
root@rasp2:~# cd /opt/iobroker root@rasp2:/opt/iobroker# iobroker stop /usr/bin/iobroker: Zeile 1: 2072 Speicherzugriffsfehler node /opt/iobroker/node_modules/iobroker.js-controller/iobroker.js $1 $2 $3 $4 $5 root@rasp2:/opt/iobroker#Im Admin-Log ist kein Eintrag.
Zu meiner Konfiguration:
Raspberry PI2:
-
Es läuft node 0.12.6 und der neueste js-controller
-
Datenübergabe von PI1 per MQTT in node-red
-
Homematic Adapter (hm-rega und hm-rpc)
-
VIS / Flot / Rickshaw zur Visualisierung der Daten
-
SQL-Adapter mit Verbindung zu externer MYSQL-Datenbank (um mysql nicht lokal laufen zu lassen)
-
MYSQL-Server ist meine Synology Diskstation mit Mariadb.
-
Überwachung der DB mit MySQL Workbench unter Windows (siehe Screenshot)
Funktional läuft alles super - Die Datenaufbereitung ist viel schneller (ca. 5 Mal) als auf PI1 mit history adapter.
Würde ich gerne produktiv nehmen - aber:
Bis auf die Stabilitätsprobleme …..
Ich hoffe Du kannst helfen.
Grüße
Thomas
1023_screenshot.jpg -
-
Auf welchen Wert steht bei Dir swappiness? `
so, jetzt habe ich swappiness auf 10 gestellt - der Spuk scheint vorbei, seit rund 24 Std. kein Absturz mehr. Die Erhöhung mache ich aber nur ungern, weils halt für die SSD nicht so gut ist. -
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
