Weihnachtsangebot 2025! 🎄

[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

[aquapro]

Ich denk das wird normal sein, mit dem history.

Es sind 1400 states, die uberwacht werden. Wenn die auf Standard 960 Einträge im RAM stehen, wird es eng. Hab jetzt den Wert runter gesetzt, mal schauen.

Nächste Step wär wieder zurück auf einen Host.

Bekommt man den Client wieder aus den Einstellungen vom Master raus?

Dann umstellen auf MySQL und damit sollte es sich entspannen.

Wichtig ist, das nicht immer die CCU gerissen wird, wenn iobroker spinnt.

[sissiwup]

Hallo,

ich hatte auch die Abbrüche auf meinem Pi.

Er hat dann auch wahllos Prozesse gekillt, wenn er keinen Speicher mehr hatte.

1. Maßnahme: Swap auf 2 GB vergrößern

=> Dann wird er nur noch langsamer und bricht nicht mehr ab.

2. History aus => wenn denn keine Probleme liegt es daran

=> Überwachung des Pi mache ich mit RPi-Monitor, der liefert alles was ich wissen muss.

Beim Pi mit 4 Kernen, sollte die Load Über 15 Minuten immer unter 2 liegen.

Bei mir liegt sie mit vielen Adaptern und History immer so bei ca. 0.5.

Der 5 min Load sollte immer unter 4 liegen, sonst kommt er nicht mehr hinterher.

Bei mir liegt der aktuell bei ca. 1

Der 1 min Load darf mal über 4 gehen.

Bei mir ist das Maximum (bei Neustart) 5. Ansonsten 2.

Der Speicher ist bei mir nahezu ein Strich bei ca. 600 MB.

=> Sollte unter 2. ein stabiles System rauskommen, muss nicht auf History verzichtet werden.

Ich habe die History auf mySQL umgestellt. Seitdem läuft es stabil.

(Ich logge nahezu jeden Datenpunkt für 2 Jahre).

Am besten die History auf einen anderen Pi oder ein nas, welches meist sowieso eine mySQL-DB anbietet.

[coyote]

Da ich auch immer wieder Abbrüche auf dem Pi2 habe (Reconnection to DB), hab ich jetzt mal auf den Rat von Sissi gehört und SWAP auf 2GB erhöht.

Seit 4 Stunden sieht es mal gut aus, vorher hatte ich fast alle halbe Stunde die Abbrüche, da der Speicher vollgelaufen ist.

Mal abwarten ob es jetzt besser ist. Load sieht auch gut aus, bin ziemlich stetig unter 1 bzw. bei 1 min Load mal bei 1,5

[aquapro]

Okay.

Ich verwende ein armbian image. Da steht das file wohl auf 128MB und liegt im Verzeichnis /var.

Hab sowas gefunden, für 128MB:

dd if=/dev/zero of=/var/swap bs=1024 count=131072

Nun ist file 2G groß und nach mkswap auch okay.

Aber in /etc/sysctl.conf steht vm.swappiness=0 . Somit wird swap ja nur im notfall benutzt, reicht das?

Gruß

Tino

[aquapro]

hm-rega Adapter kann ich auch nicht mehr anschalten.

Sobald ich das mache, kommt nach dem ersten sync die Warnung:

warn	Pending request for more than xxx ms

Intervall stand auf 30 nun auf 120 Sekunden. Gleiche Problem:

! hm-rega-0 2016-02-03 19:16:33 warn Pending request for more than 150000 ms
! hm-rega-0 2016-02-03 19:16:20 warn Pending request for more than 125000 ms
! hm-rega-0 2016-02-03 19:16:08 warn Pending request for more than 100000 ms
! hm-rega-0 2016-02-03 19:15:55 warn Pending request for more than 75000 ms
! hm-rega-0 2016-02-03 19:15:42 warn Pending request for more than 50000 ms
! hm-rega-0 2016-02-03 19:15:30 warn Pending request for more than 25000 ms
! hm-rega-0 2016-02-03 19:13:18 info request state values
! hm-rega-0 2016-02-03 19:13:18 info deleted 0 variables
! hm-rega-0 2016-02-03 19:13:18 info added/updated 74 variables
! hm-rega-0 2016-02-03 19:13:17 info got 74 variables
! hm-rega-0 2016-02-03 19:13:16 info deleted 0 programs
! hm-rega-0 2016-02-03 19:13:16 info added/updated 30 programs
! hm-rega-0 2016-02-03 19:13:14 info got 30 programs
! hm-rega-0 2016-02-03 19:13:13 info added/updated rooms to enum.rooms
! hm-rega-0 2016-02-03 19:13:12 info added/updated functions to enum.functions
! hm-rega-0 2016-02-03 19:13:10 info added/updated 3 favorites to enum.favorites
! hm-rega-0 2016-02-03 19:13:10 info time difference local-ccu 1s
! hm-rega-0 2016-02-03 19:13:10 info ReGaHSS 192.168.178.37 up
! hm-rega-0 2016-02-03 19:13:07 info subscribe hm-rpc.0.BidCoS-RF:50.PRESS_SHORT
! hm-rega-0 2016-02-03 19:13:07 info starting. Version 0.2.2 in /opt/iobroker/node_modules/iobroker.hm-rega
! host-bananapi2 2016-02-03 19:13:04 info instance system.adapter.hm-rega.0 started with pid 3129
! host-bananapi2 2016-02-03 19:13:04 info object change system.adapter.hm-rega.0
! host-bananapi2 2016-02-03 19:12:48 info object change system.adapter.hm-rega.0
! admin-0 2016-02-03 19:12:27 info successful connection to socket.io from ::ffff:192.168.178.42
! host-bananapi2 2016-02-03 19:07:25 info object change system.adapter.hm-rega.0

Lass ich das so, steigt die ccu nach einiger Zeit aus.

:cry:

[sissiwup]

Hast du Cuxd installiert, was sagt der?

Welche Parameter hast du bei den drei Adaptern?

[aquapro]

Hatte Cuxd extra deaktiviert. Parameter waren die empfohlenen, gingen auch die ganze Zeit.

Hab jetzt alle drei Adapter mehrfach gelöscht und neu installiert.

Jetzt laufen die ersten beiden wieder. Cuxd hab ich noch nicht wieder installiert.

Es wird Speicherproblem sein. Starte jetzt jeden Tag neu und gut ist. Ich werde iobroker so nicht produktiv einsetzen, hat für mich im Augenblick keinen Sinn. Aber ich teste aktiv weiter, vielleicht bessert es sich ja. Zumindest helfen die Erkenntnisse hoffentlich bei der Weiterentwicklung.

Gruß

Tino

[nobody]

Ich möchte ja nur ungern euer Experiment mit dem Swapspace stören, aber vielleicht sind dabei die folgenden Zahlen hilfreich:

Zugriffszeiten RAM 60-80 ns

Zugriffszeiten SD-Card (Class 10 lesend) 1,8 - 2,2 ms (1.800.000 - 2.200.000 ns)

Zugriffszeiten SSD (lesend) 0,2 - 0,4 ms

Zugriffszeiten HDD (lesend) 3,4 - 9 ms

Die Werte weichen je nach Hersteller ab, aber die Größenordnungen sind in etwa richtig.

Da beim Swapping nur kleine Memory-Pages ausgelagert werden, ist fast ausschließlich die Zugriffzeit relevant und die Transferraten sind egal.

Wenn nun auf eine ausgelagerte Memory-Page (auf Debian 32 bit default = 4.096 Byte) zugegriffen werden soll, muss erst eine andere Memory-Page ausgelagert werden um Platz zu schaffen, dann die gewünschte Memory-Page in den RAM geladen werden und dann erst kann der Prozessor diese Page benutzen.

Das Problem fällt erst garnicht auf, weil das System zuerst die Memory-Pages auslagert, die von inaktiven Prozessen stammen oder auf die schon lange nicht mehr zugegriffen wurde. Sobald ein System Memory-Pages von aktiven Anwendungen massenhaft auslagern muss, ist das system praktisch tod. Spätestens wenn für irgendeinen node.js-Prozess die Garbage-Collection startet will sie alle Pages überprüfen. Dann ist das System für Minuten weg.

„RAM ist durch nichts zu ersetzen – außer durch noch mehr RAM.“

Thema swappiness:

Swappiness is a Linux kernel parameter that controls the relative weight given to swapping out runtime memory, as opposed to dropping pages from the system page cache (sometimes also called disk cache).

Der Parameter hat überhaupt nichts damit zu tun, ob das System Memory-Pages auslagert oder nicht sondern steuert nur, ob Memory-Pages des Disk cache in das Swapfile ausgelagert oder gelöscht werden. Wenn diese gelöscht werden, müssen diese aus den Originaldateien wiederhergestellt werden. Wenn die ausgelagert werden, ist dies meistens etwas schneller.

Wenn man mit SSD oder SD arbeitet, ist auslagern des Disk-Cache quatsch, weil dies auf die Lebensdauer des Flash-Speichers geht. Ob swappiness nun auf 0, 1 oder 100 steht hat keine Auswirkung darauf, wie viel Speicher das System den Anwendungen zur Verfügung stellt.

Memory-Pages von Anwendungen werden immer ausgelagert, wenn der RAM nicht mehr reicht und alle Systemreserven wie Buffer und Cache freigegeben wurden. Dies wird aber über vm.min_free_kbytes gesteuert. https://git.kernel.org/cgit/linux/kerne … ctl/vm.txt

[aquapro]

Deshalb hab ich das geschireben:
> Es wird Speicherproblem sein. Starte jetzt jeden Tag neu und gut ist. Ich werde iobroker so nicht produktiv einsetzen, hat für mich im Augenblick keinen Sinn. Aber ich teste aktiv weiter, vielleicht bessert es sich ja. Zumindest helfen die Erkenntnisse hoffentlich bei der Weiterentwicklung.

Und in einem anderen Post das:
> Vielleicht bekomme ich die tage ein größeres System an den Start (mehr RAM), dann versuch ich es damit.

[tp1de]

Hallo etv,

auch ich habe aktuell Stabilitätsprobleme.

Ich habe einen 2. PI aufgebaut um den SQL- Adapter zu testen.

Bei mir stürzt regelmäßig (alle 5- 24 Stunden) der js-controller ab - Ich vermute falsche Adressierung.

MySQL läuft bei mir auf der Synology Diskstation - Speicher-Auslastungsprobleme auf dem PI habe ich deshalb nicht.

Könnte es sein, dass auch bei Dir der SQL-Adapter das Problem macht?

Darüber hinaus verursacht der hm-rpc Adapter bei mir Probleme.

Ab und zu muss ich die CCU2 rebooten, damit alle Werte sauber übertragen werden.

Viele Grüße

Thomas
3435_screenshot__51_.png