LogDB wird riesig, wie bereinigen/verkleinern

[Radiocarbon]

Hallo,

ich habe nun FHEM seit 2020 in Betrieb. Heute stellte ich fest, dass die Graphen in den Diagrammen seit gestern Nacht nicht angezeigt werden.
Nach suchen, woran es liegen kann stellte ich fest, mein "fhem.db" ist riesig > 9GB. Dadurch war kein Platz mehr auf der SD-Karte. Durch Systemreboot habe ich zwar ein paar temporäre Dateien verloren, aber so konnte ich wenigstens Änderungsversuche in FHEM speichern.

Aber die SQLite-Datenbankdatei ist trotzdem riesig. Selbst durch löschen (SQL-Delete in Tabelle "history" der Daten von vor 2021) wurde die Datei nicht kleiner.
Nun habe ich gelesen, irgendwas mit "configdb reorg 5" könnte Abhilfe schaffen. Aber wie wende ich das an? In der Befehlszeile der WebUI hat es keine Wirkung, es kommt nur eine Fehlermeldung, es sein ein unbekanntes Kommando, mit Hinweis auf die Hilfe. Aber das bringt mich nicht weiter, ich verstehe nicht, wie ich das anwenden kann.

Nun hoffe ich auf eure Hilfe, dass ich mein logdb verkleinern kann.

Ich checke nicht, wie ich https://wiki.fhem.de/wiki/DbRep_-_Reporting_und_Management_von_DbLog-Datenbankinhalten#(regelm%C3%A4%C3%9Figes)_L%C3%B6schen_von_Datenbanks%C3%A4tzen bei mir anwenden kann. ist wohl schon zu spät, morgen gehts weiter.

[kamp]

Hallo,

erstmal ist es sicher nicht gut für die Lebensdauer deiner SD-Karte, wenn du da drauf eine SQLite DB speicherst. Anscheinend verwendest du einen Raspberry, denke über einen Umstieg auf eine SSD nach. Dann, basierend auf deiner Angabe von 9GB, stellt sich die Frage, ob du alles loggst, oder nur das, was du auch benötigst für z.B. Plots. Es gibt hier die Möglichkeit (DBLogExclude...) nur das zu loggen, was du brauchst. Falls du wirklich so viel brauchst, stell dir die Frage, ob SQLite hier die passende Lösung ist, oder ob nicht MySQL besser und performanter wäre.

Zur eigentlichen Frage: Bei SQLite bleibt die Datei auch nach dem DELETE so groß wie zuvor, du musst ein VACUUM ausführen.

[ch.eick]

Hallo.

Zuerst solltest Du Dir ganz genau überlegen, welche von Deinen daten keinen Sinn machen.

z.B.
Daily Werte, die über den ganzen Tag immer weiter ansteigen. Am Ende des tages ist nur noch der Maximal Wert relevant.
Hier kannst Du dann für jeden der Tages Werte ein DbRep Device erzeugen und dieses dann Täglich für den Vortag laufenlassen.
Im Device muss dies dann aber wirklich ganz genau definiert sein und um das vorher zu testen macht man zuerst mal ein Display.
Du darfst diesen Dateianhang nicht ansehen.

VG Christian

[betateilchen]

"configdb reorg" hat nichts mit DbLog zu tun.

[Radiocarbon]

Hallo,

erstmal ist es sicher nicht gut für die Lebensdauer deiner SD-Karte, wenn du da drauf eine SQLite DB speicherst. Anscheinend verwendest du einen Raspberry, denke über einen Umstieg auf eine SSD nach. Dann, basierend auf deiner Angabe von 9GB, stellt sich die Frage, ob du alles loggst, oder nur das, was du auch benötigst für z.B. Plots. Es gibt hier die Möglichkeit (DBLogExclude...) nur das zu loggen, was du brauchst. Falls du wirklich so viel brauchst, stell dir die Frage, ob SQLite hier die passende Lösung ist, oder ob nicht MySQL besser und performanter wäre.

Zur eigentlichen Frage: Bei SQLite bleibt die Datei auch nach dem DELETE so groß wie zuvor, du musst ein VACUUM ausführen.

Vielen Dank für den Tipp mit VACUUM. Das würde sicherlich helfen. Leider habe ich in der Anleitung dazu gelesen, dass SQLite mit den vorhandenen Daten erst einmal eine temporäre Datenbankdatei anlegt und dann die optimierte Datei zurück schreibt. Tja, hätte ich das eher gewusst..., mir fehlt aktuell der Platz auf der SD-Card.

Zu der Frage, ob wirklich alles nötig ist mitzuloggen, kann ich nur sagen: das meiste ja, aber nicht für so lange Zeit. Eigentlich würde mir die Datenhaltung ala RRD genügen. Also aktuelle Daten feinkörnig und für grössere Zeitbereiche grobkörniger. Aber das habe ich gar nicht gerafft, wie das in FHEM funktionieren soll/kann.

Was passiert, wenn ich die Datenbankdatei einfach lösche. Wird sie durch FHEM neu erstellt oder muss ich sie neu anlegen und die beiden Tabellen selbst erzeugen?

[Radiocarbon]

Hallo.

Zuerst solltest Du Dir ganz genau überlegen, welche von Deinen daten keinen Sinn machen.

z.B.
Daily Werte, die über den ganzen Tag immer weiter ansteigen. Am Ende des tages ist nur noch der Maximal Wert relevant.
Hier kannst Du dann für jeden der Tages Werte ein DbRep Device erzeugen und dieses dann Täglich für den Vortag laufenlassen.
Im Device muss dies dann aber wirklich ganz genau definiert sein und um das vorher zu testen macht man zuerst mal ein Display.
Du darfst diesen Dateianhang nicht ansehen.

VG Christian

Danke für den Hinweis, ich habe ihn gelesen aber verstehe nicht, was du mir mitteilen möchtest.
Ich logge Daten meiner Heizung. Also Solarthermie, Pufferspeicher, Vorlauf- Rücklauf von Radiatorheizkreis und Fußbodenheizung. Dann noch Photovoltaik, Stromeingang und -ausgang.
Alle Daten werden alle 5 Minuten geloggt.

[Radiocarbon]

So, ich habe die Datenbankdatei, nach stoppen fhem, auf meinen Rechner gezogen.
Dann sämtliche Einträge in der Tabelle "history" gelöscht, und mit VACUUM die DB defrakmentiert. Danach wieder auf den Raspi gespielt. Natürlich waren, wie zu erwarten, alle Daten weg. Aber die Datei wird nach dem Start von fhem in einer Minute um 100kB grösser. Ich verstehe nicht wo das her kommt. Dabei ist "defaultMinInterval" auf
".*:300::force" gesetzt. Trotzdem werden jede Sekunde sämtliche Werte geschrieben.

Das einzige, was ich in letzter Zeit geändert hatte, war das setzen von "oldreadings .*state" um den letzten Stand von den Shelly-Fensterkontakten zu halten.

Ich so, alle paar Minuten wird folgendes in die Datenbank geschrieben:

2023-06-13 23:05:40|logdb|DBLOG|state: <html>Another operation is in progress. <br>Data is stored temporarily.</html>|state|<html>Another operation is in progress. <br>Data is stored temporarily.</html>|

Wie kann ich den Übeltäter aufspüren, der da zusätzlich in die DB zu schreiben scheint?

[RalfRog]

...
Dabei ist "defaultMinInterval" auf ".*:300::force" gesetzt. Trotzdem werden jede Sekunde sämtliche Werte geschrieben.
...

.*:300::force   ist vielleicht falsch?
Lt. Beispiel in der Hilfe zu den Attributen ist es ein Doppelpunkt mehr =>  attr dblog defaultMinInterval  .*::120::force 
...und: Eventuell im Quelldevice angegebene Spezifikationen DbLogExclude / DbLogInclude haben Vorrag und werden durch defaultMinInterval nicht überschrieben.

Edit:
Ein Datenbankbackup wär vielleicht auch nicht übel.

[kamp]

ich würde dir wirklich raten, zu einer MySQL Datenbank zu wechseln, denn ich finde es einfacher, dort dann über phpmyadmin diverse Skripte einzuspielen, damit die DB nicht ins unermessliche wächst. Aber wie gesagt, ich würde das nicht auf einem Raspi mit SD-Karte laufen lassen, denn SD Karten haben eine sehr schlechte Eigenschaft: von einer Sekunde auf die andere sind sie kaputt ohne große Vorankündigung und alle Daten sind weg.
In deinem Fall wäre es vermutlich auch einfacher, damit du live siehst, was gerade geloggt wird und du deine Config auf deine Wünsche anpassen und Fehler berichtigen könntest.

[ch.eick]

Hallo.

Zuerst solltest Du Dir ganz genau überlegen, welche von Deinen daten keinen Sinn machen.

z.B.
Daily Werte, die über den ganzen Tag immer weiter ansteigen. Am Ende des Tages ist nur noch der Maximal Wert relevant.
Hier kannst Du dann für jeden der Tages Werte ein DbRep Device erzeugen und dieses dann Täglich für den Vortag laufenlassen.
Im Device muss dies dann aber wirklich ganz genau definiert sein und um das vorher zu testen macht man zuerst mal ein Display.
1.PNG

VG Christian

Danke für den Hinweis, ich habe ihn gelesen aber verstehe nicht, was du mir mitteilen möchtest.
Ich logge Daten meiner Heizung. Also Solarthermie, Pufferspeicher, Vorlauf- Rücklauf von Radiatorheizkreis und Fußbodenheizung. Dann noch Photovoltaik, Stromeingang und -ausgang.
Alle Daten werden alle 5 Minuten geloggt.

Der Hintergund ist, dass nach einiger Zeit Deine Daten auch verdichtet werden könnten.
Es könnten auch Devices gelogged werden, die später angelegt wurden, wenn dort nicht mit autocreate ein "DbLogExclude .*" eingetragen wurde.
Ich frage von Zeit zu Zeit mal alle Device in der DbLog ab und lösche die, die nicht erforderlich sind.
Bei Temperaturen könntest Du z.B. nach einem Jahr auf min, max und avg gehen, oder nur noch stündliche Werte behalten.

Hier mal einige Basis SELECT für MySQL

Code Auswählen Erweitern

## Anzeige der Datenbank Version
select version();

## Groesse der Datenbank
SELECT table_schema "DB Name",
       Round(Sum(data_length + index_length) / 1024 / 1024, 1) "DB Size in MB"
  FROM  information_schema.tables
  GROUP BY table_schema;

>>> 10.5 GB bei mir

## Alle Devices in der history Tabelle
select DEVICE from history group by DEVICE;

## Alle DEVICES in der history Tabelle
select DEVICE from history
group by DEVICE
order by DEVICE;


## Alle DEVICES und READINGS in der history Tabelle
## Achtung, hier habe ich auf den aktuellen Tag limitiert, da ansonsten die Laufzeit zu lang würde.
##      Dann werden jedoch readings, die nicht an diesem Tag kommen auch nicht mit angezeigt werden.
select DEVICE, READING from history
where TIMESTAMP > curdate()
group by DEVICE, READING
order by DEVICE, READING;

Ich verwende im Docker Container das original Oracle MySQL im 64 Bit Image auch auf einem RPI4 (64 Bit Image). Am besten auf einer SSD.
Wie bereits geschrieben, niemals eine Datenbank auf einer SD-Card betreiben!! Regelmäßig ein Backup machen und auch mal einen Restore testen.

VG  Christian

[Radiocarbon]

So, jetzt habe ich das ganze etwas beruhigen können. Alle geloggten Inputs haben jetzt "event-min-interval .*:300" erhalten. Fürs erste Okay. Als zweiten Schritt  werde ich eine USB-Festplatte anstöpseln und die Datenbankdatei dort hin auslagern.
In Zukunft werde ich FHEM wohl auf einen "richtigen" Mini-PC installieren. Habe nur noch kein für mich passendes Modell gefunden. Raspi 4 wäre ein Möglichkeit, müsste dann nur mit der M2-Erweiterung irgendwie in ein Hutschienengehäuse passen.

@ch.eick Jetzt habe ich verstanden, was du meintest. Ich behalte das im Hinterkopf, dein Ansatz gefällt mir. MariaDB ist für den neuen Rechner schon mal vorgemerkt. Danke für den Denkanstoß.

[ch.eick]

So, jetzt habe ich das ganze etwas beruhigen können. Alle geloggten Inputs haben jetzt "event-min-interval .*:300" erhalten. Fürs erste Okay. Als zweiten Schritt  werde ich eine USB-Festplatte anstöpseln und die Datenbankdatei dort hin auslagern.

Tausch bitte deine SD-Card auch aus!!!
Oder noch besser direkt Punkt "Ich verwende", aber mit direktem Boot von SSD ohne SD-Card.

In Zukunft werde ich FHEM wohl auf einen "richtigen" Mini-PC installieren. Habe nur noch kein für mich passendes Modell gefunden. Raspi 4 wäre ein Möglichkeit, müsste dann nur mit der M2-Erweiterung irgendwie in ein Hutschienengehäuse passen.

@ch.eick Jetzt habe ich verstanden, was du meintest. Ich behalte das im Hinterkopf, dein Ansatz gefällt mir. MariaDB ist für den neuen Rechner schon mal vorgemerkt. Danke für den Denkanstoß.

Ich verwende
- RPI4 64 Bit Image mit Boot direkt von einer SSD über USB3.
- Alle USB Empfänger sollten mit einer USB Verlängerung vom Gerät weg placiert werden.
- Sofort mit Docker beginnen
- Die original Oracle MySQL (gibt es nur in 64 Bit, s.o. 64 Bit Image für RPI4)

[frank]

So, jetzt habe ich das ganze etwas beruhigen können. Alle geloggten Inputs haben jetzt "event-min-interval .*:300" erhalten. Fürs erste Okay.

diese aussage kann nur falsch sein.
das attribut kann ggf nur mehr events erzeugen, aber nicht reduzieren.

[betateilchen]

diese aussage kann nur falsch sein.
das attribut kann ggf nur mehr events erzeugen, aber nicht reduzieren.

Du hast recht, aber der Thread bewegt sich ohnehin schon seit geraumer Zeit auf Popcorn-Niveau