You are sending to fast error im Log & CCU2 deswegen tot…

[holgerwolf]

Hallo,

ich habe nach dem Update aller Module auf meinem Banana auch das Problem das der controller nach ein paar Stunden überläuft und der Prozess gekillt wird. Auch bleibt irgendwann später die CCU hängen.

Habe jetzt hier gelesen, dass man den Memory des controllers begrenzen kann. Habe also in der conf vom controller das MemoryLimit auf 100 (MB) eingestellt und alles neu gestartet. Jetzt nach einer guten Stunde ist auch schon wieder auf 130 MB angewachsen.

Hab ich die falsche Stelle erwischt, oder funktioniert das nicht wie gewünscht.

Danke

Holger

[aquapro]

Hallo Holger,

die Angabe des Limits von 100MB betrifft wohl nicht die Gesamtgröße für den Adapter. Steht hier irgendwo in einem der Posts.

Gruß

Tino
2716_contpage_heizung.txt
2716_d_heizung_bad.txt
2716_hz_heizung_bad.txt

[holgerwolf]

Hallo Tino,

danke für die Info. Was sollte man denn hier eintragen? Ich werde den Wert gleich mal auf 60MB stellen…

Gestern nachmittag war es dann auch wieder soweit iobroker.js-controller war weg. Der Rest lief zumindest im Taskmanager auch wenn es z Bsp keine Einträge in der SQL Datenbank gab. Es steht auch keine Fehlermeldung im Log. Das Log endet einfach...

CCU ist diesmal nicht hängengeblieben.

Danke und Gruß

Holger

[aquapro]

Schlecht zu sagen. Viel Adapter hast Du und welche. Ich habe aufs Minimum zurück gefahren, um das Problem zu beobachten.

js-controller hab ich auf 100 und admin auf 80. Paar auf 50. Damit läuft es paar Tage stabil. Wie lange das gut geht, weiß ich noch nicht, da ich meist am Wochenende etwas an den Teilen mache und so neu starte.

Gruß

Tino

[holgerwolf]

Der neue Parameter in der iobroker-dis.json scheint aber nicht zu funktionen. Den habe ich jetzt auf 60 runtergestellt, aber der controller hat nach ner halben Stunde schon wieder 150MB…

Gruß

Holger

[nobody]

Hallo Holger,

wo hast du denn den Wert abgelesen?

Wenn du den mit top abgerufen hast, ist die Spalte RES relevant:

` > PID = Die Prozess-ID

USER = Der Benutzer, unter dessen Kennung der Prozess läuft bzw. gestartet wurde

PR = Dynamic priority

NI = Nice-Wert, sprich die Priorität, mit welcher der Prozess gestartet wurde

VIRT = Virtueller Speicherverbrauch. Beinhaltet auch alle Ressourcen (bsp. Programm Bibliotheken), welche mehrfach verwendet werden können. Daher nicht aussagekräftig für den Speicherverbrauch eines Prozesses.

RES = Speicherverbrauch (RAM) des Prozesses. Beinhaltet aber keine Daten, die ausgelagert wurdem-

S = Prozess-Status

%CPU = Prozentualer Zeitanteil der CPU für diesen Prozess

%MEM = Prozentualer Anteil des RAMs für diesen Prozess

TIME+ = Die Gesamtzeit, mit der sich die CPU diesem Prozess gewidmet hat

COMMAND = Name des Prozesses `

VIRT sagt nichts aus. RES schon eher.

Generell gilt, dass der Parameter nur auf die Heap-Size wirkt (nach oben begrenzt) und NICHT direkt auf die Prozessgröße.

Der Heap ist jedoch das, was normalerweise im laufenden Betrieb anwächst und somit der relevante Parameter für den Langzeitbetrieb. Der Rest sind node.js, Google V8 und alle anderen importierten Libraries. so-Libs können vom mehreren Prozessen gemeinsam genutzt werden und belegen für alle Prozesse somit nur einmal Speicher. Deswegen kann die Summe aller unter VIRT aufgeführten Prozesse viel größer sein, als der real verbrauchte Speicher.

Prinzipiell solltest du den reservierten Speicher für den Heap auf der admin-Oberfläche unter Objekte````
system.host.raspberrypi.memHeapTotal

Mein js-controller Prozess hat mit Limit 80 MB nach nun zwei Tagen Laufzeit folgende Werte (hab am WE die Sicherung ausschalten müssen):

11590 root 20 0 169308 76072 16880 R 82,0 7,6 111:42.58 iobroker.js-con

Ungefähr da bleibt er nun auch noch nach einer Woche.

[holgerwolf]

Hallo,

ich schaue mir den Speicherverbrauch über den "grafischen" Taskmanager an. Sind aber die gelichen Werte wie mit TOP. Und wenn ich den Speicher hier angegeben habe, nehme ich immer den RES Wert. Ist dann auch der gleiche Wert wie in der Objekt Tabelle.

Überall ist der Wert aber wieder über dem eingestellten MAX Wert in der iobroker-dis.json Datei. Momentan schon wieder über 90 MB.

Gruß

Holger

[nobody]

@holgerwolf:

Hallo,

ich schaue mir den Speicherverbrauch über den "grafischen" Taskmanager an. Sind aber die gelichen Werte wie mit TOP. Und wenn ich den Speicher hier angegeben habe, nehme ich immer den RES Wert. Ist dann auch der gleiche Wert wie in der Objekt Tabelle.

Überall ist der Wert aber wieder über dem eingestellten MAX Wert in der iobroker-dis.json Datei. Momentan schon wieder über 90 MB.

Gruß

Holger `

ok, dann liegt es vielleicht daran, dass du den Eintrag in die falsche Config-Datei gemacht hast

http://forum.iobroker.net/viewtopic.php … 138#p18531

Der gehört nicht in die iobroker-dis.json sondern in die Datei /opt/iobroker-data/iobroker.json

[holgerwolf]

Aber laut Buefox gibt es jetzt doch auch ein Setting dafür:

http://forum.iobroker.net/viewtopic.php … =20#p18258

Und nachdem ich den in der Config Datei gefunden habe, dachte ich der wärs...

Gruß

Holger

[nobody]

Hier zur Vollständigkeit der Link zur Erklärung von Bluefox:

http://forum.iobroker.net/viewtopic.php … tMB#p18379

Warum dies in die /opt/iobroker-data/iobroker.json und nicht in die /opt/iobroker/iobroker-data/iobroker.json soll ... keine Ahnung. Ich hab es zur Sicherheit mal in beide geschrieben.

[holgerwolf]

Ich habe den Wert jetzt an beiden Stellen auf 80MB gestellt. Speicher lief auf 96,8 MB hoch und steht da jetzt stabil.

Mal schauen, ob es hilft..

Danke und Gruß

Holger

[aquapro]

So langsam verlier ich schon die Hoffnung.

Hab eben bei mir geschaut. Also so wird das auf einem PI nie was.

Einstellungen:

! filename="top4admin.PNG" index="0">~~

Und so sehen die beiden PI via TOP aus:

! filename="top4.PNG" index="2">~~

! filename="top4a.PNG" index="1">~~

Gruß

Tino

[nobody]

Schon komisch.

Mal ne naive Frage:

Ist auf dem bananapi auch der aktuelle js-controller 0.8.4 installiert?

Gesendet von meinem GT-N8000 mit Tapatalk

[aquapro]

ja, wieso?

[nobody]

Der Text und die Abbildungen ließen einigen Interpretationsspielraum beim Leser.

Meine Interpretation war, dass das Problem mit dem zu hohen Speicherverbrauch auf dem bananapi, nicht aber auf dem bananapi2 auftritt, weil da die RES-Werte in etwa in dem Bereich lagen, wo sie aufgrund der Werte in der Spalte RAM Limit auch zu erwarten waren. Beim bananapi fällt insbesondere der history-Adapter negativ auf. Auch rpc- und rega-Adapter sollten bei einem Heap-Limit von 50MB eigentlich etwas niedriger liegen.

Ist diese Interpretation so korrekt?

Nun ist das ein Multi-Host-Setup. Jeder Host startet seine Prozesse selbst und die lib hierfür gehört zum js-controller.

Die wenigsten dürften ein Multi-Host-Setup und da ich auch zurzeit keins habe, tritt das bei mir auch nicht auf.

Der bananapi hat selbst keinen admin-Prozess und wird somit über die admin-Oberfläche vom bananapi2 konfiguriert. Die nächste Frage wäre jetzt eigentlich, ob die Werte für das RAM Limit überhaupt beim Starten der Prozesse verwendet werden oder ob sie auf dem Weg vom bananapi2 zum bananapi verloren gehen…
2858_screenshot__1541__li.jpg

[aquapro]

Ich sehe Du hast aufgepasst.

Genau das mit dem Multihost hab ich auch vermutet. Zumal auf dem client nichts funktioniert, wenn der master nicht da ist.

Es funktioniert kein backup und auch kein simples prüfen auf updates.

Also "iobroker update" auf client geht nicht, wenn master nicht da ist.

Ein upgrade auf dem client, also "iobroker upgrade admin", reisst den admin auf den master runter usw. …
3435_screenshot__50_.png

[nobody]

ok, der relevante Code ist in der controller.js in den Zeilen 1039ff.

Du könntest das Memory-Limit einfach testweise ins Log schreiben oder halt auch wenn eben keins da ist.

Wenn da dann kein Wert für memoryLimitMB ist könnte man dann ja über http://iobroker.net:8000 ein issue melden.

[aquapro]

Danke, ich muss mich mal mehr in den Quellcode einbringen. Im Augenblick teste ich nur wie ein normaler Anwender. In den Code schaue ich bei iobroker selten. Bin zu verwöhnt von closed source.

Werde nachher mal testen. Und auch schauen, ob ein Multihost nun überhaupt noch nötig ist, dieser sollte ja nur das RAM Problem entzerren. Vor dem neuen Parameter.

[aquapro]

So, mal paar kleine log Einträge erzeugt.

Master:

    // define memory limit for adapter
    if (instance.common.memoryLimitMB && parseInt(instance.common.memoryLimitMB, 10)) {
        args.push('--max-old-space-size=' + parseInt(instance.common.memoryLimitMB, 10));
        logger.info('host2.' + hostname + ' memoryLimitMB for adapter "' + name + '" ' + parseInt(instance.common.memoryLimitMB, 10));
    } else {
      logger.info('host2.' + hostname + ' memoryLimitMB for adapter "' + name + '"0.');
    }

An dem "host1" erkennt man, dass die Meldung aus dem controller.js vom client kommt "bananapi".

Die anderen Meldungen kommen aus controller.js vom master "bananapi2".

! filename="log4.PNG" index="0">~~

Sieht für mich normal aus. Nur leider war der Speicher (RES) vom history eben schon wieder über 200MB.

[nobody]

Schade.

Der Grund, warum ich vermutet hatte, dass die Limits nicht greifen, waren eher die Werte für die hm Adapter. Diese schwanken bei mir mit Limit 50 zwischen 40 und 50 mb. Der Grund für die höheren Werte kann aber auch andere Ursachen haben wie z.b. andere node.js Versionen oder andere Debian Version, die die Libraries bei der Zählung anders zuordnet.

Der history - Adapter ist ein Fall für sich:

Max-old-space-size legt die Heap - Größe fest, bei der die Garbage Collection angestoßen wird. Die meisten Adapter halten nur wenig Daten und müllen sich nur bei jeden Durchlauf durch die allokierten Variablen und Objekte zu, die danach nicht mehr gebraucht aber von V8 nicht direkt wieder freigegeben werden.

Beim history-Adaper ist es jedoch anders, weil der die history Daten im Speicher hält (wenn ich das richtig verstanden habe). Ich gehe mal davon aus, dass der Adapter die Files nach dem Start oder dem ersten Zugriff auf die Daten in den Speicher läd. Da die Daten noch benötigt werden, kann da auch nichts freigegeben werden.

Die Beschreibung zum Parameter max-old-space-size ist leider nicht sehr ausführlich und die Foreneinträge hierzu widersprüchlich. Ich war eigentlich aufgrund der Diskussionen zum Thema V8 Tuning davon ausgegangen, dass weitere Speicheranforderungen zu Fehlern führen. Dies scheint jedoch nicht der Fall zu sein.

Ich hab im Dezember auf mySQL umgestellt und kann das bei mir nicht mehr nachvollziehen.

Sind auf dem System größere history Mengen, die das bestätigen würden?

Gesendet von meinem GT-N8000 mit Tapatalk