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

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

[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

[etv]

@tom57:

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 `
Servus Thomas,

ja ich denke auch, dass es der SQL-History Adapter in Verbindung mit MySQL war. MySQL hat auch recht viel Speicher gebraucht und daher hab ich es am Pi auch deinstalliert - brauch ich ja auch sonst nicht…

Ich hab mir diese Woche einen weiteren Pi gekauft und auf dem wird nun iobroker als zweiter Host mit MySQL und SQL-History und sonst nix laufen. Das probier ich mal aus - ich muss nur noch raus finden, wie ich die Disk des ersten Pi auf die neue Systemdisk des zweiten Pi bekomme, denn so erspar ich mir die gesamte Installation bis wieder alles so läuft wie es soll...

Bin auch noch unschlüssig, ob ioBroker OHNE History überhaupt eine Disk braucht, denn da wird ja nicht viel auf die SD-Card geschrieben und da kann sein, dass ich da wieder auf SD-Card umsteige - die ist dann doch um einiges schneller als die Festplatte die ich dran hängen hab (so um die 25%).

Wenn das mit dem zweiten Pi gut funktioniert und noch Speicher frei bleibt, wird ev. auch noch der eine oder andere Adapter auf dem zweiten Pi laufen....den ersten greif ich nun nicht mehr an - also keine neuen Adapter mehr - der hat nun mindestens um die 20% RAM frei und läuft so sehr stabil!

Grüße

Tom

[tp1de]

Hallo Tom,

Disk Image kopieren ist mit Win32DiskImager.exe in wenigen Minuten getan.

Ich würde aber überlegen, ggfs. mit dem Raspian Image anzufangen, wenn der neue PI auf SD-Karte laufen soll.

Mach ich aber nur für Testzwecke. Ein USB Stick kostet auch nichts und ist verlässlicher im Dauerbetrieb.

Schau mal, was alles an Statusänderungen oder im Log geschrieben wird …..

Der alte - der mit Festplatte - sollte für MySQL verwendet werden. Besser ist aber eine SSD.

Ich würde dort nur MySQL installieren - keinen Iobroker. Dann brauchst Du auch kein Multihost.

MySQL wird standardmäßig in Raspian mit 128 MB InnoDB Buffer installiert.

Wenn Du den Iobroker mit js-controller, admin, sql-adapter und ggs. vis istalliert, bekommst Du auf dem neuen PI mit MYSQL wieder Speicher Probleme.

Falls Du dies aber machen willst, dann solltest Du auf jedem Fall denn InnoDB Buffer von 128 MB auf 32 oder 16 MB reduzieren.

Ich laufe aktuell mit 16MB und einem InnoDB Buffer Usage von 48,7 % bei zwischen 5 und 10 InnoDB Writes per Second.

Läuft denn bei Dir der SQL-Adapter aktuell stabil?

Grüße

Thomas

[etv]

Servus Thomas,

ich hab eh grad eine alte Notebook Festplatte ausgegraben - werde nun beide mit Festplatte betreiben…ist ja eh alles da

SQL-History hab ich dzt. nicht laufen - hab ich mit den Problemen abgedreht.

Ich zieh gerade die Images mit dem Win32... - wollte es irgendwie unter unix schaffen, aber egal - geht so auch - dauert halt, bis eine 250GB Platte via USB2.0 runter gesaugt wird :shock:

Bei der Gelegenheit mach ich auch gleich mit gparted und truncate am Notebook kleine Imagefiles, die ich mir zwecks "Not-Restore" aufhebe. SO hab ich keine Imagefiles die, rasch mit dem Win32... geschrieben sind und ioBroker Backup läuft sowieso täglich eines..

Ich möchte auf jeden Fall mal mit Multihost spielen, mal schauen wie das funktioniert, aber wenn es da wieder Brösel mit dem Speicher gibt (obwohl auf dem zweiten jetzt ja nur MySQL und SQL-History laufen wird), werd' ich mal deine Tipps ausprobieren - hast eh in einem anderen Thread die MQQT-Lösung schon aufgezeigt...die finde ich spannend!!

Grüße

Tom

[tp1de]

Hallo Tom,

schreib mal die Speichernutzung vom 2. PI mit Multihost-Admin, MySQL und SQL-Adapter.

Ich vermute mal:

js-controller 100-150 MB

io.admin ….. 100 MB

io.sql ......... 100 MB

MySQL .........250 MB

mal sehen....

Wo machst Du dann die Auswertungen der SQL-Datenbank?

Wenn Du viel testest und Images neu schreibst empfehle ich USB3 Sticks.

Ich hab welche von Scandisk mit ca. 120Mbit/s lesen und 80Mbit/s schreiben.

Auf dem PC geht das lesen (sichern) und schreiben der Images dann in 2-3 Minuten je nach Größe.

Bin gespannt auf Deine Erfahrungen.

Grüße

Thomas

[etv]

Servus Thomas,

ein Statusbericht von mir:

Ich hab heute erfolgreich den zweiten Raspi als reinen History Adapter installiert - hab den bestehenden Raspi einfach geclont, erst iobroker komplett gelöscht und dann MySQL und iobroker installiert.

Hat in der Multihost Umgebung mal ganz gut funktioniert.

Derzeit logge ich alle Temperaturen und Feuchten im Haus und draußen, die Load auf den Raspis und den Sonnenstand, da ich in Zukunft die Rollläden vom Sonnenstand her steuern will - so hab ich mal eine ungefähre Ahnung, zu welcher Uhrzeit die Sonne wo "um die Ecke" kommt [emoji3]

Auswertung erfolgt rein über VIS (hab die Diagramme alle auf dem Tablett abrufbar), bzw. über Flot manuell, wenn mich etwas interessiert, also Anlass-abhängig.

Derzeit sind am History Raspi etwa 50%/des Speichers frei. Das werde ich mal beobachten…

Aja, als Disken hab ich alte Notebook Drives dran hängen - die waren einfach da und daher wird da dzt. mal nix investiert - es kommen eh bei Homematic jedes Monat genug dazu [emoji1]

Grüße

Tom

[etv]

Servus Thomas,

also ich muss sagen, das Ganze funtioniert mit Multihost sehr gut bis jetzt! Ich hatte anscheinend ein paar MySQL Config Probleme, da kam es nach einem Reboot der beiden Raspis zu einer kleinen "Sauerei" - das hab ich nu naber ausgebessert und reboot's der beiden funktionieren sehr gut und ohne Probleme. Ich stoppe da immer erst den zweiten Pi (iobroker stop) und dann den ersten und mache dann am ersten einen reboot und sobald der oben ist, wird der zweite gebootet.

Speicher schaut dzt. so aus (sind erst ein paar Minuten up)

Pi 1 hat ca 50% Speicher frei und die Load ist 0,08 / 0,19 / 0,17 %

laufen tut:

• admin

• flot

• rega

• rpc

• 2x ical

• javascript.0

• rickshaw

• vis

• web

Pi 2 hat ca 60% Speicher frei und die Load ist 0,06 / 0,18 / 0,14 %

laufen tut:

• mysql

• javascript.1

• pushbullet

• sql history

Geloggt werden aktuell 19 Datenpunkte

Dzt. sollte es keinen Grund für einen reboot geben = morgen Vormittag präsentiere ich dann die neuen Speicherwerte, wenn die beiden mal 24 Stunden gelaufen sind…

Grüße

Tom

[tp1de]

Hallo Tom,

ich hab Deine Erfahrungen zum Anlass genommen und habe gestern auf Multihost umgestellt.

Ich muss sagen, ich bin sehr positiv überrascht. Insgesamt ist die Speicherausnutzung signifikant besser als vorher.

Beide Systeme laufen nun mit unter 40% genutztem Speicher im Mittel. CPU Load ist auch deutlich geringer.

PI 1: Master mit admin, hm-rpc, hm-rega, node-red mit Piface- und 1-Wire Board und USB RS485 Adapter

PI 2: Slave mit SQL-Adapter, mysql Datenbank und VIS mit Flot und Rickshaw Grafiken.

PI 1 liest kontinierlich den RS-485 Datenstrom meiner Heizungssteuerung und wertet diesen mit Node-Red aus.

Ein OWFS Server ist installiert für die Temperatursensoren.

In Node Red überwache ich mit dem Pifaceboard die Kesselsteuerung und protokolliere diese in eigenen States.

(Brennerlaufzeiten und Schaltpunkte etc).

Load ist ca. 0.4 - 0,8 Memory ca 45 %

PI 2 schreibt kontinuierlich ca. 20 Datenpunkte in MySQL Datenbank weg.

In Vis werden die Daten aufbereitet und dargestellt.

Load < 0,1 Memory ca. 30%

In der vorherigen Version hatte ich die Daten zwischen den PI's per MQTT übergeben. Der MQTT-Server lief auf Pi 1.

Obwohl ich in dieser Version den MySQL-Server auf der Diskstation hatte waren die Loads

mit PI >90% Memory und PI2 mit > 80% Memory viel höher und ich hatte erhebliche Stabilitätsprobleme !

PI 1 läuft stabil durch, auch wenn ich bei PI 2 den Iobroker runterfahre, PI 2 ausschalte bzw. reboote.

Wenn Pi 2 wieder da ist laufen die SQL-History Prozesse nahtlos weiter. Toll so muss es sein !

Mein erstes Fazit:

Alles so wie ich mir bestenfalls vorgestellt habe - Jetzt muss ich noch die Langzeit-Stabilität testen.

Grüße

Thomas

[etv]

…ja danke, hab deinen Post drüben gerade gelesen und gleich positiv kommentiert

Schöne Grüße

Tom

[sissiwup]

Hallo,

ich habe mal die Speicherentwicklung angesehen,

deutlich wird, wenn man auf längere Sicht schaut,

dass da wohl noch ein Speicherleck ist:

Ich starte den ioBroker immer um 4:00 neu.

Dann ist der der freie Speicher (blau) am höchsten.

Danach nimmt er kontinuierlich ab.

[etv]

@sissiwup:

Hallo,

ich habe mal die Speicherentwicklung angesehen,

deutlich wird, wenn man auf längere Sicht schaut,

dass da wohl noch ein Speicherleck ist: `

Hallo,

wäre interessant weche(r) Adapter das sind - ich hab nun 42 Stunden Uptime und bei mir liegen beide Raspi's noch immer um den selben Wert herum - 20% der Master und 25% der Slave - da tut sich bei mir nur um die +/- 2 oder 3 Prozent was.

Was mir aber in den letzten "Umbautagen" immer wieder aufgefallen ist - ich muss nach jedem Backup neu starten, da danach der Speicher voll ist. Wäre aber nix böses ist nur folgendes Script, welches ja in diesem Forum gepostet wurde:

#!/bin/bash
cd /opt/iobroker
iobroker stop
rsync -aLvzh /opt/iobroker /opt/backup/
iobroker start
tar -czvf /media/backup_card/iobroker/iobroker-main.`date "+%F"`.tar /opt/backup/iobroker

Grüße

etv

[etv]

Guten Morgen,

ich hab heute wieder rein geschaut und siehe da, es sind am Pi 1 "nur" mehr 14% Speicher frei, d.h. es gibt anscheinend wirklich in einem der Adapter ein Memory-Leak…

Folgende Instanzen laufen bei mir auf diesen Pi:

• admin

• flot

• rega

• rpc

• 2x ical

• javascript.0

• rickshaw

• vis

• web

Ich werd' mal in den kommenden Tagen VIS auf den zweiten Pi umziehen lassen und schauen, wie's dann aus sieht.

Grüße

etv