Autor Thema: [GELÖST] - fhem.save wächst, System wird träge bis es nicht mehr reagiert ....  (Gelesen 532 mal)

Offline traders-banquet

  • New Member
  • *
  • Beiträge: 26
Ich habe ein Problem und bisher keine Lösung.

Die fhem.save ist bei mir im Log-Verzeichnis von Fhem.
Diese Datei wächst, zuletzt zu einer Größe von 151 MB. Das hatte zur Folge, dass sich das Webfrontend nicht mehr aufrufen lies und auch Ereignisse ( Reaktionen auf Bewegungsmelder ) sehr verzögert ausgeführt wurden.
Es half nur den Fhem Prozess abzuschießen, die fhem.save zu löschen und Fhem wieder zu starten. Ein Versuch eines neustarts habe ich nach einer Stunde abgebrochen, in der Fhem Log stand including fhem.save und nach einer Stunde hatte ich die Geduld verloren und den Prozess beendet, die fhem.save gelöscht und Fhem neu gestartet.
Jetzt habe ich erstmal ein sehr fluffiges System, die fhem.save hatte nach dem ersten abspeichern gerade mal 400 KB. Anweisungen werden sofort ausgeführt, sowie Reaktionen auf Bewegungen über einen Bewegungsmelder werden sofort ausgeführt. Leider hatte FHEM durch diese Aktion sämtliche Zustände vergessen.

Ich frage mich, was kann man tun, damit die fhem.save derart wächst, dass Fhem nicht mehr auf Anfragen ragiert ? Kann man diese Menge, 151 MB ist wahrlich nicht wenig, beeinflussen ? Kollegen haben in der gleichen Datei vielleicht 7-10 MB.
Ich habe in meinem System 14 Fensterkontakte, 10 Heizungsthermostate, 35 Sonoff Geräte mit Tasmota, 6 Zigbee Geräte und ein paar Abfragen der örtlichen Tankstellen, ein paar Unify Geräte ein Nuki .... etc. das war es auch schon.

Hat jemand vielleicht einen Typ für mich, wonach ich suchen kann ? Ich beobachte dieses Phänomen schon seit einem Jahr, doch fand ich im Web bisher keine Hinweise, die mich weiter gebracht hätten.

Vielen Dank für Eure Mühen
« Letzte Änderung: Gestern um 08:48:09 von traders-banquet »

Offline betateilchen

  • Developer
  • Hero Member
  • ****
  • Beiträge: 18506
Antw:fhem.save wächst, System wird träge bis es nicht mehr reagiert ....
« Antwort #1 am: 24 November 2022, 19:42:23 »
Wir hatten vor einiger Zeit schonmal so ein Problem, damals waren, wenn ich mich recht erinnere, die retain Daten in MQTT devices (Server?) als Ursache für das übergroße statefile identifiziert.
-----------------------
Möchte man beruflich "etwas mit Menschen" machen, ohne etwas mit deren Dummheit zu tun haben zu müssen,
bleibt eigentlich nur der Beruf des Bestatters übrig.
-----------------------
Lesen gefährdet die Unwissenheit!

Offline betateilchen

  • Developer
  • Hero Member
  • ****
  • Beiträge: 18506
Antw:fhem.save wächst, System wird träge bis es nicht mehr reagiert ....
« Antwort #2 am: 24 November 2022, 19:57:30 »
ich habe es gefunden...

Zitat
ein genauerer Blick in das File hat dann unter anderem offenbart, was Beta-User schon vermutet hat: MQTT retain Müll. Extrem viel davon. Ich hab den mit set <MQTT2_SERVER> clearRetain gelöscht. ...

Tut alles wieder so, wie's soll.

https://forum.fhem.de/index.php/topic,129404.msg1237333.html#msg1237333

Dass es damals um einen Nutzer mit configDB geht, ist dabei nicht relevant.
« Letzte Änderung: 24 November 2022, 19:59:03 von betateilchen »
-----------------------
Möchte man beruflich "etwas mit Menschen" machen, ohne etwas mit deren Dummheit zu tun haben zu müssen,
bleibt eigentlich nur der Beruf des Bestatters übrig.
-----------------------
Lesen gefährdet die Unwissenheit!
Informativ Informativ x 1 Liste anzeigen

Offline rudolfkoenig

  • Administrator
  • Hero Member
  • *****
  • Beiträge: 25812
Antw:fhem.save wächst, System wird träge bis es nicht mehr reagiert ....
« Antwort #3 am: 24 November 2022, 20:49:38 »
Ich habe fhemdebug mit dem Befehl "sizeInFile" erweitert, das sollte die Suche nach dem Verantwortlichen vereinfachen.

Offline traders-banquet

  • New Member
  • *
  • Beiträge: 26
Großartig, mit dem Befehl set MQTT2 clearRetain ist das Problem gelöst, meine Datei war schon wieder auf 2,5 MB angeschwollen, also noch vollkommen klein, doch mit dem Befehl sind sie auf 1,5 MB geschwunden. Die Ursache wird in meinem Falle : OpenMQTTGateway_ESP32_BLE sein. Dieses Device entdeckt täglich derart viele Geräte, das ich mich schon mehrfach gefragt habe, wo die alle sein sollen und der Verdacht nahe liegt, das auch in Geräten BLE Devices stecken, in denen dies nicht vermutet wird. Ich werde mich wohl nochmal mit dem OpenMQTTGateway_ESP32_BLE beschäftigen müssen und die white_list verwenden. Bisherige Versuche scheiterten leider immer. Ich wohne ländlich und in BLE Reichweite sind um mich herum 3 weitere Häuser. Ich habe täglich über 250 Geräte, welches das OpenMQTTGateway_ESP32_BLE entdeckt.

Vielen Dank
Informativ Informativ x 1 Liste anzeigen

Online frank

  • Hero Member
  • *****
  • Beiträge: 11143
Zitat
Dieses Device entdeckt täglich derart viele Geräte, das ich mich schon mehrfach gefragt habe, wo die alle sein sollen
vielleicht vorbeiziehende handy/navi von fussgängern/fahrzeugen?
FHEM: 6.0(SVN) => Pi3(buster)
IO: CUL433|CUL868|HMLAN|HMUSB2|HMUART
CUL_HM: CC-TC|CC-VD|SEC-SD|SEC-SC|SEC-RHS|Sw1PBU-FM|Sw1-FM|Dim1TPBU-FM|Dim1T-FM|ES-PMSw1-Pl
IT: ITZ500|ITT1500|ITR1500|GRR3500
WebUI [HMdeviceTools.js (hm.js)]: https://forum.fhem.de/index.php/topic,106959.0.html

Offline rudolfkoenig

  • Administrator
  • Hero Member
  • *****
  • Beiträge: 25812
Zitat
Ich habe täglich über 250 Geräte, welches das OpenMQTTGateway_ESP32_BLE entdeckt.
Meine Theorie:
- Android/Apple Telefone wechseln staendig die Bluetooth Adressen, damit man fuer Ladenanbieter/etc nicht verfolgbar wird.
- OpenMQTTGateway kann nicht solche Adressen identifizieren, und stuft sie jeweils als neues Geraet ein.
- OpenMQTTGateway sendet die Daten mit der retain MQTT-Flag an dem MQTT Server weiter. Wenn ich die Diskussion im Internet verstehe, damit angeschlossene HA-Systeme beim Startup alle Daten mitkriegen. Habe keine Option gesehen, um retain abschalten zu koennen.
- MQTT2_SERVER nimmt retain ernst, und speichert Nachrichten mit retain.

Bisher gab es in MQTT2_SERVER keine Moeglichkeit, retain Messages zu filtern.
Ich habe die Funktion des ignoreRegexp MQTT2_SERVER Attributes erweitert: ab sofort werden zutreffende Nachrichten nicht  gespeichert (falls retain gesetzt ist), noch an andere Clients weiterverteilt.
Gefällt mir Gefällt mir x 1 Liste anzeigen

Offline rob

  • Sr. Member
  • ****
  • Beiträge: 600
Vielen Dank an Euch. Anfang Oktober war mein statefile auf 154MB angeschwollen. Dachte ich hab was verwurstet und mich nicht getraut mich zu outen.
Seitdem ermittle ich die Größe bei jedem save und zeige das grafisch an, um ein Gefühl zu bekommen, wie schnell das geht. Bisher aber bei niedlichen 660KB.

Retain klingt sehr plausibel. Meine Kameras senden nämlich Snapshots bei MotionDetection und das steht leider auch im retain drin (bisher nur im Ganzen abschaltbar). Seit Oktober sind die ausgeschaltet, was das niedliche statefile erklären würde.

Würde auch ein "hideRetain 1" hier helfen? Oder wird das hidden Reading trotzdem ins statefile geschrieben? Hab ich so konkret nicht aus der commandref herausgelesen.

Offline kroman

  • Full Member
  • ***
  • Beiträge: 135
Zitat
Ich werde mich wohl nochmal mit dem OpenMQTTGateway_ESP32_BLE beschäftigen müssen und die white_list verwenden. Bisherige Versuche scheiterten leider immer.

Ich habe die whitelist im OpenMQTTGateway so gesetzt - funktioniert wunderbar.

set mqtt2server publish -r home/OMG1/commands/MQTTtoBT/config {"white-list":["xx:xx:xx:xx:xx:xx","yy:yy:yy:yy:yy:yy","zz:zz:zz:zz:zz:zz"]}

Offline rudolfkoenig

  • Administrator
  • Hero Member
  • *****
  • Beiträge: 25812
Zitat
Würde auch ein "hideRetain 1" hier helfen?
Nein. Wie der Name schon sagt, es verhindert nur die Anzeige.
Statt im RETAIN Reading werden die Daten im .RETAIN gespeichert.

Offline Steigerbalett

  • Jr. Member
  • **
  • Beiträge: 57
    • timeloop.de by Steigerbalett
Meine Theorie:
- Android/Apple Telefone wechseln staendig die Bluetooth Adressen, damit man fuer Ladenanbieter/etc nicht verfolgbar wird.
- OpenMQTTGateway kann nicht solche Adressen identifizieren, und stuft sie jeweils als neues Geraet ein.
- OpenMQTTGateway sendet die Daten mit der retain MQTT-Flag an dem MQTT Server weiter. Wenn ich die Diskussion im Internet verstehe, damit angeschlossene HA-Systeme beim Startup alle Daten mitkriegen. Habe keine Option gesehen, um retain abschalten zu koennen.
- MQTT2_SERVER nimmt retain ernst, und speichert Nachrichten mit retain.

Bisher gab es in MQTT2_SERVER keine Moeglichkeit, retain Messages zu filtern.
Ich habe die Funktion des ignoreRegexp MQTT2_SERVER Attributes erweitert: ab sofort werden zutreffende Nachrichten nicht  gespeichert (falls retain gesetzt ist), noch an andere Clients weiterverteilt.
Danke.
Ich habe, nachdem FHEM bei mir faktisch eingefroren war und auch nicht mehr starten wollte, nach langer suche auch die MQTT Retain Nachrichten als Übeltäter ausfindig gemacht. Aber nachdem das Thema hier im Forum bisher unter meinem Radar lief hab ich das per per regelmäßigem löschen der Daten für mich mehr schlecht als recht erledigt...

Offline betateilchen

  • Developer
  • Hero Member
  • ****
  • Beiträge: 18506
Verständnisfrage:
In welchen Fällen ist es überhaupt sinnvoll, dieses reading in das statefile zu schreiben?
-----------------------
Möchte man beruflich "etwas mit Menschen" machen, ohne etwas mit deren Dummheit zu tun haben zu müssen,
bleibt eigentlich nur der Beruf des Bestatters übrig.
-----------------------
Lesen gefährdet die Unwissenheit!

Offline rob

  • Sr. Member
  • ****
  • Beiträge: 600
Ja, spannende Frage. Inbes. wenn jmd. das Rading aus der Anzeige ausblendet, doch weiterhin bei jedem Save/ Restart weiterhin mitschleift. Ggf. zum Triggern. Aber was macht da Sinn?

Btw.: Bei den MQTT2-Devices gibt es das klasse Feature "periodicCmd" womit man aufräumen kann. Als workaround könnte man ein Device auserwählen und den Server mit aufräumen.
Ich hab aber ein at auf Verdacht angelegt, um retain darüber periodisch zu säubern.

Offline rudolfkoenig

  • Administrator
  • Hero Member
  • *****
  • Beiträge: 25812
Zitat
In welchen Fällen ist es überhaupt sinnvoll, dieses reading in das statefile zu schreiben?
Laut RFC:
Retained messages do not form part of the Session state in the Server, they MUST NOT be deleted when the Session ends [MQTT-3.1.2.7].
Aus diesem Grund habe ich, ohne laenger nachzudenken, Nachrichten mit retain persistiert.

Im Fall eines gewoehnlichen(!) MQTT-Servers kann man mit solchen Nachrichten neu hinzugekommenen Subscribern mitteilen, welche Publisher ueberhaupt mitmachen, oder deren aktuellen Status liefern, ohne dass die Sender einzeln gefragt werden muessen.

Falls der MQTT Server nur fuer FHEM verwendet wird, ist Retain vermutlich sinnlos.
Ich schlage vor Retain per Voreinstellung zu ignorieren, im Sinne von nicht speichern.

Gefällt mir Gefällt mir x 1 Informativ Informativ x 1 Liste anzeigen

Offline betateilchen

  • Developer
  • Hero Member
  • ****
  • Beiträge: 18506
Danke für die Erklärung.

Ich schlage vor Retain per Voreinstellung zu ignorieren, im Sinne von nicht speichern.

Das wäre auch mein nächster Vorschlag gewesen  :)


--
« Letzte Änderung: Heute um 12:34:31 von betateilchen »
-----------------------
Möchte man beruflich "etwas mit Menschen" machen, ohne etwas mit deren Dummheit zu tun haben zu müssen,
bleibt eigentlich nur der Beruf des Bestatters übrig.
-----------------------
Lesen gefährdet die Unwissenheit!

 

decade-submarginal