Normalement même si la purge n’est pas faite tu as accès aux graphiques, après je pense là que Gladys était occupée avec la purge et donc que ça bloquait un peu ton système
Si tu n’as plus d’états dans SQLite, je pense que tu peux faire un nettoyage de la DB + redémarrer Gladys 
Alors pour être très précis, jusqu’à il y a 2h environ (donc je pense jusqu’à ce qu’il efface les données de ces capteurs, j’avais la visu sur les courbes mais sans nouvelles données puisque les courbes s’arrêtaient à hier 10hxx, soit l’heure ou je suis passé à la nouvelle image.
Je suis donc à peu près sûr que je restait sur les données de la DB SQLite jusqu’à l’effacement. Les nouvelles données étaient bien écris dans DuckDB puisque le nombre d’état augmentait.
Oki, je me lance alors ^^
Non c’est impossible, le code SQLite a été supprimé, il n’est pas dans l’image duckDB. Tu avais peut-être du cache à l’affichage, mais ça ne venait pas de ta base.
Résultat des courses pour mon installation (80 millions d’états) :
DB SQLite avant nettoyage : 47,7 Go
DB DuckDB après migration : 410 Mo
DB SQLite après nettoyage : 13,7 Go
Gain : 47,7 - (13,7 + 0,41) = 33,6 Go (70% ^^) 
Merci @pierre-gilles pour ce passage rapide !!
Côté soucis : Mes courbes sont cassées pour le moment (cache maybe ?)
Dernière 24h :
Comme si il avait loupé les retours d’états (alors que DuckDB s’incrémentait bien dans le compteur système)
Egalement quelque chose qu’il ne me semble pas ne posait de problème avant, j’ai une valeur « Vitesse pattern » qui prend la dernière valeur reçu sur le réseau mqtt (de n’importe quel topic)
Mais cela n’est peut-être pas lié. Je sais seulement que c’était fonctionnel avant de partir en vacance ^^
ça m’étonne que ça soit si lourd… Tu as bien 0 états dans SQLite ? Tu as redémarré Gladys après le nettoyage de la DB ?
Normalement tu devrais retomber à une DB toute petite (quelques Mo max).
Relance un coup de purge sinon ^^ Peut-être qu’il reste de la data dans la table aggregate
Dans ton cas, vu la taille de ta DB et la lenteur de la purge, peut-être que Gladys a loupé des états vu que le système était « occupé » à nettoyer… Malheureusement c’est perdu, tu auras un trou sur ces périodes.
ça m’étonnerait que ce soit lié, mais si tu as plus d’infos n’hésite pas
Meme si je trouve ca dejà super (^^) oui ca m’étonne aussi ^^ comme je te le disais tout a l’heure, oui je suis bien à 0 états dans SQLite sur l’onglet systeme, mais la tâche de purge était encore en cours :
J’attends qu’elle soit terminée pour redémarrer. Je ferais à nouveau une purge et un nettoyage après ça.
Le nettoyage de la base m’a semblé très rapide également par rapport à la dernière fois que je l’avais fait alors la DB etait beaucoup plus légère.
J’en profiterais pour vider le cache du navigateur également.
Je fais un nouveau retour ensuite.
Si ce n’est que ça ce n’est pas grave ^^ j’ai surtout eu peur que la totalité des histos soient supprimés ^^
Attends vraiment que la purge soit finie puis fais ton vacuum. Chez moi, j’ai dû recommencer toute la procédure (après un redémarrage de Gladys) pour que les tâches soient menées à bien en totalité…
Ok ok … je suis stupéfait … ^^ Je reprend, pour 80 millions d’états :
DB SQLite avant nettoyage : 47,7 Go
DB DuckDB après migration : 410 Mo
DB SQLite après nettoyage : 1,1 Go => 27 Mo après nettoyage de la table t_message
Gain : 47,7 - (1,1 + 0,41) = 46,2 Go soit - 97% ^^
Alors autant pour moi, il est tellement rapide de récupérer la DB maintenant que j’ai été voir ce qui me prenait 1 Go dans SQLite, et il s’avère que j’avais 3 millions de ligne dans la table t_message contenant le texte ‹ Test lumière auto on/off ›.
J’ai donc tout supprimé (il faudra peut-être penser à avoir une option pour nettoyer cette partie d’ailleurs car pour mon cas ce doit être une scène que j’avais mal faite …) :
Gain : 47,7 - (0,03 + 0,41) = 47,26 Go soit - 99% ^^
Backup DB avant migration: 12,28 Go
Backup DB après migration : 694 Mo => 408 Mo après nettoyage de la table t_message
Gain : 12,28 - 0,694 = 11,586 Go soit - 94% ^^
Gain : 12,28 - 0,408 = 11,872 Go soit - 97% ^^
Bien joué @pierre-gilles 
Problème de stockage résolu !
Et comme tu le disais, affichage des courbes instantané que ce soit en 24h, en 1h ou en mix de périodes. Y a plus qu’à s’éclater sur les PR qui sont en cours pour les visualisations plus larges des courbes maintenant ^^!! Impressionnant !
Au passage sur 11 pages de dashboard, dont 4 pages contiennent des 4 à 8 courbes avec de multiples fonctionnalités comme ci-dessous, les affichages sont quasi instantanés (c’était loin d’être le cas avant) :
EDIT (si ça peut donner des idées à d’autres qui ont un chat ralenti ^^) : Et depuis la suppression des lignes de la table t_message, l’affichage du chat est redevenu instantané (pas connu ça depuis des années 
)
=>
Trop bien merci pour le retour d’expérience ! Effectivement c’est incroyable la différence 
Pour le chat, il faudrait faire une purge quotidienne des messages pour ne garder que les 1000 plus récents (je sais pas si ça sert de garder plus, on fait déjà ça pour les job background)
