ioBroker JS killt meine Synology ?

[Humidor]

Hallo Leute,
seit Tagen bin ich auf der Suche nach dem Übeltäter, meine Synology kollabiert jeden Tag so etwa gegen 5h früh. (kA ob hier eine Zusammenhang besteht).
ioBroker läuft bei mir im Docker als Container und hat Resourcen zugeteilt. Dennoch überschreiten diese den Docker und überlasten die Syno.

PlatformBetriebssystem:linux
Architektur:x64
CPUs:8
Geschwindigkeit:1783 MHz
Modell:AMD Ryzen Embedded V1500B
RAM:3.7 GB
System-Betriebszeit:08:05:28
Node.js:v20.18.1
time:1732872536090
timeOffset:-60
NPM:10.8.2
Adapter-Anzahl:547
Datenträgergröße:889.8 GB
Freier Festplattenspeicher:554.0 GB
Aktive Instanzen:21
Pfad:/opt/iobroker/
Betriebszeit:08:02:44
aktiv:true
_nodeCurrent:20.18.1
_nodeNewest:20.18.1
_nodeNewestNext:20.18.1
_npmCurrent:10.8.2
_npmNewest:10.8.2
_npmNewestNext:10.8.2

welche Möglichkeiten gibt es noch das problem genauer zu eruieren?
Besten Dank!

[BananaJoe]

@humidor sagte in ioBroker JS killt meine Synology ?:

welche Möglichkeiten gibt es noch das problem genauer zu eruieren?

Wann läuft denn dein Backup? Des Containers und das des BackItUp-Adapters?

Edit: Und wenn wir schon dabei sind:
Welches Synology Modell genau?

Edit 2: 8 Kerne dem Docker zugeteilt?

[Samson71]

@bananajoe sagte in ioBroker JS killt meine Synology ?:

Edit 2: 8 Kerne dem Docker zugeteilt?

Wenn das ein AMD Ryzen Embedded V1500B ist, dann hat der nur 4 Kerne mit 8 Threads.

[arteck]

@humidor sagte in ioBroker JS killt meine Synology ?:

jeden Tag so etwa gegen 5h früh. (kA ob hier eine Zusammenhang besteht).

jede Wette da springt das backup an..hat keine ressourcen mehr und ..bäm

[Humidor]

@arteck Hallo! bin wieder da.
Ja, das Backup haut rein um 5:00, jetzt ist aber noch immer 100% Auslastung, kann das so hängen bleiben?

DS1621+ mit 20GBRam

diese JS Version ist gerade drin, da ich vom Docker Image last zurück gegangen bin, denke ich werde mal das Update vom Image machen, oder?

da stehts, 8 CPU's

das macht es an der Syno:

die Frage: welche Settings sind OK bei meiner HW?
ich habe gerade den Container gestoppt, spiele das Last Update ein, dann begrenze ich die zur Vergüng stehenden Resourcen, nur auf welche Werte.

[BananaJoe]

@humidor runter auf 3 oder 4 Kerne (denn deine CPU hat nur 4 "echte", also 3 damit einer für das NAS bleibt).
Und verdopple den RAM von 4 auf 8. Das sieht zwar auf dem einen Screenshot nach 8 aus, aber top zeigt nur 4.
Und wenn der Rest des RAMs eh nur ungenutzt vor sich hinschlummert weil du nichts anderes damit machst, dann darf es auch gerne noch etwas mehr sein.

Und nimm mal htop statt top, ist ein top mit - wie ich finde -besserer Anzeige.

[Humidor]

so, alles von vorne, die Syno läuft, Docker ioBroker Container auf latest, läuft

ioBroker läuft, mit den nötigsten
woher kommen die 8 CPU's ?

alle Adapter sind aus bis auf admin, cloud, iot, vis und web.

sobald ich dann anfange Adapter zu starten, geht die CPU/Ram Auslastung hoch, das ist mM ja normal, aber bei Mqtt sind es gleich 20% und mehr pro! Adapter und ich habe 3 davon...

und der ioBroker ist ausgelastet

[BananaJoe]

@humidor sagte in ioBroker JS killt meine Synology ?:

sobald ich dann anfange Adapter zu starten, geht die CPU/Ram Auslastung hoch, das ist mM ja normal, aber bei Mqtt sind es gleich 20% und mehr pro! Adapter und ich habe 3 davon...

Naja, der erste ist könnte ein Broker sein? Der war gerade aus, also werden alle Geräte die den gerade nutzen geichzeitig versuchen sich wieder zu verbinden. Als darf der nach dem Start mal eben 5 Minuten etwas höher lasten

[Humidor]

@bananajoe sehe nach geraumer Zeit kurz 27% und dann lange 83%, wiederholend

hinzu kommt, das polling findet gar nicht statt, dazu müsste javastrict lauf, dort wird das polling gestartet
dh die Mqtt sind nur aktiv und schon belastet es die CPU massiv! zumindest von Clients nicht.

[Humidor]

sobald der mqtt.0 Server läuft, läuft auch J auf Hochtouren

wenn ich mqtt.o stoppe:

es kommuniziert ein bsc (esp, liest die Daten per BT von einer Speicherbatterie ein) und 2 goE Wallboxen
was soll daran so tragisch sein?

Anhand vom Timestamp sehe ich auch, dass sich dort nicht viel bewegt. Mqtt aktualisiert ja nicht zyklisch, nur bei Änderung, das wäre ja der Vorteil....

sobald ich den mqtt.o stoppe, ist die Auslastung = 0%

jetzt habe ich mein javascript gestart, dh das lesen von mqtt1 und 2 ist aktiviert

die Auslastung bleibt gering

[Armilar]

@humidor

Warum laufen alle 3 Instanzen des MQTT auf Port 1883?

[Humidor]

@armilar sollten die unterschiedlich eingestellt werden?

[Armilar]

@humidor

Jap und die Clients entsprechend auch...

[Humidor]

@armilar ändere ich den Port im mqtt.1 und im Cerbo (Mqtt Broker) auf 1884, kommunizieren die Dinger nicht mehr miteinander?

[Thomas Braun]

@humidor

Services dann auch neugestartet?

[Humidor]

@thomas-braun immer natürlich, nein will nicht, weiß da nicht weiter.

[Armilar]

@humidor

Setze die Ports immer in mind. 2er Schritten. Wenn der MQTT.0 auf 1883 steht, dann nutzt der wahrscheinlich ebenfalls den 1884.

Also den MQTT.1 auf 1885 und den MQTT.2 auf 1887

Falls da noch ein Sonoff-Adapter, Shelly-Adapter oder anderer Adapter mit MQTT aktiv ist, dann dort auch abweichende Ports nutzen. Die stören sich sonst gegenseitig.

[Humidor]

@armilar es will nicht, sobald ich den mqtt.0 (Broker) abdrehe, fkt. irgendwie vieles nicht mehr in den Victron Cerbos (Node Red), die Cerbos sind aber Broker.
über die Clients lese ich die Werte der Cerbos aus, eine Änderung des Ports fkt. nicht.
da ist der Wurm drin.

am meisten frisst der JS Controller, ist das Sinn der Sache?
hmm, ist die % Anzeige vom JS die Summe aller Prozesse?

[BananaJoe]

@armilar sagte in ioBroker JS killt meine Synology ?:

@humidor

Warum laufen alle 3 Instanzen des MQTT auf Port 1883?

STOP Warum soll da was an den Ports geändert werden?
mqtt.0 ist ein Broker, und der darf - wenn frei - natürlich auf Port 1883 laufen
mqtt.1 ist ein Client - und natürlich darf der sich zu einen Broker verbinden der auf 1883 läuft. Lokal belegt er damit den Port nicht, das ist der Zielport zu dem er sich verbinden will
mqtt.1 dito, siehe mqtt.0

[Humidor]

@bananajoe mqtt.0 ist der Broker, der hat mit meinen 2 Cerbos nichts zu tun. dennoch fkt. dann einiges auf den Cerbos nicht mehr, wenn ich ihn stoppe. Ich habe echt noch kA warum das so ist. Die Broker und Client Instanzen im ioBroker haben keine Abhängigkeiten zueinander oder? Es verbinden sich aber auch andere Geräte auf diesen Broker.
jede Instanz eines mqtt erzeugt eine Grundlast am ioBroker, denke ein weiterer Broker um die anderen Geräte auf einen anderen Port zu leiten, wird das System weiter an den Rand bringen. Außer durch die Mehrbelegung entsteht ein Problem, dass mehr Rechenleistung verursacht, als gewöhnlich (das weiß ich nicht).

Ich möchte mal rausfinden, warum da Zusammenhänge sind. Das gefällt mir nicht.
Die Victron Cerbos (bessere Raspis) haben einen Mqtt Broker am laufen. (den Port verändern habe ich noch nicht raus bekommen wie). Ich möchte nur per Clients zum ioBroker Daten holen, über die Clients kann dann auch ein Pfad geöffnet werden zur Kommunikation, das mache ich so. dh der ioBroker gibt eine Paar Werte rüber zur Steuerung an die Cerbos. Mehr ist da nicht.
Normalerweise wäre die Topology von Mqtt so, dass sich die Client anmelden und dann schickt der Broker geänderte Daten durch. Warum auch immer, muss ich einen Alive alle 30s machen, dass diese Verbindung aufrecht bleibt sonst beendet der Master diese nach ca.60s. In der Instanz wäre das eigentlich mit "Dauerhafter Session" aktiviert, so meine Interpretation, fkt. leider nicht. Das ist aber meine geringste Sorge.

Das Ziel wäre jetzt den Mqtt Broker im ioBroker zu stoppen (die verbundenen Geräte sind nur Datenlieferanten, die erstmal kalt gestellt werden können), dann rausfinden, warum am Cerbo Funktionen ausfallen.