Augmentation taille du Swap et gestion taille BD

Le recorder c’est fait pour les données « volatiles » de HA pour la domotique.

Si des choses doivent être gardées, c’est soit avec des entitiés qui enregistrent des statistiques long terme.
Soit avec une autre base de données. (Influx ou autre SQL server)

Tu veux garder quoi comme données?

Du coup tu garde juste 2 entities ?

La temp ext, temp salon, a voir pour d’autre mais a réfléchir effectivement sur l’intéré

:rofl: jolie performance !

Venant de Jeedom je n’avais pas ce problème.
Je sélectionnais individuellement ce que je voulait enregistrer ou non

1 « J'aime »

Non pas du tout! J’en garde beaucoup, beaucoup plus!
Les 2 en include

  include:
    entities:
      - sensor.alarm_status
      - sensor.processor_temperature

c’est pour une exception aux exclude:

    entity_globs:
      - sensor.processor_*
      - sensor.*_status

Certains de ces sensor s’enregistrent toutes les 1 sec!!
En temps normal, quand le système est stable, stocker la charge de processeur, on s’en fout un peux, je garde juste la valeur actuelle et l’historique… bah osef

Ce qui a beaucoup changé chez moi c’est cet exclude:

    domains:
      - device_tracker

C’était de loin le plus gros consommateur de db!

OK je commence à comprendre la logique mais c’est pas simple.
Pour regarder la base tu utilise mariaDB ?

Regarde le lien partagé par @Pulpy-Luke ça explique comment le faire dans la db sqlite standard.
MariaDB c’est un autre serveur SQL, ce n’est pas un outil pour lire ton fichier .db.

En revanche pour revenir à ton souci clairement ton auto_purge ne marche pas.
Enlève le de la configuration déjà pour commencer, car c’est par défaut à true, tu n’en a pas besoin.

La config du recorder n’est pas si compliquée.
Sur la doc ils expliquent très précisément et simplement la logique des include/exlude dans la section « Configure Fillter »

OK merci pour toute les infos !
Je vais lire tout ca tranquillement.

J’étais dans le même cas que toi à un moment; très exactement les même soucis. Et c’était invivable, j’avais aussi créé des automatisations pour rebooter, vider la db et tout…
Passer sur un RPi4 peut aider, mais ça serait le même problème très rapidement.
Comme je disais, à l’époque, je suis passé de 400Mo dans la DB avec 1,2millions d’entrées (events+states) à une base de 37Mo avec 200.000 entrées (events+states) et là tu respire vraiment :slight_smile:

Sinon autre config que tu peux essayer, ça peut aider à réduire la pression sur le système et ton SSD, si tu as beaucoup de choses qui s’enregistrent. Par défaut c’est 1sec… 20sec de lag dans l’enregistrement dans la DB ce n’est pas très grave…

commit_interval: 20
1 « J'aime »

Comment tu as fait exactement pour passer de 400 mo à 37mo ?

Depuis j’ai considérablement augmenté le contenu et les intégrations, donc je suis à 160mo en moyenne là.

Exactement comme j’ai dit:

  • Analyser le contenu de la base par event_id et entity_id.
  • Appliquer le filtre en conséquence.

Et ça a donné le filtre que j’ai partagé. Mais ils faut voir chaque installation est différente, peut-être que tu as certains de tes sensors qui bombardent plus que d’autres

Aussi réduction à 7 jours comme tu as fait et augmentation du commit interval, je ne sais pas si ça a une influence sur la taille de la db, mais en termes de processing et I/O ça aide.

Merci pour ton aide !!
Pour la purge manuel il faut coché « Apply filter » ?

Je n’ai jamais utilisé la purge manuelle.
Mais je pense que oui faut cocher le filtre.

En revanche ça risque d’être un gros boulot pour ton RPI3.
J’y irais par étape à ta place. Fait juste avec days to keep d’abord.
Repack risque de prendre beaucoup de ressources.

Refais un 2eme passage avec repack après, si ça marche le premier.

En principe, purger ça va rien donner de plus, le filtre et le 7 jours s’appliquent déjà…
Le seul truc qui peut agir, c’est le repack : taille du fichier, mais pas directement lié au contenu

Ouais mais vu son graph de la taille de la db on dirait que ça ne purge pas en auto, ça devrait se voir toutes les nuits à 4h12… donc s’il commence par une purge avec les nouveaux paramêtres en premier, puis un repack ça pourra aider.

auto_purge boolean (optional, default: true)
Automatically purge the database every night at 04:12 local time. Purging keeps the database from growing >indefinitely, which takes up disk space and can make Home Assistant slow. If you disable auto_purge it is >recommended that you create an automation to call the recorder.purge periodically.

Possible. Sur le graphique on voit la croissance sur une journée donc purge qui marche ou pas il y quand même un truc sur ce qu’on y insére.
Et si la base est trop grosse, c’est effectivement pas impossible que la purge automatique n’aboutisse pas au déclenchement journalier.
De toute façon, le premier indice c’est avec le premier comptage

@Pulpy Le graph c’était sur 7 jours!! :slight_smile:

1 « J'aime »

OK je commande une paire d’yeux en urgence sur Amazon

Je déplace le sujet dans ‹ entre aide ›