@euguuu a testé et ça marche !
Le bonus c’est qu’à chaque fois que tu retire des features de l’historique, Gladys fait tourner un petit VACUUM donc ça fait du nettoyage aussi 
1 « J'aime »
Woaw merci pour le lien, j’étais passé à côté. Je suis impatient de tester ça !!
1 « J'aime »
@pierre-gilles, j’ai essayé hier soir d’installer Gladys sur mon PC fixe, d’utiliser ma DB actuelle pour ensuite supprimer des features.
Mon PC fixe utilise un SSD NVME donc ça doit être super rapide, bien plus que mon RPi qui prend 10h pour traiter les 8Go de ma DB et supprimer les features…
MAIS, comme le service Zigbee2MQTT doit être utilisé et qu’il n’est pas lancé dans l’instance de dev que j’ai installé sur mon PC, impossible d’accéder aux périphériques pour supprimer les features.
→ As tu une astuce pour me permettre de réaliser la suppression des features sur mon PC fixe et ensuite réutiliser cette version de DB modifiée sur mon RPi ?
Salut @lmilcent !
A part taper directement dans la DB, j’ai pas d’astuce particulière 
Ca prend vraiment trop de temps sur ton Pi ?
Tu peux utiliser un programme comme TablePlus sur ton PC pour avoir une interface d’accès propre à ta DB.
Pense bien à stopper Gladys avant de récupérer/remettre ta nouvelle DB
En effet, je m’étais rendu compte que ça corromp la base sinon.
Oui je te confirme, ça tourne depuis plus de 12h, pour la suppression d’une seule feature. Mais je sais que c’est lié à deux choses : une DB de 8Go et un RPi avec une carte SD et pas un SSD.
Si tu as ça sous la main, tu peux me rappeler comment :
- Lister les features par devices
- Supprimer les données d’une feature (et je désactiverais ensuite leur stockage dans l’interface)
Sinon j’irais chercher dans le code source 
Merci
C’est ici:
Ensuite pour supprimer les états d’une feature:
DELETE FROM t_device_feature_state WHERE device_feature_id = 'cca32009-8d8f-4965-b658-bdb28eb31300';
DELETE FROM t_device_feature_state_aggregate WHERE device_feature_id = 'cca32009-8d8f-4965-b658-bdb28eb31300';
Ne pas oublier à la fin:
VACUUM;
2 « J'aime »
Merci, je savais bien que tu avais déjà fait le taf pour moi au moins une fois😂
Désolé pour la demande en doublon, et merci encore !!
1 « J'aime »
Résultats en image : une taille réduite de 50% 
Désormais ma DB fait 3.8Go contre plus de 8Go !
Niveau sauvegardes (perso) ça se ressent :
4 « J'aime »
C’est super, j’ai aussi réduit de 1.6Go ma base et que ça fait du bien les dashbord qui charge immédiatement ! 
3 « J'aime »
ça fait plaisir à lire tout ça
2 « J'aime »
On pourrait aussi cleaner la table location, on a tout l’historique de localisation mais ça sert à rien on est d’accord ?
Dans Gladys 3 on avait une fonctionnalité, on pouvait voir l’historique de ces déplacements, je trouvais ça pratique
Cette table est vraiment grosse chez toi ?
Je l’avais clean il y’a quelques semaines, je l’ai fait ce matin ( env 60000 lignes )
Je ne vois pas de use case sur l’historique de localisation.
Ok, 60k lignes c’est rien on pourra mettre à terme une tâche pour vider l’historique (un peu comme on fait avec les states: derniers 6 mois, dernière année, etc…)
Super la base de donnée a été réduite aussi chez moi et cela se ressent sur l’affichage des graphiques.
Par contre maintenant j’ai un problème à chaque modification d’un device, par exemple son nom, cela me bloque Gladys pendant plusieurs minutes. (facile 10 à 15 min)
Est-ce normal?
Je pourrais donner plus de détails et faire des tests mais en soirée si besoin.
Du coup j’ai fait un essai pour ajouter une fonctionnalité à un device MQTT.
J’ai du attendre environ 22 min pour que la page s’affiche après la sauvegarde
Je te confirme j’ai le même bug.
En modifiant mes device MQTT a chaque fois c’est très long jusqu’à indiqué qu’une erreur s’est produite.
Je suis obligé de redémarrer l’instance Gladys pour que ça refonctionne mais la modification est prise en compte
J’ai rencontré le même problème lorsque j’ai enlevé l’historique des devices.
Je n’avais pas eu le temps de faire remonter l’information.
Idem chez moi.
@pierre-gilles je ne sais pas si c’est le cas, mais on dirait réellement que soit la base de données soit Gladys est en mode bloquant à ce moment là.
Car vraiment plus rien ne répond. Donc soit j’ai totalement tord (ce serait pas la première fois ), soit il y a quelque chose à faire pour optimiser un peu cette partie.
De mon côté, je vois un processus node index.js à 100% du CPU, quand l’écriture sur la carte SD de mon Raspberry Pi ne semble pas à 100% de I/O.
Salut à tous !
En fait lorsque vous enregistrez un appareil, Gladys va faire 2 choses:
- Si certaines features sont en historique désactivés, Gladys va purger tous les états de ces features. Cela représente potentiellement des millions de lignes sur certaines DB, ce qui peut bloquer la DB pendant pas mal de temps lors de la suppression.
- Après ça, Gladys lance un VACUUM, opération qui va « réellement » supprimer la data du disque, et libérer de l’espace. VACUUM est une opération bloquante, et pendant toute la durée du VACUUM, la DB, et donc Gladys, n’est pas accessible. Sur les petites DB, c’est invisible, sur les grosses DB, ça peut prendre 20 minutes et effectivement on a l’impression que c’est « cassé », alors que non ça travaille juste !
La solution que je vois :
- Coder une tâche de suppression d’états « background » qui supprime en petit batch afin que Gladys ne soit pas bloquée lors de la suppression de features à millions d’états. Il faut faire des tests et trouver le bon chiffre pour que ce soit ni trop bloquant, ni trop lent.
- Retirer le VACUUM immédiat et mettre en place une tâche de VACUUM nocturne programmée et activable/désactivable (toutes les semaines par exemple).
La contrepartie de tout ça, c’est que l’effet « libération de stockage » ne sera plus immédiat, suite à une purge d’états il faudra attendre la prochaine nuit ou attendre une semaine que Gladys se purge. Eventuellement, on peut mettre un bouton quelque part pour purger manuellement mais il faut que l’utilisateur soit conscient que Gladys sera indisponible pendant tout le temps de la purge.
Par contre j’ai une assez grosse semaine donc je pense pas pouvoir regarder dans les jours qui viennent, je regarderais soit en fin de semaine, soit dans le courant de la semaine prochaine ! Je vous tiens au courant
3 « J'aime »