Iobroker.js-controller stürzt ab

[tp1de]

Aktuelle node version v0.12.6. Habe auch 4.2.1 und 0.10.22 ausprobiert. Der Fehler bleibt der Gleiche.

Installiere alle nochmal alles von Scratch (Raspian Image) - sag dann Bescheid, ob der Absturz noch da ist.

[starfish]

Anfänglich dachte ich: Zufall oder irgendein selbstgemachter Fehler, aber hier ists mittlerweile wiederholt dasselbe: iobroker verabschiedet sich neuerdings in unregelmässigen Abständen. js-controller 8.5, Node 0.12.6, SQL-Adapter 0.1.2 - konnte allerdings noch nicht genauer nachschauen, was nun wirklich abgestürzt ist. Das Log nach dem Neustart ist aber voll mit Einträgen wie:

bananapi2 2016-02-03 10:11:08 error host.bananapi2 instance system.adapter.sql.0 terminated with code 7 (Adapter already running) , also reboot.

[tp1de]

Inzwischen habe ich den Raspberry PI komplett neu installiert - mit Node v.0.12.6.

Der Fehler tritt immer noch auf. Nach ca. 1 1/2 Stunden Laufzeit mit SQL-Adapter verabschiedet sich der js-controller.

Jetzt habe ich aber auch einen Eintrag im Log:

rasp2	 2016-02-03 09:31:52	warn	host.rasp2 instance system.adapter.sql.0 terminated due to SIGABRT

Die Raspian-shell läuft weiter, ebenso die Datenbank.

Alle Subprozesse ( admin, node-red etc) sind noch aktiv, der js-controller abgestürzt.

Die Befehle "iobroker start" oder "iobroker stop" funktionieren nicht.

Bluefox: Was kann ich tun?

[holgerwolf]

An den Fehler möchte ich mich ranhängen. Habe das bisher immer auf den steigenden RAM Bedarf vom controller geschoben, den ich nicht in den Griff kriege (siehe anderen Beitrag: http://forum.iobroker.net/viewtopic.php?f=22&t=2044 )

Symtome sind bei mir aber auch die gleichen. Prozess wird gekillt. Kein Eintrag ins iobroker Log. Restlichen Prozesse laufen weiter.

Plattform bei mir ist ein BananaPi.

Gruß

Holger

[starfish]

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

[aquapro]

Auf welchen Wert steht bei Dir swappiness?

[starfish]

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?

[aquapro]

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.

[starfish]

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

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