mqtt Adapter 4.0.7 Hohe CPU Load

[lakelounge]

Hat außer mir noch jemand mit dem neuen mqtt-Adapter (4.0.7) und dem neuen Admin (6.2.17) das Problem, dass die CPU-Load aus dem Ruder läuft?

[TT-Tom]

@lakelounge der adapter läuft bei mir mit 2%.
habe Dienstag das Update angestoßen. Wieviele Verbindungen hast du denn auf MQTT?

[lakelounge]

@tt-tom Danke für deine Antwort, bei mir sind das maximal 8 - 10 Verbindungen … Bis Vorgestern lief mein ioBroker auch mit ca. 2 % aber nach dem Update läuft es immer wieder aus dem Ruder. Ich hatte das schon einmal, bevor der mqtt 4.0.7 dann beim Admin 5 wieder zurückgezogen wurde. Mit dem 3.0.7 (war das glaube ich) lief alles problemlos.

[TT-Tom]

@lakelounge ich habe bei mir jetzt nochmal geschaut, sie war jetzt runter auf 0,5%

Steht sie permanent da oben? Von wieviel sprechen wir eigentlich?

[lakelounge]

@tt-tom nach einem Neustart dauert es immer ein wenig, bis es sich „aufschaukelt“. Danach geht die Load auf 2.8 bis über 3 und da bleibt sie dann auch. Hauptverbraucher sind der Javascript-Adapter und der MQTT-Adapter.
Bei meinem Raspberry 4 / 8 GB schaltet das Licht dann z. B. mit einer Verzögerung von 20 Sekunden. Der Prozessor ist also wirklich an Arbeiten.

[Asgothian]

@lakelounge sagte in mqtt Adapter 4.0.7 Hohe CPU Load:

@tt-tom nach einem Neustart dauert es immer ein wenig, bis es sich „aufschaukelt“. Danach geht die Load auf 2.8 bis über 3 und da bleibt sie dann auch. Hauptverbraucher sind der Javascript-Adapter und der MQTT-Adapter.
Bei meinem Raspberry 4 / 8 GB schaltet das Licht dann z. B. mit einer Verzögerung von 20 Sekunden. Der Prozessor ist also wirklich an Arbeiten.

Ein Load von 2,8% - 3% ist vergleichbar wenig. Trotzdem würde ich die bei Dir laufenden Skripte auf unnötige Operationen prüfen:

• Schnelles Abfragen von Datenpunkten in Schleifen an Stelle von Trägern
• Grössere Mengen von "Heartbeat" Operationen die regelmässig laufen
• mehrfach-Timeouts die nicht abgebrochen werden (der Häufigste Fehler hier ist ein 'setTimeout' innerhalb eines wiederkehrenden Triggers ohne das via 'clearTimeout' vorher bestehende Timeouts beseitigt werden.

A.

[lakelounge]

@asgothian Danke für deine Antwort! Wenn alle Prozessor-Cores zwischen 85 und 100% stehen, kann das nicht wenig sein. Man merkt am Raspberry auch, dass er warm/heiß wird. Kein Script wurde geändert und bis Vorgestern liefen die alle problemlos. Die aufgeführten Operationen können nicht das Problem sein. Es gibt keine schnellen Abfragen von Datenpunkten, keine Heartbeat-Operationen und es laufen auch keine Timeouts, die nicht abgebrochen werden. Bis vor dem Adapter-Update (mqtt 4.0.7) lagen die Prozessor-Cores meist bei 1 bis 10 % im Durchschnitt. Klar gehen die zwischendurch hoch, aber dann auch wieder runter. Das hat sich nun geändert. Jetzt bleiben sie hoch und die ganze Hausautomation arbeitet mit Verzögerungen.

[BananaJoe]

@lakelounge Als Besitzer von über 100 Geräten die sich per MQTT an meinem ioBroker Melden habe ich eine starke Vermutung woran es liegt. Du nutzt den Adapter vermutlich als Broker

Wenn du den Adapter beendest hängen alle MQTT Geräte die daran melden wollen "in der Luft". Meine ganzen Gosund SP111 Steckdosen und Klone blinken dann munter blau vor sich hin während sie versuchen sich wieder mit dem MQTT-Broker zu verbinden.

Und wenn der Broker wieder verfügbar ist (also der Adapter wieder gestartet) verbinden sich quasi alle MQTT-Geräte innerhalb von Sekunden wieder mit dem Broker, wollen Antworten und ihre Daten loswerden.

Ich hatte schon mal ca. 60 Geräte auf dem MQTT-Adapter als Broker. Kein Problem, bis zum Neustart des Adapters.
Dann hatte ich obiges Problem was sich dann selbst in eine "Todesspirale" begeben hat. Weil der Adapter eine Verbindung annahm, dem Gerät dann aber nicht immer schnell genug geantwortet hat. Darauf hin hat das Gerät die Verbindung unterbrochen und gleich wieder neu aufgebaut, der Adapter war aber doch schon bei der Antwort dabei ... so wurde es schnell immer schlimmer.

Ok, du hast "nur" 10 Geräte. Was nichts heißt, kommt ja darauf an wieviel die zu senden haben.
Also, vermutlich hast du es geschafft durch den Adapter Neustart deine MQTT-Geräte dazu zu bringen relativ gleichzeitig etwas zu wollen. Sagt das Log des Adapters? Was sagen die Geräte? Bei Tasmota kann man in der Konsole dabei zuschauen bzw. die Reconnect-Meldungen sehen.

Wenn es das ist, liegt es daran das der Adapter "zu langsam" ist. Das soll die Programmierleistung nicht schmähen, aber letztendlich ist der Adapater ein - sehr umfangreichen, ggf. aufgeteiltes - JavaScript. Und ist dann ein Prozess für sich der dann eben die Kommunikation bei so vielen Anfragen aus Sicht der Geräte nicht erledigen kann.
Der Sonoff-Adapter hat ein ähnliches Problem, der kommt mit meinen vielen Geräten auch nicht klar

Falls es das ist ... wie kommst du da wieder raus aus der Nummer?

• mehrere Adapterinstanzen nutzen (auf verschiedenen Ports)
• Externen MQTT-Broker verwenden, z.B. Mosquitto und den Adapter als Client einsetzen.
  Ich nutze den Mosquitto-Broker und der schluckt das alles bei mir locker weg. Der Adapter ist nur noch Client, wird also Benachrichtigt wenn sich etwas ändert und muss nur noch darauf reagieren.

[TT-Tom]

@lakelounge was @BananaJoe geschrieben hat klingt sehr plausibel. Wenn der Raspi ohne MQTT sauber läuft, würde ich eine Verbindung nach der anderen von Hand starten, um den Info-Schwall zu bremsen.

[lakelounge]

@bananajoe Danke für deine Antwort. Nein, ich nutze eine eigene Mosquitto-Installation als Broker. Dieser läuft zwar auf demselben Raspberry aber der Mosquitto-Prozess dümpelt irgendwo bei 1 % Prozessorleistung herum. Im ioBroker „fange“ ich nur die entsprechenden Meldungen ab. Die 10 Geräte (Wemos D1 Mini mit Tasmota 12.1.1) sind alle auf zwischen 60 und 120 Sekunden eingestellt.

[BananaJoe]

@lakelounge ok, dann solltest du nach den Dingen schauen die @Asgothian geschrieben hatte

[Asgothian]

@lakelounge sagte in mqtt Adapter 4.0.7 Hohe CPU Load:

@asgothian Danke für deine Antwort! Wenn alle Prozessor-Cores zwischen 85 und 100% stehen, kann das nicht wenig sein. Man merkt am Raspberry auch, dass er warm/heiß wird. Kein Script wurde geändert und bis Vorgestern liefen die alle problemlos. Die aufgeführten Operationen können nicht das Problem sein. Es gibt keine schnellen Abfragen von Datenpunkten, keine Heartbeat-Operationen und es laufen auch keine Timeouts, die nicht abgebrochen werden. Bis vor dem Adapter-Update (mqtt 4.0.7) lagen die Prozessor-Cores meist bei 1 bis 10 % im Durchschnitt. Klar gehen die zwischendurch hoch, aber dann auch wieder runter. Das hat sich nun geändert. Jetzt bleiben sie hoch und die ganze Hausautomation arbeitet mit Verzögerungen.

Prozessor cores Zwischen 85% und 100% sind recht weit von den vorher genannten 2.8 bis 3 weg. Aber seis drum.

Ich würde initial alle selbst geschriebenen Skripte anhalten um zu verifizieren ob die Last durch das System oder durch selbst geschriebene Skripte entsteht.

Danach die Skripte eines nach dem Anderen reaktivieren, sofern die Last herunter gegangen ist.

A.

[lakelounge]

@bananajoe wie schon geschrieben, treffen die Dinge von @Asgothian nicht zu. Heartbeat hab ich keine, Timeouts (derzeit keiner aktiv) und meine Datenpunktabfragen bzw. gelegentliches schreiben in diese hat nie ein Problem gemacht. Ich muss mal sehen, ob ich den mqtt-adapter nochmal auf 3.0.7 runter bekomme. Damit ging alles problemlos. Ich hab vorgestern Abend das Update auf 4.0.7 gemacht und gleich am nächsten Morgen ist mir das verzögerte Licht-schalten aufgefallen. Aber Danke für die Hilfe und die Anregungen!

[Homoran]

@asgothian sagte in mqtt Adapter 4.0.7 Hohe CPU Load:

Ein Load von 2,8% - 3% ist vergleichbar wenig

reden wir hier von cpu Last in % oder von load average, die über den Daumen die Anzahl Kerne nicht überschreiten sollte. Eine Load average von 3 wären dan etwa 75% Auslastung.

[mickym]

Kann ich auch nicht bestätigen - ich vermute mal dass Du eine Endlosschleife drin hast, in dem Du Zustände publishst. Ggf. erst mit Änderung sodass das Verhalten nicht sofort auftritt. Und glaube mir, bei mir läuft einiges über den Adapter

und meine CPU Last ist im grünen Bereich

Bei sind es max . 50% und ja dann habe ich vielleicht ein Verzögerung von 1-2s

Dazu läuft auch noch ein Desktop mit Firefox auf dem Raspberry - der ca. 2-3% Dauerlast erzeugt. Also wäre ich in Ruhe bei ca. 10% - was im Vergleich zu dem was bei Dir ohne mqtt läuft, ja sonst vergleichsweise hoch ist.

Ich weiß aber das ist der DVD Adapter - alle Viertelstunde und der Linux Device Adapter den ich inzwischen auf 35 Minuten eingestellt habe, sodass der nicht zur gleichen Zeit aktiv wird.

Und das was hier drüberläuft über den mqtt-Adapter ist mehr oder weniger Grundlast - alle Shellies die alle 30s - ihren Momentanverbrauch melden etc.

[lakelounge]

@homoran also ich habe von einer CPU-Last von 85 - 100 % je Core und einer Load von 2,8 bis über 3 gesprochen.

[mickym]

@lakelounge sagte in mqtt Adapter 4.0.7 Hohe CPU Load:

@homoran also ich habe von einer CPU-Last von 85 - 100 % je Core und einer Load von 2,8 bis über 3 gesprochen.

Klingt nach 100% Endlosschleife - nimm mal Zustände publishen raus.

[BananaJoe]

@lakelounge genau, zeig mal bitte die Einstellungen deines MQTT Adapters

[lakelounge]

@bananajoe gerne, sobald ich wieder Zuhause bin …

[lakelounge]

@bananajoe vielen Dank schon mal im Voraus für die Hilfe! Bei den Einstellungen lasse ich mir sehr gerne helfen. Bin eben angekommen und zum Glück ist die Auslastung heute über den Tag normal geblieben. Ich muss das weiter beobachten …