ioBroker JS killt meine Synology ?

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

[Humidor]

@bananajoe ja da dürfte ich was gefunden haben
in den Cerbos gibt es einen Node Red Baustein, der die Cennectivity zum ioBroker (Mqtt Master) abgefragt hat, das dürfte allen Übels sein, denn nun ist die Auslastung gering.

noch die Frage, woher die 8 CPU's ?

[Thomas Braun]

@humidor sagte in ioBroker JS killt meine Synology ?:

noch die Frage, woher die 8 CPU's ?

Das sind 4 Cores / 8 Threads bei der CPU. Siehe:
https://www.cpu-monkey.com/de/cpu-amd_ryzen_embedded_v1500b

[Humidor]

@thomas-braun verstanden, danke, dh das Docker Image gibt die volle Anzahl des Systems frei oder wer macht das?

[Thomas Braun]

@humidor

Die info wird aus der Hardware ausgelesen. Wird z. B. im iob diag auch gemacht:

Systemuptime and Load:
 09:25:36 up 17:14,  2 users,  load average: 0.76, 0.63, 0.55
CPU threads: 4

[Humidor]

@thomas-braun eine Anzeige des aktuellen Zustands, aber wer bestimmt es?

[Thomas Braun]

@humidor sagte in ioBroker JS killt meine Synology ?:

eine Anzeige des aktuellen Zustands, aber wer bestimmt es?

Nein, eine Anzeige der verwendeten Hardware. Wird vom Chip-Design bestimmt.

[Humidor]

@thomas-braun dh ioBroker hat über den Docker der Syno Zugriff auf die HW der Syno?

[Thomas Braun]

@humidor

Logisch. Der Docker hat ja keinen eigenen Kernel, der wird ja beim Wirt angeDOCKt.

[Humidor]

@thomas-braun alles klar, dh ioBroker sieht was da ist an HW (von der Syno) und nimmt was es kriegen kann. Einfluss darauf?

[Thomas Braun]

@humidor

Keine Ahnung, ich verwende keine Docker.

[Humidor]

@thomas-braun OK, danke!

denke das wars für diesen Thread.
JS war überlastet ? durch eine "fehlerhafte" Connection-Abfrage am Mqtt Master.
Ergebnis, zu hohe Auslastung und Ram und Absturtz des übergeorndeten Systems (Docker)

[Samson71]

@humidor sagte in ioBroker JS killt meine Synology ?:

Einfluss darauf?

Soweit ich weiß nicht. Auf den verwendeten Speicher ja, aber nicht auf die Anzahl der verwendeten CPU`s bzw. Threads. Hier kann man nur mit der Zuweisung der Priorität Einfluss nehmen.

[Humidor]

@samson71 Ja, mehr geht da nicht zum einstellen

kann man noch aus diesen Angaben sagen/erkenne, mehr oder weniger RAM geben?

[Samson71]

@humidor
Da bin ich überfragt, aber wenn die Kiste 20GB hat und Du auf 4GB limitiert hast, würde ich das in jedem Fall verdoppeln. 4GB können auch knapp werden.

[Humidor]

@samson71 jap, nur habe ich natürlich mehrere Container im Dock und sogar 20GB sind dann nicht viel.

[Humidor]

@samson71 hab die Speicherriegel der Syno getauscht, da gibt es def. auch SW-Problem, nun sind 16GB Ram wieder verfügbar und das sagt nun der ioB

und alles läuft und ist aktiviert.

[Humidor]

es bleibt stabil auf dem Level, denke die Probleme und Ursachen wurden gefunden.
ich werde noch weiter schauen , was ich optimieren kann.

Besten Dank euch!!

die Ram-Ausnutzung wird stetig mehr, ich beobachte es weiter
Ram bis auf 39% hoch und aktuell bei 37%
denke das passt.

[Humidor]

Heute noch entspannter, das passt jetzt.

[Samson71]

@humidor
Dem Screenshot nach werden jetzt auch 16GB RAM erkannt und nicht mehr (nur) 4GB. Hast Du den anders/neu zugewiesen? Scheint dann aber tatsächlich ein Problem mit einem defekten Speicherriegel gewesen zu sein.