Instabiles Systemverhalten

[___manalishi]

@thomas-braun die Umstellung auf nur "Beta-Repo" und Multi-user.target" hat keine Veränderung gebracht.

Ich habe soeben nach identischer Vorgehensweise gerade wieder einen neuen LXC erstellt und ein Backup wiederhergestellt. Der neue Container läuft wieder performant wie der vorherige ohne Master-Slave Konfiguration.

der

iobroker multihost

command hat keine "disconnect" option. Ich habe daher den Folder des Slaves unter Objects gelöscht und den Slave gestoppt.

iob stop
iob fix
iob start

ausgeführt, da der Remove Button unter Hosts beim Entfernen des Slaves eine Fehlermeldung erzeugt.
Bleibt ggf. durch diese Methode eine Konfiguration erhalten, die zu den Performance Problemen führt?

[___manalishi]

@arteck Hast Du Erfahrung min Master-Slave Betrieb und weisst ggf. wie ,am eine Konfiguration "sauber" entfernt?

[ticaki]

@___manalishi

iob host remove nameVomHost

Vorher Iobroker und alle Slave anhalten hatte das problem letzte Woche

[arteck]

@___manalishi sagte in Instabiles Systemverhalten:

@arteck Hast Du Erfahrung min Master-Slave Betrieb und weisst ggf. wie ,am eine Konfiguration "sauber" entfernt?

Die gibt's nicht...

Das wasdu gemacht hast ist schon ok..ausserdem ein offline host verursacht keine performance probleme am andern host

[ticaki]

@arteck
Naja… genau das hatte ich aber letzte Woche. Sendtohostasync ist plötzlich hängen geblieben.

[haselchen]

@ticaki
@___manalishi

Den Slave entfernt man , in dem man den Ordner unter System löscht.
Dazu Expertenmodus einschalten.
Bei nächsten Start ist der Slave dann weg.

[___manalishi]

@arteck ich kann das bei mir reproduzieren mit dem Slave. Das würde auch ins ursprüngliche Fehlerbild passen. In meiner Abwesenheit hat sich der Slave verabschiedet und damit die Performanceprobleme ausgelöst, die ich anfangs (von unterwegs) auf die VPN Verbindung geschoben hatte.

[___manalishi]

@ticaki said in Instabiles Systemverhalten:

ndtohostasync

steht das irgendwo im Logfile? Ich habe da nix gefunden

[ticaki]

@___manalishi

Nein, das kann man nur raus bekommen in dem man komisches Adapterverhalten auf Entwicklerebene analysiert. Sollte aber defininitiv nicht mit einem/keinem/mehreren funktionierenden Slave passieren.

[arteck]

@___manalishi sagte in Instabiles Systemverhalten:

@arteck ich kann das bei mir reproduzieren mit dem Slave. Das würde auch ins ursprüngliche Fehlerbild passen. In meiner Abwesenheit hat sich der Slave verabschiedet und damit die Performanceprobleme ausgelöst, die ich anfangs (von unterwegs) auf die VPN Verbindung geschoben hatte.

hmmmmmmmmmm..

in welchen adapter ?

wenn der host offline ist (in deinem Fall der Salve) dann funktionieren keine adapter mehr auf diesen .. punkt.

der verliert die Verbindung zur der Datenbank (egal ob jsonl oder redis) ergo der Master sieht den nicht mehr.. punkt..

es wird auf jedenfall protokolliert was passiert ist.. auch wenn die verbindung nur kurz weg ist
so sieht das aus

also nochmal.. wenn der host wech ist und du sogar per script was dahin sendest läuft der auf timeout.. mit entsprechender Meldung

was meinst du mit sendtohostasync .. damit kannst du Befehle senden an die hosts .. macht der Admin genauso..

[ticaki]

@arteck
Das was ich geschrieben habe, letztes bleibt der Adapter an dem ich aktuell mitwirke bei Initialisieren auf meinen livesystem hängen. Also mit logs debuggt bis ich sendToHostAsync() ermittelt hatte - dann einen eigenen timeout eingebaut und geht wieder. Anschließen hab ich dann versucht den nicht vorhanden Host zu entfernen, der obwohl nicht existent mit einer höheren cpulast als 0 angezeigt wurde.

Es ist möglich, das nach einen Routerwechsel, den ich vorgenommen habe, der existierende Slave die IP des nicht existierenden zugewiesen bekommen hat...