Nach einem VACUUM über Nacht sollte man über die am wenigsten belastende Lösung nachdenken, denn zum Beispiel verwaltet Gladys und NodeRed meine elektrische Heizung und meinen Pellet-Ofen. Das bedeutet, dass mein Heizsystem jede Nacht zwischen 2 und 4 Uhr für 20 Minuten blockiert wäre?
In diesem Fall würde ich lieber einen manuellen Modus für das VACUUM haben.
Ein weiteres Beispiel: Wenn du Gladys eine Alarmanlage hinzufügst, hätten Einbrecher jede Nacht 20 Minuten freie Bahn.
Kann man sich nicht vorstellen, die Gesamtheit in mehrere Teile zu splitten, die dann auf die gleiche Weise gelöscht werden?
Das ist auch eine der Lösungen, die @pierre-gilles vorschlägt
Ach danke.
Ich habe zu schnell gelesen. 
@pierre-gilles Das sollte beim Hinzufügen eines Features nicht passieren. Ich habe gerade getestet und wie die anderen dauert es eine Weile (4 Minuten auf amd64).
Ich habe 14 GB RAM für den Container, ich muss die Nutzung etwas begrenzen.
Wie ist das möglich, so viel RAM für Gladys? Was machst du damit?
Sinon machen wir die DB-Reinigung nur, wenn wir ein Feature aus der Historie löschen
Nichts Besonderes
Zur Information arbeite ich heute an diesem Thema. Ich bin heute Morgen gut vorangekommen und habe einen Pull Request erstellt 
Mein Ansatz:
Wenn ein Gerät registriert wird, bei dem mehrere Funktionen das Kontrollkästchen „Ja, Zustände beibehalten“ deaktiviert haben, starte ich Hintergrundjobs, die die vergangenen Zustände auf eine etwas intelligentere Weise bereinigen als bisher.
Der Job zählt in der Datenbank, wie viele Zustände bzw. aggregierte Zustände es für jede Funktion gibt, und bereinigt dann in kleinen Batches von 1000 Zuständen, um die Datenbank nicht zu überlasten. Zwischen jedem Batch wartet Gladys 100 ms, um Gladys etwas Luft zu verschaffen.
Um 5 Millionen Zustände zu bereinigen, sind also 5 Millionen / 1000 = 5.000 Batches erforderlich.
5.000 * 0,1 = 500 Sekunden = 8,3 Minuten Wartezeit zwischen den Batches. Wenn man 100 ms pro Bereinigung hinzufügt, dauert es 16 Minuten, um 5 Millionen Zustände im Hintergrund auf nicht blockierende Weise und sanft zu bereinigen.
Auf Gladys-Seite können alle Hintergrundjobs in der Registerkarte „Hintergrundaufgaben“ in Echtzeit verfolgt werden:
Dadurch können diese Aufgaben nachverfolgt und ihre Ausführung überwacht werden.
Normalerweise sollte die Registrierung eines Geräts nun sofort erfolgen, und Gladys sollte nicht mehr blockieren!
Ich werde meine Tests an größeren Datenbanken fortsetzen und sehen, wie ich mit dem VACUUM umgehe 
Der Pull Request:
Genial, ich kann es kaum erwarten, es zu testen.
Ich vermute, du bist in einer anderen Zeitzone oder schläfst nachts nicht?
Ja, ich bin in Bangkok +5 Stunden Zeitverschiebung zu Frankreich!
Was das VACUUM betrifft, habe ich mich für einen „manuellen“ Ansatz entschieden, zumindest vorerst, angesichts der Auswirkungen auf die Verfügbarkeit von Gladys bei großen Datenbanken.
Ich habe das VACUUM beim Registrieren der Geräte entfernt und eine manuelle Schaltfläche in den Systemeinstellungen hinzugefügt, mit einem Text, der klar darauf hinweist, dass Gladys während einer bestimmten Zeit nach dem VACUUM nicht verfügbar sein wird.
Die Idee ist, zunächst zu sehen, wie lange das VACUUM auf verschiedenen Instanzen dauert, und dem Benutzer die Wahl zu lassen, es durchzuführen oder nicht.
Anschließend können wir möglicherweise einen monatlichen Nachtjob hinzufügen, aber wir müssen dies gut kommunizieren und ihn deaktivierbar machen für diejenigen, die maximale Verfügbarkeit von Gladys wünschen.
Der Button:
Der PR:
