You are sending to fast error im Log & CCU2 deswegen tot…
-
Liebe Leute,
zu diesem Thema wiedermal ein Update von mir.
Also nach dem "weg mit dem Speck" auf dem Raspi scheint nun alles wieder ohne Probleme zu laufen, d.h. es ist sehr wahrscheinlich ein Memory Problem gewesen!
in den letzten Tagen sind folgende Adapter auf dem Raspi 2B gelaufen:
-
admin
-
flot
-
hm-rega & hm-rpc
-
zwei ical Instanzen
-
javascript
-
vis
-
web
Nach einem Start hatte ich immer um die 50% freien Speicher und nach ein paar Stunden Laufzeit um die 35%, nach einigen Tagen dann 25%, aber das bleibt dann stabil! Den Parameter memoryLimitMB hab ich im iobroker.json auf 80 gesetzt.
Als nächsten Adapter hab ich nun Pushbullet aktiviert - nach dem Start merkt man keinen Speichermehrverbrauch - mal die kommenden Tage abwarten, aber der Adapter scheint nicht viel zu brauchen, bzw. anscheinend erst wenn er aktiv wird….mal sehen - Waschmaschine und Trockner laufen gerade, also sollten in den kommenden Stunden auf jeden Fall man zwei Nachrichten gepusht werden
Ich halte euch auf dem Laufenden...
Grüße
etv
-
-
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
-
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 -
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
-
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
-
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
-
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.memHeapTotalMein 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. -
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
-
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
-
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
-
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.
-
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
-
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
-
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
-
ja, wieso?
-
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 -
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 -
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.
-
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.
-
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.
