Disque plein / aide nettoyage base de donnée

Ah oui je comprends. Et il n’existe pas la possibilité de la faire régulièrement pour éviter de devoir supprimer énormément de données à la fois ?

Dans mon cas, j’ai 68Gb de disque, 22Gb de base de données et 22Gb de libre. Sauf que le VACUUM ne se termine jamais, faute de place sur le disque.

Je me retrouve avec un fichier .db-wal de presque 10Go en plus des 22 Go de la db. Je ne sais plus trop quoi faire.
Lancer la tache manuellement ne fonctionne pas, j’ai une erreur « database locked ». Même en indiquant un chemin TMPDIR différent et qui dispose de 800Go de libre.

J’ai bougé ce sujet dans un nouveau topic :slight_smile:

Non car le VACUUM est lent sur les grosses bases/disque lent, même si il a été exécuté récemment.

Dans ton cas, ce que je ferais:

  • Stopper Gladys
  • Copier ta DB sur ton PC par exemple ou sur un disque plus puissant/avec plus d’espaces
  • Utiliser un outil comme TablePlus pour exécuter une commande SQLite sur ta DB
  • Exécuter « VACUUM; »
  • Une fois que c’est fini, recopier la DB sur ton serveur Gladys
  • Relancer Gladys

:slight_smile:

J’ai hésité à faire un sujet dédié, merci !

Dans mon cas j’ai dû faire un wal_checkpoint(TRUNCATE); pour que ca vide le fichier .db-wal devenu aussi gros que la DB.
Et ensuite le VACUUM.

Gladys fait un checkpoint régulier d’habitude ?

[EDIT]
Quand Gladys lance une tâche de « Nettoyage » (donc un Vacuum), le fichier .db-wal grossi de plus en plus, jusqu’à atteindre la même taille que la db.
Je me retrouve donc avec deux énormes fichiers (tâche en cours ici) :
Capture d'écran 2024-03-27 162440

Ce que j’ai fait, c’est que j’ai changé la DB de place, pour une partition avec plus de place.

Mais je n’explique pas ce qui suit :thinking:

Retention pas supprimée ?

Ma DB fait 22Go, avec une rétention illimité de tous mes équipements. Pour diminuer la taille, j’ai mis en place une rétention à 6 mois des états et illimités pour les valeurs agrégées.

Malgré tout, même avec un VACUUM après toutes les tâches de purge de Gladys, je suis à 17Go. En cherchant, j’ai trouvé une requête pour lister le nom de valeurs par tables, et je ne comprend pas pourquoi il y a si peu de différence entre les valeurs agrégées et les valeurs brutes.

Vacuum pas fonctionnel ?

Une fois que la tâche de vacuum est terminée, je me retrouve avec deux énormes fichiers, qui ne sont pas supprimés.

La tâche est terminée pourtant :

Capture d'écran 2024-03-27 163129

C’est uniquement si je force Gladys à s’arrêter ou redémarrer que le fichier .db-wal est supprimé. Mais j’ai toujours 17Go d’utilisés.

Capture d'écran 2024-03-27 163222

Si tu as 3 mois de rétention des états et 6 mois des états agrégés, cela veut dire que tu auras :

  • 1 ligne pour chaque état de chaque fonctionnalité de chaque appareil pour les 3 derniers mois
  • 1 ligne pour chaque minute (affichage heure), 1 ligne pour chaque 5 minutes (affichage jour), 1 ligne pour chaque jour (affichages semaine, mois, 3 mois, année) pour les 6 derniers mois pour chaque fonctionnalité de chaque appareil

Donc les états agrégés font quand même beaucoup de lignes :sweat:

Cette commande te permet de connaître les devices/features qui enregistrent le plus d’états.

SELECT COUNT(*) as total, tdf.id, tdf.name, td.name 
FROM t_device_feature_state tdfs 
JOIN t_device_feature tdf ON tdf.id = tdfs.device_feature_id 
JOIN t_device td ON td.id = tdf.device_id 
GROUP BY device_feature_id ORDER BY total DESC;

PS: tu t’attendais à plus de réduction en ne gardant que 6 mois ?

1 Like

Merci pour ton message et la requête.

Voici ce que ça donne :

GROUP BY device_feature_id ORDER BY total DESC;
4081384|8ede0b40-31b8-42a1-b6d8-fdfceaea35e1|Formaldehyd (Décimale)|capteurQualitéDeLair
2426183|631724ce-6fca-48c8-8588-5598f5a736ee|COV (Décimale)|capteurQualitéDeLair
2425895|b1289ec3-87f7-4dfc-bc95-80a9fa2bd840|Niveau de CO2|capteurQualitéDeLair
2000636|b0eb1e68-2b18-4c9d-b20b-0547a0641698|Intensité du signal|PriseBureau
941126|30d10a22-d247-49b9-873e-9aec623f886f|Puissance consommée|PriseBureau
785583|2c8ced8b-e581-497d-b247-e6cb884d45da|Intensité consommée|PriseBureau
611299|c1a94fd6-3413-46ef-86df-33214fb74328|Puissance consommée|PriseOnduleur
544435|4d88bc30-dbf3-4165-919d-fba0c54b728e|Intensité du signal|PriseVideoproj
512281|6f91c791-fd31-43ad-89d6-91418fffdaf1|Puissance consommée|PriseFrigoTS0121
313060|6b907ebe-c011-4dd1-af54-339b51add63f|Intensité du signal|InterrupteurSalon
302039|d9d990a1-6b0a-4d58-bc19-9a7c591ecf71|Intensité du signal|CapteurFumeeEntree
278423|3cf063a8-8ced-4134-954f-e1b81f930a16|Détection mouvement Oui/Non|CapteurMouvementEntree

En regardant de plus près, j’ai bien des état qui date de plus des 3 mois prévus. La tâche « Faire du ménage » n’est pas censé supprimer tout ça ?

Capture d'écran 2024-03-27 164633

sqlite> SELECT * FROM t_device_feature_state WHERE device_feature_id = "8ede0b40-31b8-42a1-b6d8-fdfceaea35e1" ORDER BY created_at ASC LIMIT 10;
id|device_feature_id|value|created_at|updated_at
afee0e90-6084-4571-bfec-1acd4b7d4a8e|8ede0b40-31b8-42a1-b6d8-fdfceaea35e1|3.0|2023-08-31 01:23:29.486 +00:00|2023-08-31 01:23:29.486 +00:00
4b836770-b2da-47a0-bc5f-abd2c24f65ee|8ede0b40-31b8-42a1-b6d8-fdfceaea35e1|3.0|2023-08-31 01:23:33.090 +00:00|2023-08-31 01:23:33.090 +00:00
c1b9ec79-663a-4730-8de6-1f226d39c336|8ede0b40-31b8-42a1-b6d8-fdfceaea35e1|3.0|2023-08-31 01:23:36.497 +00:00|2023-08-31 01:23:36.497 +00:00
a7697c08-c7b5-4282-8a54-b98071e56deb|8ede0b40-31b8-42a1-b6d8-fdfceaea35e1|3.0|2023-08-31 01:23:40.002 +00:00|2023-08-31 01:23:40.002 +00:00
927c202e-fae5-4c8a-9e97-efe9db7a01d5|8ede0b40-31b8-42a1-b6d8-fdfceaea35e1|3.0|2023-08-31 01:23:43.512 +00:00|2023-08-31 01:23:43.512 +00:00
423cdb73-33a6-4dac-a0e2-a397184f7277|8ede0b40-31b8-42a1-b6d8-fdfceaea35e1|3.0|2023-08-31 01:23:47.010 +00:00|2023-08-31 01:23:47.010 +00:00
c7114d81-8740-4c42-bcde-790ec4ecbe02|8ede0b40-31b8-42a1-b6d8-fdfceaea35e1|3.0|2023-08-31 01:23:50.638 +00:00|2023-08-31 01:23:50.638 +00:00
59a722ee-71c2-44a9-ae8b-a9912d79a3b3|8ede0b40-31b8-42a1-b6d8-fdfceaea35e1|3.0|2023-08-31 01:23:54.175 +00:00|2023-08-31 01:23:54.175 +00:00
91435e9b-3c4f-4866-9940-4d360949d099|8ede0b40-31b8-42a1-b6d8-fdfceaea35e1|3.0|2023-08-31 01:23:57.655 +00:00|2023-08-31 01:23:57.655 +00:00
9a2f224f-16dc-4752-84bf-735823ec9303|8ede0b40-31b8-42a1-b6d8-fdfceaea35e1|3.0|2023-08-31 01:24:01.066 +00:00|2023-08-31 01:24:01.066 +00:00

Au final, en le faisant à la main, j’ai déjà probablement économisé 3.3Go si j’en crois le fichier .db-wal qui à grossi.

sqlite> DELETE FROM t_device_feature_state WHERE device_feature_id = "8ede0b40-31b8-42a1-b6d8-fdfceaea35e1" AND created_at < "2023-12-31 00:00:00.000";
1 Like

J’ai 3 mois de rétention et mes derniers états sont bien du 28 Décembre.
J’ai 6 mois de rétention agrégée et mes derniers états agrégés sont bien du 27 Septembre.

Et ta tâche Nettoyage des vieux états d'appareils est bien en Succès :thinking:

Encore une fois, ma db n’a pas maigrie malgré l’evolution du fichier wal

Il faudrait qu’on regarde ça Write-Ahead Logging
Ça me paraît bizarre un fichier wal de plusieurs Go.
Tu ouex toujours redémarrer le docker gladys pour fermer la connexion, prendre en compte les changements et nettoyer le fichier wal.

J’ai eu un souci de partition pleine il y a quelques mois et là solution a été pour moi de… supprimer le db-wal qui était plus gros que la DB…
Radical mais je n’ai vu aucun problème par la suite…
Édit : je vois qu’en fait ton db-wal est bien supprimé donc, je suis HS. Désolé…

Salut @lmilcent :slight_smile:

Je pense qu’il y a un malentendu sur la façon dont le nettoyage fonctionne dans Gladys.

Vous parlez de deux choses différentes :

  • Nettoyage de la base de donnée : Ce bouton n’est qu’un raccourci vers la requête SQLite VACUUM. La commande VACUUM reconstruit le fichier de base de donnée afin de libérer la place occupée par des tuples supprimés. Pour en savoir plus, la documentation de SQLite est très claire : VACUUM
  • Nettoyage des vieux états d’appareils : Cette tâche s’exécute tous les jours à 4h du matin, et purge tous les états de capteurs inférieur à la durée de rétention choisie. (Cf code: Gladys/server/config/scheduler-jobs.js at master · GladysAssistant/Gladys · GitHub )

Si tu changes la durée de rétention dans l’UI, le nettoyage des anciens états aura lieu au prochain 4h du matin (afin de ne pas trop déranger ta prod en journée).

Cela pourrait être affiché dans l’interface je me dis…

Du coup, si tu fais un VACUUM alors que les états sont encore là, ça ne clean rien c’est normal :slight_smile:

Il faut attendre 4h du matin, puis faire le VACUUM

1 Like

Arf, j’ai suspecté que c’était ça, mais j’étais trop pressé je pense ^^
Voyons ce matin ce que ça donne alors ! Merci d’avoir pris le temps de répondre :slight_smile:

Je remonte ce sujet car je rencontre un problème d’espace disque faible.

Or je ne meurs pas d’envie de bidouiller ma BDD, ni d’utiliser mon terminal car j’aurai peur de tout péter (et accessoirement parce que c’est toujours très chronophage!)

Est-ce que l’un d’entre vous peut me donner une marche à suivre plus simple ? S’il en existe une ?

Là ça devient critique ^^

Salut @guim31 :slight_smile:

Tu peux aller dans « Systèmes », et éditer ce paramètre :

Met quelque chose de plus petit que ce que tu as actuellement.

Ensuite, à 4h du matin, Gladys viendra nettoyer les anciens états plus vieux que la durée choisie.

En revanche, vu que tu es arrivé à un stade assez « grave » (plus de disque du tout…), c’est possible que ça échoue, et là pas le choix tu vas devoir trouver de l’espace à la main, c’est même plus au niveau Gladys le souci, c’est au niveau système linux ^^

1 Like

J’ai fini par faire le bourrin : redimensionner mes partitions !! :grin: Passé de 60Go à 200Go pour avoir de la marge

1 Like