HA Datenbank wächst und wächst und wächst und ich weiß nicht warum :-)

Jim_OS · 21. Juni 2024 um 09:37

Moin zusammen,

heute auch mal eine Frage von mir: Meine home-assistant_v2.db hat seit ein paar Wochen ein gewisses Eigenleben entwickelt und ich kann nicht nachvollziehen warum diese jetzt quasi “explosionsartig” anwächst. Bis vor rund 3 Wochen (Ende Mai) war meine home-assistant_v2.db rund 600MB groß und jeden Tag kamen nur wenig MB im einstelligen Bereich hinzu.

Ende Mai hat sich das dann plötzlich geändert und jeden Tag kamen rund 100MB hinzu, sodass sich die Datenbank innerhalb von nur 1 Woche um mehr als das Doppelte vergrößert hatte und jetzt aktuell bereits bei über 2GB liegt. Die einzigen Änderungen die ich Ende Mai durchgeführt habe waren a) das Update von Core 2024.4.x auf Core 2024.5.x und zusätzlich habe ich noch weitere 4 Zigbee Plugs eingebunden. Diese haben aber eigentlich so wenige Entitäten die in der DB erfasst werden, dass ich die als Ursache für das Problem ausschließe.

Zigbee Plug

Wie man anhand der Kurve im ersten Screenshot sehen kann habe ich dann am 09.06. per HA Boardmittel (Entwicklerwerkzeuge → Dienste → Datenbank purge) versucht die Datenbank zu “bereinigen”, was dazu geführt hat das sie von ca. 1.600MB auf ca. 1.300MB reduziert wurde. Allerdings kamen dann in den nächsten Tagen pro Tag wieder mehr als 100MB dazu.

Dann habe ich noch zusätzlich in der configuration.yaml die Haltezeit auf 10 Tage fest definiert.

recorder:
  purge_keep_days: 10

und um das mal zu testen, im Energy Dashboad alle bisher bei “Einzelne Geräte” eingetragenen Geräte (ca. 20 per Zigbee und Tasmota Plugs gemessene Verbraucher)

HA_Energy_Dashboard_Geräte
gelöscht.

Das hat dann dazu geführt das die Datenbank jetzt pro Tag “nur noch” um 50 bs 60MB anwächst,

aber das halte ich eigentlich auch für (zu) viel. Eben weil ich so einen Größenanstieg der DB aus den letzten rund drei Jahren HA Nutzung nicht kenne.

Ich habe dann mal versucht per SQLIte Abfragen anhand der Infos hier

irgendwelche Besonderheiten und/oder Probleme zu erkennen, allerdings sehe ich in den Ergebnissen der SQL-Abfragen nicht wirklich etwas was diesen DB-Anstieg erklären könnte.

Hier ein paar SQL-Anfrage Ergebnisse:

Das Einzige was im ersten Screenshot heraussticht ist der hohe Wert bei dem sensor.tasmota_mt176_p Sensor. Aber das ist der Sensor der den aktuellen Stromverbrauch beim Stromzähler per IR Lesekopf ermittelt und an HA sendet und da dieser sich ja im Sekundentakt und permanent ändert dürfte dieser hohe Wert dort wohl relativ normal sein? Auch ist der IR Lesekopf hier schon seit über einem Jahr bei HA eingebunden.

Tja verständlicherweise irritiert mich das die Größe meiner DB seit Ende Mai plötzlich so stark ansteigt, aber im Moment habe ich keine Idee mehr ob
a) 50 - 60 MB pro Tag jetzt ggf. normal sein könnten weil es bei HA mit Core 2024.5.x ggf. eine Änderung gab
oder b) ich seit Ende Mai hier irgendein Problem mit HA bzw. der DB habe.

Ich habe an verschiedenen Stellen auch schon gelesen das User mit ähnlichen Problemen tatsächlich ihre home-assistant_v2.db gelöscht und anschließend wieder neu erstellen lassen haben und dann das Problem weg war. Aber das wäre natürlich nur der ultimative letzte Schritt, da dadurch alle bisherigen Werte weg wären.

Daher hier die Frage ob irgendjemand noch irgendwelche Ideen hat was die Ursache dieses Problems sein könnte und/oder wie ich vielleicht die Ursache finden könnte.

VG Jim

dp20eic · 21. Juni 2024 um 10:19

Moin,

Lösung, nein, Gründe fallen mir auch erst einmal nicht ein, meine ist aktuell ~3 GB groß, was mich nicht wirklich stört.
Die Frage ist ja erst einmal, Prunst Du regelmäßig?
Dann wurde ja mit einem Release, in diesem Jahr, die Aufbewahrung der historischen Daten in HA geändert, sodass jetzt natürlich die Datenrate steigt, bis es sich ausgleicht, wenn die Aufbewahrungsfrist erreicht ist und neue Daten = der geprunten Daten entspricht.

VG
Bernd

Jim_OS · 21. Juni 2024 um 10:48

Moin Bernd

Jepp. In den letzten Jahren gab es dafür eigentlich nicht wirklich einen Grund, aber zumindest seit Ende Mai und auftauchen dieses Problems, habe ich schon mehrfach die DB manuell bereinigt incl. dem umpacken. Jetzt gerade habe ich das wieder gemacht und siehe da die DB ist um rund 800MB geschrumpft.
HA_DB_Neu

Ich vermute auch das das mit dem Update von 2024.4.x auf 2024.5.x zu tun hat, aber ich habe mir die alten Release-Note dazu noch nicht angeschaut, ob es bei dem Update Änderungen die DB betreffend gegeben hat. Werde ich aber noch nachholen und mal einen Blick auf die alten Release-Note werfen.

Was mich halt so irritiert hat, bzw. immer noch irritiert, ist dieser extreme Anstieg seit Mai. Wie gesagt: Bis Mai und seit ca. 3 Jahren, stieg die Größe der DB pro Tag um vielleicht 5 - 10MB. Seit Ende Mai hat sich das plötzlich fast verzehnfacht auf zuerst 100MB und nach meinen Änderungen jetzt auf rund 50 - 60MB pro Tag. Obwohl sich die Aufbewahrungszeit von 10 Tagen ja eigentlich nicht geändert hat.

Ich werde jetzt auch mal eine Automatisierung erstellen die die Datenbank regelmäßig bereinigt und dann mal schauen wie sich das entwickelt. Vielleicht sind die 50 - 60MB pro Tag bei meiner HA-Installation hier (die nicht wirklich so umfangreich ist), ja jetzt seit Core 2024.5.x auch “normal”.

VG Jim

dp20eic · 21. Juni 2024 um 12:36

Moin,

Ich beobachte ja nicht das einzelne Datenbank File, müsste ich auch mal machen, sondern nur den gesamten Plattenplatzverbrauch, daher kann ich auch nicht sagen, ob und wie sich das über die letzten 4 -5 Monate entwickelt hat.
Mir ist halt nur im Hinterkopf geblieben, dass sich bei den historischen Daten etwas geändert, erweitert wurde.
Zudem kann man die Systeme auch nicht 1:1 vergleichen, da andere Sensoren, Integrationen und Konfigurationen vorliegen.

Die andere Frage ist, hast Du einfach nur Interesse daran, herauszufinden warum es so ist, oder ein konkretes Problem?

Man könnte sich auch noch einmal auf die Suche machen, um zu schauen wie man sqliteMonitoren kann um zu sehen wer was in die Datenbank schreibt, bei SQlite bin ich aber nur ein Nutzer, habe damit noch nicht so viel angestellt.

VG
Bernd

Jim_OS · 21. Juni 2024 um 13:47

Ne die Frage die ich mir stelle ist ja gerade ob ich hier evtl. ein Problem habe, eben weil sich das Verhalten der DB seit Ende Mai so stark verändet hat. Ein konkretes Problem im Sinne von das oder jenes funktioniert jetzt nicht mehr (richtig) und/oder es gibt diese oder jene Fehlermeldungen und/oder ich kann dieses oder jenes jetzt nicht mehr machen, habe ich hier nicht.

Aber wenn sich eine Datenbankgröße - die in jetzt rund 3 Jahren Betrieb auf 600 MB angewachsen war - innerhalb von nur rund zwei oder drei Wochen mehr als verdreifacht auf vorhin über 2.000 MB und das ohne das ich groß irgendwelche Geräte hinzugefügt habe die Daten in die Datenbank schreiben, dann frage ich mich halt ob das jetzt - z.B. weil es in den letzten Wochen/Monaten irgendwelche Änderungen bei HA gegeben hat - “normal” ist, oder ob ich hier ggf. ein Problem habe.

BTW: Inzwischen habe ich die Release-Note zu Core 2024.5.x auch mal überflogen und da gab es keine Änderungen bzgl. der DB, dem Recorder oder der History., außer einer kleinen Änderung bzgl. dem purge,

https://github.com/home-assistant/core/pull/110066

was aber nicht die Datenerfassung in der DB betrifft.

Die Änderungen die Du meinst und an die ich mich auch noch erinnern kann, waren schon eher im Laufe dieses Jahres und Ende letzten Jahres war da glaube ich schon etwas.

Wie gesagt werde ich das Thema weiter im Auge behalten und mich ggf. noch tiefer mit der SQLIte Datenbank befassen. Wie schon erwähnt findet man im HA-Forum in den letzten Monaten div. ähnliche Beiträge, die natürlich zum Teil nichts zu bedeuten hatten, oder wo es einfach an dem gelegen hat was die User bei sich gemacht hatten. Aber es gibt auch ein paar Beiträge bei denen sich die User, ähnlich wie ich, dass Verhalten der DB nicht erklären konnten und bei denen dann tatsächlich ein löschen der home-assistant_v2.db und die anschließende Neuanlage, zum Erfolg geführt haben. D.h. im Anschluss hat sich die DB wieder so verhalten wie vorher und es kamen immer nur wenige MB pro Tag hinzu. Eine echte Erklärung für das Verhalten der home-assistant_v2.db und wodurch genau dieses Problem entsteht, hatte aber auch leider niemand. Es kam von anderen Usern immer nur: “Hatte ich auch schon. Wenn Du die home-assistant_v2.db löscht und neu erstellen lässt dürfte das Problem weg sein.” So oder so ähnlich halt.

Edit: Beispiel für eine dieser Diskussionen bzgl. home-assistant_v2.db löschen

VG Jim

dp20eic · 21. Juni 2024 um 14:24

Moin,

Du musst ja nicht gleich löschen, Du könntest ja auch erst einmal die Dateien verschieben, kopieren.
Wenn die auf einem anderen Rechner liegen, kann man da evtl. auch mit einem Tool darauf zugreifen und Daten exportieren und wieder importieren.

Ich habe mir gerade die drei Files auf meinen Rechner gezogen und kann darauf mit DBeaver zugreifen, somit gehen Deine Daten ja nicht flöten

VG
Bernd

Jim_OS · 21. Juni 2024 um 14:40

Ne das ich die DB, bzw. die drei dazugehörenden Dateien, erst sichere ist schon klar. Aber falls die aktuelle home-assistant_v2.db eine - wie auch immer geartete - “Macke” haben sollte - warum auch immer - komme ich um das löschen letztendlich nicht herum.

Ich wollte schon immer mal eine Neuanfang mit HA machen und mich der alten Werte aus den letzten Jahren entledigen. Ne nicht wirklich.

VG Jim

Jim_OS · 22. Juni 2024 um 14:57

Ein kleines Update dazu: Mein Datenbank hat hier wirklich ein gewissen “Eigenleben” das ich so nicht wirklich nachvollziehen kann. Nach dem bereinigen und umpacken von gestern Mittag (12.40 Uhr) und der Reduktion auf 1.244MB, ist die DB jetzt innerhalb von 24 Std. wieder um rund 183 MB auf 1.427 MB angewachen
HA_DB_Größe_Neu

und das obwohl in den Tagen davon der tägliche Zuwachs ja immer nur bei 50-60 MB lag.

Ich frage mich so langsam wirklich was da los ist. Warum wächst die DB jetzt innerhalb von 24 Std. plötzlich wieder um 183 MB, wenn die Tage davon immer nur 50-60 MB pro Tag in die Datenbank geschrieben wurde. An HA selber und den Sensoren wurde ja nichts verändert und in den letzten 24 Std. sind von diesen ja auch nicht mehr Daten und Änderungen erfasst worden als in den Tagen davor über einen Zeitraum von jeweils 24 Std.

Alles irgendwie etwas komisch und mir fehlt dafür bisher eine Erklärung. Mal sehen wie es jetzt in den nächsten Tagen weitergeht.

VG Jim

detlefh68 · 23. Juli 2024 um 11:02

Hallo,

ich benötige auch etwas Hilfe beim Anwachsen der Datenbank.
Meine DB hat damit genau am 9.7. begonnen und ich habe keine Erklärung was der Auslöser
diese Anstiegs sein soll.
Ich habe am 8,7. das 2024.7.1 Update installiert. kann das der Grund dafür sein?

Über einen Tip würde ich mich sehr freuen.
Wie z.B. kann ich die Datenbank aufräumen ohne die Langzeitdaten der Messsensoren zu löschen?

Viele Grüße
detlefh68

Jim_OS · 23. Juli 2024 um 12:34

Nur eine Info von mir: Ich hatte bisher noch keine Zeit und auch nicht wirklich Lust, mich um das Thema weiter zu kümmern. Auf jeden Fall macht meine DB immer noch Dinge die ich nicht wirklich nachvollziehen kann. Hier mal ein aktueller Screenshot.

Ich hatte ja am 21.06. manuell per recorder.purge die Datenbank bereinigt und umpacken lassen, sodass sie dann “nur” noch ~ 1.250 MB groß was. Dann ist die DB innerhalb von 4 Tagen wieder sprunghaft auf über 2.000 MB angewachsen, um dann vom 26.06. bis zum 14.07. so gut wie gar nicht mehr anzuwachen. Sprich der Zuwachs über diese 18 Tagen war dann so wie ich das von früher gewöhnt war, sprich in Summe nur lediglich um die 50 MB.

Was dann genau am 14.07. die scheinbare Bereinigung ausgelöst hat weiß ich auch nicht, denn ich habe am dem Tag keine Bereinigung durchgeführt und der Eintrag in der configuration.yaml

recorder:
  purge_keep_days: 10

mit den 10 Tagen passt auch irgendwie nicht dazu.

Ab dem 14.07. nimmt der Zuwachs dann wieder sprunghaft zu, sodass die DB Größe aktuell 2.112 MB beträgt. Somit ist die DB innerhalb von 8 Tagen um ca. 300 MB angewachsen. Während des gesamten bei dem Screenshot sichtbaren Zeitraumes habe ich an HA keine Änderungen durchgeführt, sprich keinerlei Updates installiert und ich bin auch immer noch bei Core 2024.6.4.

Was auch immer HA mit der DB da aktuell bei mir macht, aber normal ist das wohl nicht. Zumindest war das jahrelang anders.

Da bei mir demnächst eh ein HA Host-Umzug ansteht werde ich mich in absehbarer Zeit wohl wieder mit dem Thema befassen (müssen) und vielleicht nutze ich den Host Umzug auch dafür bei der DB einen sauberen Neuanfang zu starten, sprich diese zu löschen und dann automatisch neu erstellen zu lassen. Mir pers. sind die historischen Werte jetzt nicht so wichtig und wenn ich ansonsten keinen Lösungsansatz für dieses m.M.n. eher komische DB-Problem finden sollte, bleibt mir wohl eh nichts anderes übrig.

VG Jim

detlefh68 · 23. Juli 2024 um 13:39

Hallo,

mir fällt auf, dass ich Tabellen „states_temp_xy“ in der Datenbank habe, kann man diese entfernen?

VG Detlef

Jim_OS · 23. Juli 2024 um 15:53

Ich kann Dir nur sagen das ich diese Einträge bei mir nicht habe, aber nicht ob diese ggf. normal und manchmal vorhanden sind und schon gar nicht ob man diese problemlos/gefahrlos entfernen kann.

Du kannst Dir ja mal diesen Beitrag im HA-Forum zu Gemüte führen, falls Du das nicht eh schon gemacht hast:

Darin konnte ich zwar keine Erklärung finden warum sich meine DB scheinbar so komisch verhält, aber vielleicht findet Du darin ja Infos die Dir ggf. helfen, bzw. Dir ggf. etwas bringen.

VG Jim

detlefh68 · 23. Juli 2024 um 16:55

Vielen Dank für die Antwort!

Das Verhalten der Datenbank ist schon merkwürdig. Ich werde (habe schon angefangen) den
Beitrag zu Gemüte zu ziehen.

Ich habe auch in Erinnerung, dass es mit einem Update ein Problem mit dem Recorder gab und ab ca. 4h nachts die Aufzeichnung stoppte.

VG Detlef

Seppokalypse · 16. Oktober 2024 um 15:04

Mal ne Frage,
könnte man nicht die Datenmenge reduzieren, indem man stumpf alle Aktualisierungen aller Entitäten reduziert, z.B. von alle 2-5 Sek. auf alle 10 Sek.? Somit müsste man doch den 2-3 fachen Speicherplatz sparen, oder? Gibt es ein Addon, welches ALLE Entitätsaktualisierungen verlangsamt?
VG,
Seppo

Jim_OS · 16. Oktober 2024 um 15:16

Theoretisch schon, allerdings lassen sich Abrufintervalle nicht bei allen Geräten individuell einstellen.

VG Jim

dp20eic · 16. Oktober 2024 um 15:37

Moin,

herzlich willkommen im Forum.

das kann man, aber nicht mit einem Hammer, denn nicht alles ist ein Nagel

Es wäre besser zu verstehen wie HA die Daten abspeichert und dann muss man sich fragen was habe ich da eingestellt, dass die Datenbank aus allen Nähten platzt.

Ganz einfach ausgedrückt, wenn Du alles auf dem Standard belässt, werden in HA alle Daten für 10 Tage in den Historie-Tabellen (Kurzzeitdatentabellen) gehalten, alles, was dann nicht bestimmten Kriterien entspricht, wird gelöscht, alles, was diesen Kriterien entspricht, wird in den Langzeittabellen gespeichert.
Der Vorteil, in den Kurzzeittabellen ist eine viel höhere Auflösung der Daten, in den Langzeittabellen dagegen aggregierte Daten, daher nehmen die nicht mehr so viel Platz weg.
Möchtest Du jetzt Daten in den Kurzzeittabellen länger als die 10 Tage halten, kannst Du Dir in der configuration.yaml den Rekorder einrichten und den z. B. auf 30 Tage stellen, dann werden alle Daten in der maximalen Auflösung für 30 Tage gehalten und danach gelöscht, b.z.w. in die Langzeittabellen geschrieben.
Wenn Dich aber nur wenige Daten in höhere Auflösung für 30 Tage interessieren, dann muss man den Rekorder auch so einstellen, dass nur das für > 10 Tage in den Kurzzeittabellen landet, was man haben möchte.

Also, wenn man alles korrekt einrichtet, dann braucht man keine Krücke, um etwas zu verlangsamen oder an der ursprünglichen Programmierung zu manipulieren, zumal für gewisse Entitäten, möchtest Du ja vielleicht auch, dass sie jede Sekunde melden?

Hier mal die Dokumentation:

Und weil es @Jim_OS gerade erwähnt, nicht alles ist Pull, manches kommt auch von den Geräten per Push, dann müsste man nach Deiner Methode zig Einzelgeräte anfassen und umstellen, vorausgesetzt es ginge.

VG
Bernd

Jim_OS · 16. Oktober 2024 um 16:10

Da das Ursprungsposting ja von mir stammt sollte ich dazu auch noch ein Update posten: Das Verhalten bei meiner DB ist inzwischen anders und die Infos dazu sind in diesem Beitrag zu finden.

D.h. statt das die Größe der DB kontinuierlich weiter ansteigt stagniert sie jetzt irgendwann und das dann über einen Zeitraum x (siehe den anderen Beitrag). Ich für meinen Teil habe b.a.W. aufgegeben mir dieses Verhalten zu erklären und/oder noch weiter danach zu suchen. Somit ist für mich das Thema b.a.W. abgeschlossen. Ich werde diesen Beitrag hier allerdings auch nicht als gelöst markieren, weil es hier ja auch nicht wirklich eine Lösung gibt bzw. gab.

VG Jim

Creep · 16. Oktober 2024 um 17:31

Ich habe das gleiche Problem. Meine DB ist mittlerweile schon auf 11 GB gestiegen innerhalb eines Jahres. Bisher habe ich noch kein Platzproblem, aber wollte mich dem Thema jetzt auch mal annehmen.

Wirklich wichtig wären mir nur die Daten aus dem Energy Dashboard. Alles andere würde ich gerne mal löschen.

Bleiben die Daten im Energie Dashboard erhalten wenn ich die normale DB lösche bzw irgendwie zurück setze?

dp20eic · 16. Oktober 2024 um 18:55

Moin,

wenn ich das wörtlich nehme, dann bleibt von HA nichts übrig!
Also niemals die Datenbank löschen!

Zudem gibt es keine normale Datenbank, aber mal von vorne.

Wie und wo ist bei Dir HA installiert?
Welche Datenbank nutzt Du
- SQLite, ist Standard, wird so bei der Installation von HA mitinstalliert
- MariDB
- …
wenn andere Datenbank als SQLite,
- intern als Add-on
- extern
Hast Du irgendwelche Anpassungen gemacht, z. B.
- Recorder Einträge in der configuration.yaml
- machst Du Auto Prune, oder irgendein Prune
- wie ist denn Deine Aufbewahrungszeit der Historiendaten (Kurzzeitdaten)

Also erst mal Butter bei die Fische, dann schauen wir mal.

VG
Bernd

Creep · 16. Oktober 2024 um 19:16

Moin Bernd,
HA ist als OS auf einem NUC installiert.
Datenbank ist (wieder) SQlite. War einige Zeit auf mariadb, hab aber wieder aufwändig zurück gewechselt.
Anpassungen habe ich derart gemacht, indem ich vor einigen Wochen in der recorder.yaml einigen Entitäten “included” habe. Alle anderen sollten ja dann eigentlich nicht geloggt werden. Hat aber das Wachstum leider nicht wirklich aufgehalten.

Kurzeitdaten werden 10 Tage gespeichert.

Ja, ich habe viele Entitäten (1954). Das sollte aber ja nicht dazu führen das das Backup mittlerweile 11,2 GB groß ist.

Vielen Dank für die Hilfe.

Viele Grüße
Mark