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

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 ! :D :D :D

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:

609_bildschirmfoto_2016-02-09_um_23.30.32.png

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

aquapro

Sag ich doch.

looxer01

~~@etv:~~

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 `

Hi,

ich verwende das script ebenfalls (hatte mir das mal zusammengebastetl. Sieht ähnlich aus ist aber nicht ganz das gleiche:

#!/bin/bash
cd ./opt/iobroker
iobroker stop
rsync -aLvzh /opt/iobroker /BackUp/
iobroker start
tar -cvf /BackUp/iobroker-20$(date +%y%m%d-%R).tar /BackUp/iobroker

bei mir läuft das auch ohne Probleme aber ich verwende auch node 0.10.22 und da gab es noch nie Speicherprobleme.

Vermutlich reicht es den iobroker start ans ende zu legen, was etwas schade ist, da der tar Befehl eigentlich nicht iobroker vom starten hindern muesste.

vG Looxer

chka

Ich hatte heute nach auch das wunderbare Erlebnis, allerdings hat die ccu weiter gearbeitet :-)

leider gibt es bei mir nicht die Datei opt/iobroker-data/iobroker.json sondern nur die /opt/iobroker/iobroker-data/iobroker.json

! root@raspberrypi:/opt# ls
! backup.sh iobroker minecraft-pi sonic-pi vc Wolfram
! root@raspberrypi:/opt# cd iobroker/iobroker-data
! root@raspberrypi:/opt/iobroker/iobroker-data# ls
! files history homekit.0 iobroker.json node-red objects.json objects.json.bak sqlite states.json states.json.bak

etv

~~@looxer01:~~

Vermutlich reicht es den iobroker start ans ende zu legen, was etwas schade ist, da der tar Befehl eigentlich nicht iobroker vom starten hindern muesste.

vG Looxer `

…danke, ja das kann ich mal versuchen!

Grüße

etv

chka

bei mir hat es geholfen den CuX hm-rcp zu löschen alle Objekte des passenden hm-rcp zu löschen. danach neu installieren und es läuft alles bestens.

Community Forum

NEWS

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

Support us

405

32.5k

81.7k

1.3m