Wieder mal: 100% CPU-Last durch MQTT

[betateilchen]

Wenn die weiteren 150 Readings _nicht_ angelegt würden und auch der gesamte Datensatz nicht dokumentiert ist (à la VW), wüsste dann aber der Ersteller gar nicht, was da so alles einläuft.

Pragmatischer Lösungsvorschlag:

Man könnte die eingehenden readings in ihrer Gesamtheit in diesem Fall, wenn sie nicht angelegt werden, einmalig (!) ins Log schreiben, anstatt sie anzulegen.

[Prof. Dr. Peter Henning]

Show MQTT Traffic

Sorry, aber das ist Unsinn. Die Anzeige des Traffic ist nicht persistent, und wenn dutzende Nachrichten in kurzer Zeit einlaufen, auch nicht sinnvoll nutzbar.
Und der Hinweis auf externe Tools auch nicht zielführend.

Auch das "einmalige Schreiben ins Log" halte ich für überflüssig. Im Device wird ja jetzt bereits ein Attribut "topics" befüllt, aus dem man mit wenigen Klicks Inhalte in die readingList übernehmen kann.

LG

pah

[Prof. Dr. Peter Henning]

Dauert maximal ein paar Minuten

Das ziehe ich bei dem Datenwust von VW doch mal in Zweifel. Hängt eben vom konkreten Fall ab.

LG

pah

[betateilchen]

Das ziehe ich bei dem Datenwust von VW doch mal in Zweifel. Hängt eben vom konkreten Fall ab.

Da könnte gesunder Menschenverstand weiterhelfen:

• Welche Informationen interessieren mich denn wirklich?
• Diese Frage kann ich grundsätzlich auch ohne Kenntnis dessen beantworten, was an Daten in ihrer Gesamtheit zur Verfügung steht.
• Und genau diese Daten suche ich mir im "Datenwust" raus und verwende sie.

Um es mal überspitzt zu sagen: Es ist mir doch völlig egal, wie oft in den vergangenen drei Wochen das vordere Fenster auf der Beifahrerseite geöffnet und geschlossen wurde.

[Prof. Dr. Peter Henning]

Ich habe jetzt noch einmal etwas mehr an den Mosquitto angekoppelt - nämlich einen ebusd, der auch eine ganz Menge Daten sendet. Und heute nachmittag wieder dasselbe Phänomen beobachtet: Im Mosquitto bleiben VW-Topics, die eigentlich vom MQTT2_DEVICE abgeholt werden sollen, auf "retained" stehen. Und parallel dazu wächst die Systemlast wieder dramatisch an, bis in FHEM wilde Latenzen auftreten.

Irgendetwas ist dabei noch faul.
1.Frage: Wieso bleiben die Daten überhaupt als  retained im Mosquitto?
2.Frage: Was macht der MQTT2_CLIENT, wenn derart viele Daten im Server stehen, die eigentlich auf Topics in einem Device passen?

LG

pah

O.T.: "Da könnte gesunder Menschenverstand weiterhelfen"... das ist es vielleicht. Den habe ich gerade verliehen.

[betateilchen]

1.Frage: Wieso bleiben die Daten überhaupt als  retained im Mosquitto?

Vermutlich, weil sie mit einem retained-Flag von Deinem Server zum mosquitto geschickt werden.

[passibe]

Falls tatsächlich retain das Problem ist, könntest du das jedenfalls bei MQTT2_SERVER auch regelmäßig clearen, z.B. 1x pro Tag mit einem at, das

Code Auswählen Erweitern

set <MQTT2_SERVER> clearRetainausführt.

[DasQ]

Ist in dem vw ein eigenständiger mqtt broker verbaut?


Wenn ja, warum abonnierst du nicht einfach nur die topics, die dich auch wirklich interessieren?

[Prof. Dr. Peter Henning]

Ist in dem vw ein eigenständiger mqtt broker verbaut?

Nein.

pah

[betateilchen]

warum abonnierst du nicht einfach nur die topics, die dich auch wirklich interessieren?

Weil das der "gesunde Menschenverstand" wäre.

Und da gibt es gerade ein Problem:

O.T.: "Da könnte gesunder Menschenverstand weiterhelfen"... das ist es vielleicht. Den habe ich gerade verliehen.

[Prof. Dr. Peter Henning]

Es freut uns doch alle, dass es hier jemanden gibt, der den gesunden Menschenverstand erklären kann.

pah

[passibe]

Verstehe nicht ganz.
Hast du denn jetzt mal probiert, diese ellenlange Liste an Topics zu reduzieren? Eventuell auch so, dass sie sich nicht überschreiben – vielleicht ist das ja auch ein Grund, wieso hier irgendwas schief läuft? Weil ein ankommender Wert sofort wieder überschrieben wird?
Oder hast du probiert, regelmäßig clearRetain auszuführen?

[Prof. Dr. Peter Henning]

So, ich bin jetzt etwas weiter.

Die hohe CPU-Last entsteht, wenn eine Vielzahl von Daten im MQTT-Server (intern als MQTT2_SERVER oder extern als Mosquitto) vorliegt und gleichzeitig eine Vielzahl von Einträgen in der readingList vorhanden ist, die als Regulärer Ausdruck formatiert sind. Insofern war der Hinweis von Rudi der Zielführende.

Was ich noch nicht ganz verstehe ist, warum das Wachstum der CPU-Last deutlich stärker als quadratisch mit der Anzahl der Topics ist - das kann man aber hinten anstellen.

Betreffend den von VW gelieferten Datenwust: Unglücklicherweise sind davon viele Daten relevant, den Unsinn, "mit gesundem Menschenverstand" erst einmal zu überlegen, was man denn eigentlich wolle, kann man sich also getrost sparen.

Die Misere wird natürlich gefördert durch den von Till Steinbach stammenden Python-Server zur Verbindung mit den VW-Servern.
Der baut intern ein gewaltig großes JSON-Objekt auf, und jedesmal, wenn ein Datenwert von VW eintröpfelt, wird der als separate MQTT Message an den MQTT-Server gesendet (und zwar mit retain-Flag).

LG

pah

[TomLee]

Der baut intern ein gewaltig großes JSON-Objekt auf, und jedesmal, wenn ein Datenwert von VW eintröpfelt, wird der als separate MQTT Message an den MQTT-Server gesendet (und zwar mit retain-Flag).

Wie ist das genau zu verstehen? Jedes mal wenn ein Datenwert eintröpfelt, wird dieser im großen Json ergänzt und der Json ohne retain-Flag gesendet und zusätzlich wird der neue Datenwert separat retained gesendet?

[Prof. Dr. Peter Henning]

Fast richtig. Der ganze JSON-Kram wird nur gesendet, wenn man das explizit freischaltet. Standard ist: Nur der neue Datenwert, mit retain_Flag.

Leicht irre, das - aber das ist Software von jemand anders. Ich versuche, den von einem besseren Ansatz zu überzeugen.

LG

pah