Normalerweise hast du auch ohne Löschung Zugriff auf die Diagramme, aber ich denke, dass Gladys hier mit der Löschung beschäftigt war und dein System dadurch etwas blockiert war
Wenn du keine Zustände mehr in SQLite hast, denke ich, dass du die Datenbank bereinigen und Gladys neu starten kannst 
Also, um sehr präzise zu sein, bis vor etwa 2 Stunden (also denke ich, bis er die Daten dieser Sensoren gelöscht hat, hatte ich die Anzeige auf den Kurven, aber ohne neue Daten, da die Kurven bei gestern 10:xx aufgehört haben, also der Zeit, als ich auf das neue Image umgestiegen bin.
Ich bin mir also ziemlich sicher, dass ich bis zum Löschen auf den Daten der SQLite-DB geblieben bin. Die neuen Daten wurden tatsächlich in DuckDB geschrieben, da die Anzahl der Zustände zunahm.
Oki, dann mache ich mich mal ran ^^
Nein, das ist unmöglich, der SQLite-Code wurde entfernt, er ist nicht in der duckDB-Image enthalten. Du hattest vielleicht einen Cache-Anzeige, aber das kam nicht von deiner Datenbank.
Ergebnisse der Migration für meine Installation (80 Millionen Zustände):
SQLite-Datenbank vor der Bereinigung: 47,7 GB
DuckDB-Datenbank nach der Migration: 410 MB
SQLite-Datenbank nach der Bereinigung: 13,7 GB
Gewinn: 47,7 - (13,7 + 0,41) = 33,6 GB (70% ^^) 
Vielen Dank an @pierre-gilles für diesen schnellen Übergang!!
Probleme: Meine Kurven sind momentan unterbrochen (Cache vielleicht?)
Letzte 24 Stunden:
Als ob die Zustandsrückmeldungen verpasst wurden (obwohl sich DuckDB im Systemzähler korrekt inkrementiert hat)
Außerdem gibt es etwas, das mir vorher nicht wie ein Problem vorkam: Ich habe einen Wert „Mustergeschwindigkeit“, der den letzten empfangenen Wert aus dem MQTT-Netzwerk (von einem beliebigen Topic) übernimmt
Aber das könnte auch nicht zusammenhängen. Ich weiß nur, dass es vor meinem Urlaub funktioniert hat ^^
Mich wundert, dass es so groß ist… Hast du wirklich 0 Zustände in SQLite? Hast du Gladys nach der DB-Reinigung neu gestartet?
Normalerweise sollte die DB wieder sehr klein sein (maximal ein paar MB).
Führe einen weiteren Löschvorgang durch, sonst ^^ Vielleicht sind noch Daten in der Tabelle aggregate
In deinem Fall, angesichts der Größe deiner DB und der Langsamkeit des Löschvorgangs, hat Gladys möglicherweise einige Zustände verpasst, weil das System mit der Reinigung beschäftigt war.. Leider ist das verloren, du wirst Lücken in diesen Zeiträumen haben.
Ich würde mich wundern, wenn das zusammenhängt, aber wenn du mehr Infos hast, zögere nicht
Auch wenn ich das schon super finde (^^), ja, es wundert mich auch ^^ wie ich dir vorhin gesagt habe, ja, ich habe wirklich 0 Zustände in SQLite im Systemtab. Aber die Löschaufgabe war noch im Gange:
Ich warte, bis sie abgeschlossen ist, um neu zu starten. Ich werde danach erneut einen Löschvorgang und eine Bereinigung durchführen.
Die Datenbankbereinigung schien mir auch im Vergleich zum letzten Mal, als ich sie durchgeführt habe, sehr schnell, sodass die Datenbank viel leichter war.
Ich werde auch den Browser-Cache leeren.
Ich werde danach einen neuen Bericht machen.
Wenn es nur das ist, ist das nicht schlimm ^^ Ich hatte nur Angst, dass alle Histos gelöscht werden ^^
Warte wirklich, bis die Bereinigung abgeschlossen ist, und führe dann dein Vacuum durch. Bei mir musste ich den gesamten Vorgang (nach einem Neustart von Gladys) wiederholen, damit alle Aufgaben vollständig erledigt wurden…
Ok ok … ich bin sprachlos … ^^ Ich wiederhole, für 80 Millionen Zustände:
SQLite-DB vor der Reinigung: 47,7 GB
DuckDB-DB nach der Migration: 410 MB
SQLite-DB nach der Reinigung: 1,1 GB => 27 MB nach der Reinigung der Tabelle t_message
Gewinn: 47,7 - (1,1 + 0,41) = 46,2 GB, also - 97% ^^
Also, ich muss mich korrigieren, es ist so schnell, die DB jetzt wiederherzustellen, dass ich nachgesehen habe, was mir 1 GB in SQLite einnimmt, und es stellt sich heraus, dass ich 3 Millionen Zeilen in der Tabelle t_message hatte, die den Text ‹ Test Licht Auto an/aus › enthielt.
Ich habe alles gelöscht (man sollte vielleicht daran denken, eine Option zum Reinigen dieses Teils hinzuzufügen, denn in meinem Fall muss es eine Szene gewesen sein, die ich falsch gemacht habe …):
Gewinn: 47,7 - (0,03 + 0,41) = 47,26 GB, also - 99% ^^
DB-Backup vor der Migration: 12,28 GB
DB-Backup nach der Migration: 694 MB => 408 MB nach der Reinigung der Tabelle t_message
Gewinn: 12,28 - 0,694 = 11,586 GB, also - 94% ^^
Gewinn: 12,28 - 0,408 = 11,872 GB, also - 97% ^^
Gut gemacht @pierre-gilles 
Speicherproblem gelöst!
Und wie du sagtest, Anzeige der Kurven ist sofort möglich, sei es in 24h, in 1h oder in einer Mischung von Zeiträumen. Jetzt bleibt nur noch, sich auf die PRs zu stürzen, die gerade für die erweiterten Visualisierungen der Kurven laufen. Beeindruckend!
Übrigens, auf 11 Dashboard-Seiten, von denen 4 Seiten 4 bis 8 Kurven mit mehreren Funktionen wie unten enthalten, sind die Anzeigen fast sofort (das war vorher weit entfernt davon):
EDIT (falls das anderen, die einen langsamen Chat haben, Ideen gibt ^^) : Und seit dem Löschen der Zeilen in der Tabelle t_message ist die Chat-Anzeige wieder sofort (das habe ich seit Jahren nicht mehr erlebt 
)
=>
Super, danke für den Erfahrungsbericht! Es ist wirklich unglaublich, der Unterschied 
Für den Chat sollten wir täglich eine Löschung der Nachrichten durchführen, um nur die 1000 neuesten zu behalten (ich weiß nicht, ob es sinnvoll ist, mehr zu behalten, wir machen das ja schon bei den Hintergrundaufträgen).
