Iobroker.js-controller stürzt ab

[tp1de]

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

[starfish]

@aquapro:

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.

[vegetto]

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.

[starfish]

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.

[tp1de]

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

[holgerwolf]

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

[aquapro]

@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.

[holgerwolf]

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

[starfish]

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.

[holgerwolf]

Bei mir läuft der Banana auf einer SSD. Ist dann aber auch nicht so dolle

[vegetto]

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.

[tp1de]

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…...

[holgerwolf]

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