ioB auf mehrere Installationen verteilen?

[Humidor]

@samson71 wollen, nein da missverstehst du mich. Ich habe im Syno-Forum auch schon nachgefragt, da wird kein Fehler im Docker gesehen, die Einstellungen sollten passen und sind auf max. Aber, es läuft langsamer, je mehr ich mache, das kann so nicht weitergehen.

kann ich die performance von iob auslesen, sehen welche Adapter da fressen?
auch meine ganzen Blockly scripts können da natürlich belasten, durch falsche code-verwendung....

[lesiflo]

@Humidor
Ich sehe es genauso wie einige meiner Vorredner. Ich hatte vorher auch eine Master/Slave Kombi mit 2 x Raspi 4 (4 und 2 Gb Ram). Bin vor kurzem auf einen Mini-PC mit 4 Kernen und 8GB RAM gewechselt. Allerdings nutze ich proxmox. Die Performance ist wesentlich besser als mit den Raspi's und Backup auch einfacher. Hast du mal mqtt abgeschaltet? Ich würde auch schauen woran das liegt und mal nach und nach Adapter und Scripte ausschalten.

[Samson71]

@humidor
Alles gut. Ich kann Dich verstehen, bzw. habe Dich verstanden. Ich wollte halt nur die "Empfehlung" geben, statt einen zusätzlichen Slave an die Installation zu nageln, eine ganz andere Basis als "Komplettsystem" auszuprobieren. Ich habe z.B. vor kurzem auf einen Lenovo M920q Tiny (6-Kerner mit 32GB und 512GB SSD) mit Proxmox umgestellt und absolut keine Performance Probleme. Da läuft u.a. ioBroker als LXC, neben Wireguard, PiHole und Co und es ist immer noch Luft nach oben.

[Humidor]

@samson71 kein Problem! ich sehe die Syno hier als mind. gleichwertig an. Daran wirds nicht liegen. Woran dann, der ioB läuft im Docker und lastet den Container zu 100-200% aus, die Syno selbst rappelt um 20%. Da ist mM der Hund begraben.
Dennoch, es gibt doch so Linux Befehle mit der man die Auslastung analysieren kann, ich habe nur leider kA von Linux.

[lesiflo]

@humidor Schau mal auf linux mit z.B. "htop" oder "top" wenn installiert ist. Kannst du aber mit

sudo apt install htop

nachinstallieren

[Humidor]

@lesiflo danke!

[Humidor]

@humidor das ist der Rasp3B+ mit nur einem Adapter

[Marc Berg]

@humidor

Ich würde fast darauf wetten, dass du dir in deinen vielen MQTT Instanzen irgendwo eine Schleife reingebaut hast. (wenn ich mich richtig erinnere, hast du in deinen Victrons noch weitere Broker und Clients am Laufen?)
Das Ganze wird dann wohl auch noch fleißig vom History-Adapter mitgeloggt, und schon hast du ein System, das vorrangig mit sich selbst beschäftigt ist.

[lesiflo]

@humidor Ich würde mal nacheinander den history, web und javascript Adapter aus und einschalten und schauen was passiert. Schon mal "iob fix" laufen lassen?

[Humidor]

@lesiflo iob fix frisst er mir grad nicht im Docker Terminal, muss da zuerst alle Adapter stoppen

History habe ich bei den Mqtt noch nicht am laufen, ja das mit Mqtt ist ein Thema, ich kapier das anscheinend nicht richtig. 1 Broker(andere Dinge), 3 Slaves zu Victron Cerbos bwz. 1 Raspi.
Node Red läuft nicht (mehr) am ioB nur auf den Victron Cerbos. Per Blockly starte ich das zykl. subscribe von Allem (system #), dann schreibe ich auf 5 Werte, mehr ist da nicht.
Aber ob da eine Schleife drin ist, kA ?

top wirft aber die mqtt gar nicht als die Fresser aus, history scheint mir da ganz vorne
da werden Werte gesichert, auch in influxdb.

[Humidor]

hab mal jetzt einige Adapter gestoppt, mit top schaut das für mich normal aus?

die docker auslastung hat sich von 100 auf 40% reduziert, allerdings noch diese spikes

ohne mqtt Adapter:

ohne mqtt hat sich der docker beruhigt

sobald ich irgendwas im iob mache, adaper starte, schießt mir die Aulastung hoch, OK für einen Startmoment ja kein Problem, aber ist hier einfach ein Flaschenhals irgenwo drin?

[lesiflo]

@humidor Dann tippe ich mal auf mqtt. Schon mal alles außer mqtt aktiviert? Für was nutzt du mqtt?
Ich würde auch mal im iobroker den Log-Level für mqtt auf "info" setzen. Dann kannst du eventuell sehen was
die Last erzeugt. Normal ist aber aber "error" damit er nur die Fehler ausgibt.

[lesiflo]

@Humidor Den "iob fix" würde ich trotzdem mal laufen lassen. Ist dein System auf dem neuesten Stand?

[Humidor]

@lesiflo anhand der grafen und der testreihenfolge, sehe ich nicht das große Problem bei mqtt, nur die sparkes.

iob fix kann ich im docker nicht anwenden, dazu muss iob stop sein, das geht aber nicht, dann habe ich kein Terminal, ist ja kein raspi odgl.

wie gesagt, mqtt.0 Broker zu div. Endgeräten, Wallboxen usw.
mqtt.1-3 zu den Victron Cerbo Brokern

ich werde mal nur den mqtt.0 anwerfen und alle anderen Adapter mal sehen.

[Humidor]

@humidor das ist jetzt mit allen notwendigen Adaptern, ohne History und mqtt

[Humidor]

@humidor das jetzt mit History, ohne mqtt

[Humidor]

@humidor das jetzt mit mqtt.0 Broker

im log sehe ich keine Auffälligkeiten

[Humidor]

die Auslastung bleibt im Rahmen, es spitzt sich nun doch zu auf die mqtt Clients...

die history scheint aber den iob gut zu beanspruchen....
wenn ich schon die influxdb habe, macht mir dann history noch sinn, ich habe mich mit influx und grafana noch nicht groß beschäftigt, sehe ich als Zufunkt und deswegen logge ich schon in die influx
auf der history hängen die E-Charts und solches VIS Zeugs drauf
history und javascripts haben die meisten Ereignisse (über 2000)

ohne history fällt es gleich wieder ab

[Humidor]

mit allen mqtt, ohne history
der spark wird durch einnen client verursacht, denke ich mal, da gibts was zu tun
der letzte Berg vor dem spark war das Starten der adapter

[Humidor]

auf mqtt Client kommt sowas daher, kA was das sein soll, diese Einträge werden im Objektbaum auch nicht erzeugt, sind das die Sparks?