[gelöst] fhem.save Files in der configDB sind riesig

[drhirn]

Hallo,

meine ConfigDB ist plötzlich riesig geworden (1,9GB). Schuld sind die *.fhem.save Files. Ich würde jetzt gerne heraus finden, was genau die Files so groß macht. Meine Versuche, die mit configdb fileexport 6491a6d9090ff043a949f0dba3606c19.fhem.save zu exportieren und rein zu schauen waren leider nicht erfolgreich: No data found for file ./6491a6d9090ff043a949f0dba3606c19.fhem.save .

Auch mein Versuch, ein File mit writefile aus der sqlite-DB zu bekommen war nicht von Erfolg gekrönt.

Wie könnte ich sonst dem Grund für die Dateigröße auf die Schliche kommen? Oder hat jemand eine Idee, warum die plötzlich so groß sein könnten?

Danke!
Stefan

P.S.: auto_vacuum ist gesetzt, ein manuelles vacuum hat nichts gebracht.
P.P.S.: reorg ist gemacht (dauert ca. 20min, wie ein save auch), maxversions ist auf 10
P.P.P.S.: configdb fileexport all funktioniert. Weiß aber trotzdem nicht, warum die so groß sind (168MB pro File).

Code Auswählen Erweitern


-----------------------------------------------------------------
configDB Database Information
-----------------------------------------------------------------
d:$Id: configDB.pm 26297 2022-08-07 13:19:35Z betateilchen $
c:$Id: 98_configdb.pm 26443 2022-09-25 11:17:51Z betateilchen $
-----------------------------------------------------------------
dbconn: SQLite:dbname=/opt/fhem/configDB.db
dbtype: SQLITE
dbsize: 1.78 GB
-----------------------------------------------------------------
loaded:       13b60dd506e01d090d745ebdb19a2dc9
max Versions: 10
lastReorg:    Thu Sep 29 15:25:03 2022
config:       37572 entries

Ver 0 saved: Thu Sep 29 15:25:02 2022 def: 222 attr: 1777
Ver 1 saved: Thu Sep 29 15:19:43 2022 def: 222 attr: 1777
Ver 2 saved: Thu Sep 29 15:15:11 2022 def: 222 attr: 1777
Ver 3 saved: Thu Sep 29 15:01:13 2022 def: 222 attr: 1777
Ver 4 saved: Thu Sep 29 14:53:49 2022 def: 221 attr: 1776
Ver 5 saved: Thu Sep 29 14:52:33 2022 def: 221 attr: 1776
Ver 6 saved: Thu Sep 29 14:42:51 2022 def: 221 attr: 1778
Ver 7 saved: Thu Sep 29 13:12:12 2022 def: 221 attr: 1775
Ver 8 saved: Thu Sep 29 13:07:06 2022 def: 221 attr: 1775
Ver 9 saved: Thu Sep 29 11:16:40 2022 def: 221 attr: 1775
Ver 10 saved: Thu Sep 29 11:12:26 2022 def: 221 attr: 1775
-----------------------------------------------------------------
filesave: 29 files stored in database
-----------------------------------------------------------------


[drhirn]

Darf ich diesen Thread nochmal in Erinnerung rufen? Mir stürzt FHEM nämlich inzwischen bei jedem SAVE ab. Vermute, weil der zu lange dauert. Und ein Restart dauert ziemlich lange.
Kann ich euch noch irgendwie mit Infos dazu versorgen? Wenn ja, mit welchen?

Danke!

[betateilchen]

Darf ich diesen Thread nochmal in Erinnerung rufen?

Nach weniger als 24 Stunden? Hey, wir machen das hier alle in unserer Freizeit!

Meine erste Vermutung: Du hast irgendwelche devices, die riesige Datenmengen abspeichern.
Oft sind das irgendwelche HTTPMOD devices, bei denen komplette Webseiteninhalte in readings geschrieben werden.

[Beta-User]

Hmm, habe jetzt auch mal geschaut, und kam auch auf 1.3GB, was definitiv nicht normal ist.

Nach einem "reorg" (mit default, Dauer keine Minute, auch SQLITE) war das wieder auf 40MB, was immer noch viel ist, aber vermutlich mit dem retain-Mist mancher MQTT-(Hardware-) Devices zu tun hat, den MQTT2_SERVER halt mit abspeichert.

Eine durchschlagende Idee, was du tun könntest habe ich grade auch nicht, vermute aber, dass die .save-Dateien das eigentliche Problem sind. Notfalls mal eine Sicherungskopie machen und versuchen, einfach alle per regex zu löschen? Dann sollte nach einem Neustart eben nur noch eine da sein.

[KlaGho]

Ich hatte heute morgen das gleiche Problem: fhem.save plötzlich ca.90 MB.
Allerdings benutze ich nicht "config.db".

Meine vage Vermutung: ich habe mit DOIF cards experimentiert. Hierbei werden Daten zusätzlich in FHEM.save gesichert.

Ich hatte viele Fehlerhinweise vom DOIF im Logfile, dann ließ sich FHEM nicht mehr starten: out of memory (top untility in der Linux console)
Stop FHEM via console "systemctl stop fhem" dauerte ca. 4Min.

Nachdem ich ein FHEM.save vom nächtlichen Backup zurückgeladen und die Fehler in DOIF cards korrigiert habe funtioniert FHEM wieder.

[betateilchen]

Eine durchschlagende Idee, was du tun könntest habe ich grade auch nicht, vermute aber, dass die .save-Dateien das eigentliche Problem sind. Notfalls mal eine Sicherungskopie machen und versuchen, einfach alle per regex zu löschen? Dann sollte nach einem Neustart eben nur noch eine da sein.

Das mit der Sicherungskopie ist eine gute Idee, aber das Löschen muss man nicht per regex machen, dazu reicht auch ein "configdb reorg 1", damit bleibt auch nur die letzte Version übrig.

Die aktuell verwendete ID der Konfiguration findet man übrigens in "configdb info" unter "loaded", im Beispiel: 13b60dd506e01d090d745ebdb19a2dc9
Der Name des statefile leitet sich aus dieser ID ab.

[drhirn]

Nach weniger als 24 Stunden? Hey, wir machen das hier alle in unserer Freizeit!

Ja, tut mir leid! Ist sonst eigentlich nicht meine Art. Aber so ein nicht funktionierendes FHEM ist schon lästiger als man glauben würde .

Nach dem reorg 1 habe ich noch 2 Versionen übrig. Die DB hat aber halt immer noch 500MB.

HTTPMOD hab ich in letzter Zeit eigentlich keines neu erstellt, aber ich schau mir die genauer durch. Die MQTT retains sind auch nicht wirklich viel. Dem gehe ich aber auch noch genauer auf den Grund. DOIF Cards verwende ich nicht.

Ich hab das Gefühl, das ganze hat nach meiner Endlosschleife und dem Recovery mittels configdb angefangen. Aber so richtig kann ich mir das auch nicht erklären.

Kann man den Inhalt der save-Files irgendwie lesbar darstellen?

[betateilchen]

Mach doch mal was anderes - bitte GENAU das machen!

Code Auswählen Erweitern


attr global configfile test.cfg
attr global statefile ./log/test.save
save config
shutdown restart


Dann wird ein aktuelles statefile nach ./log/test.save geschrieben, das Du analysieren kannst.
Die beiden test.* Dateien kannst Du danach bedenkenlos löschen.

[drhirn]

Wie kann ich das dann analysieren? Mit einem cat stehen nur komische Zeichen drin.

Das ganze endet in

Code Auswählen Erweitern


2022.09.30 16:28:19 1: RMDIR: ./restoreDir/save/2022-03-31
2022.09.30 16:28:19 1: copy ./log/test.save ./restoreDir/save/2022-09-30/./log/test.save failed:No such file or directory
2022.09.30 16:28:22 1: copy config ./restoreDir/save/2022-09-30/config failed:No such file or directory
2022.09.30 16:28:36 1: Server shutdown delayed due to gassistant for max 10 sec
2022.09.30 16:28:36 3: gassistant: read: end of file reached while sysread
2022.09.30 16:28:36 3: gassistant: stopped
2022.09.30 16:28:37 0: Server shutdown
Can't open test.cfg: No such file or directory


Danach ist das Service gestoppt und wird nicht neu gestartet. Nach einem Neustart sie das global Device wieder aus wie vorher. save config funktioniert einfach nicht mehr.

[betateilchen]

Da stimmt aber in Deinem FHEM irgendwas ganz anderes nicht. Wieso versucht Dein FHEM bei Starten, die Konfiguration aus test.cfg zu lesen, wenn da vorher configDB drinstand? Das Attribut configfile wird im Normalfall nicht mit gesichert, insofern sollte beim "shutdown restart" automatisch wieder configDB geladen werden.

Wie kann ich das dann analysieren? Mit einem cat stehen nur komische Zeichen drin.

Bei mir steht in ./log/test.save das Statefile im Klartext:

Code Auswählen Erweitern


udo@mqtt:/opt/fhem/log$ cat test.save
#Fri Sep 30 17:15:44 2022
setstate CUX_Wetter T: 15 °C F: 65 % W: 23 km/h P: 1009 hPa
setstate CUX_Wetter 2022-09-30 16:43:45 .license Based on data from EUMETNET - MeteoAlarm [https://www.meteoalarm.eu/]. Time delays between this website and the MeteoAlarm website are possible;; for the most up to date information about alert levels as published by the participating National Meteorological Services please use the MeteoAlarm website.
setstate CUX_Wetter 2022-09-30 16:43:45 apiMaintainer Marko Oldenburg (<a href=https://forum.fhem.de/index.php?action=profile;;u=13684>CoolTux</a>)
setstate CUX_Wetter 2022-09-30 16:43:45 apiVersion v1.0.0
...


[drhirn]

Code Auswählen Erweitern


-----------------------------------------------------------------
configDB Database Information
-----------------------------------------------------------------
d:$Id: configDB.pm 26446 2022-09-26 08:03:12Z betateilchen $
c:$Id: 98_configdb.pm 26446 2022-09-26 08:03:12Z betateilchen $
-----------------------------------------------------------------
dbconn: SQLite:dbname=/opt/fhem/configDB.db
dbtype: SQLITE
dbsize: 3.27 MB
-----------------------------------------------------------------
loaded:       821c9c464b1983392eb8c2fb4f1da762
max Versions: 10
lastReorg:    Fri Sep 30 18:50:30 2022
config:       17197 entries

Ver 0 saved: Sat Oct  1 11:23:34 2022 def: 216 attr: 1390
Ver 1 saved: Fri Sep 30 18:52:57 2022 def: 222 attr: 1776
-----------------------------------------------------------------
filesave: 22 files stored in database
-----------------------------------------------------------------



Ich danke euch!
Die test.save war eh in Ordnung. Hat man nur mit "cat" nicht erkannt. Aber 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. Und bei der Gelegenheit auch noch andere alte bzw. übrig gebliebene Devices.

Tut alles wieder so, wie's soll.

Danke nochmal und schönes Wochenende!

[betateilchen]

MQTT retain Müll. Extrem viel davon. Ich hab den mit set <MQTT2_SERVER> clearRetain gelöscht.

Das sind so typische Reorganisationsaufgaben, die bei mir jede Nacht zwischen 3 und 4 Uhr in FHEM erledigt werden, wenn man sie nicht schon auf device-Ebene unterbinden kann.

[drhirn]

Jup. at ist bereits in Arbeit .