Après faire un VACUUM la nuit, il faut réfléchir sur le moins pénalisant car, par exemple, je gère mon chauffage électrique et poêle a granulé avec Gladys et NodeRed, donc du coup toutes les nuits entre 2h et 4h mon chauffage serait bloqué dans sa position pendant 20 min?
Dans ce cas de figure j’aimerais plutôt avoir un mode manuel du VACUUM.
Autre exemple si tu ajoutes une fonction Alarme à Gladys, les cambrioleurs auront 20 min tranquille toutes les nuits.
On ne peut pas imaginer de splitter l’ensemble en plusieurs morceaux qui seront ensuite delete de la même façon ?
1 « J'aime »
C’est une des solutions que proposes aussi @pierre-gilles
Ah merci.
J’ai lu trop vite alors. 
@pierre-gilles ça ne devrait pas faire ça sur l’ajout d’une feature. Je viens de faire le test et comme les autres ça prend du temps ( 4 minutes sur de l’amd64 )
Je suis à 14GB de ram pour le conteneur, va falloir que je limite un peu l’utilisation
1 « J'aime »
Comment c’est possible autant de RAM pour Gladys ? Tu fais quoi avec ?
Sinon faire le nettoyage de la DB uniquement si on supprime une feature de l’historique
Rien de particulier
1 « J'aime »
Pour information je travaille sur ce sujet aujourd’hui, j’ai bien avancé ce matin et j’ai créé une PR 
Mon approche:
Désormais, lorsqu’on enregistre un device où plusieurs fonctionnalités ont a la case « Oui, conserver les états » décochée, je lance des jobs en background qui vont aller nettoyer les états passés, de manière un peu plus smart que ce qui était fait juste que là.
Le job va compter en DB combien il y a d’états / états aggrégés pour chaque feature, puis va nettoyer en petit batch de 1000 les états, afin d’éviter de surcharger la DB. Entre chaque batch, Gladys attend 100ms pour laisser de l’air à Gladys.
Pour cleaner 5 millions d’états, il faut donc 5 millions / 1000 = 5 000 batch.
5 000 * 0.1 = 500 secondes = 8,3 minutes à minima d’attentes entre les batch, si on rajoute 100ms par clean, ça fait 16 minutes pour cleaner 5 millions d’états en arrière plan, de façon non bloquante pour Gladys et en douceur
Côté Gladys, tout job en arrière plan peut-être suivi en direct dans l’onglet « Tâches en arrière plan »:
Ce qui permet de garder une trace de ces tâches, et de suivre leur exécution.
Normalement, l’enregistrement d’un appareil devrait être instantanée, et Gladys ne devrait plus bloquer !
Je vais continuer mes tests sur des plus grosses DB, et voir comment je gère le VACUUM 
La PR:
5 « J'aime »
Génial j’ai hâte de tester.
J’imagine que tu es dans une autre timezone ou que tu dors pas la nuit ?
1 « J'aime »
Yes, je suis à Bangkok +5h de décalage par rapport à la France !
1 « J'aime »
Concernant le VACUUM, j’ai choisi une approche « manuelle » pour l’instant, vu l’impact que ça a sur la disponibilité de Gladys sur les grosses DB.
J’ai retiré le VACUUM lors de l’enregistrement des devices, et j’ai rajouté un bouton manuel dans les paramètres systèmes avec un texte qui indique clairement que Gladys sera indisponible pendant un certain temps suite au VACUUM.
L’idée c’est déjà de voir le temps que le VACUUM prend sur différentes instances, et laisser le choix à l’utilisateur de le faire/ou non.
Ensuite, on pourra éventuellement rajouter un job de nuit mensuel par exemple, mais il faudra bien communiquer dessus et le rendre désactivable pour ceux qui veulent une disponibilité de Gladys maximale.
Le bouton:
La PR:
2 « J'aime »
