Le disk est saturé!

Entraide Home Assistant
1

Mon problème

Je rencontre un problème depuis quelques jours : le disque se remplit à vue d’oeil (10 Go tous les 8h, ça peut être plus rapide). Je dois redémarrer HA pour retrouver un peu de souffle (environ 10 Go retrouvés après reboot).
Je n’arrive pas à comprendre d’où ça vient. Je suis à jour de la dernière version.
Côté logs, je ne prends que les notifications critical.
Les datas (qui sont certes volumineuses puisque je garde 1 an d’historique) représentent 45 Go, sont stockées sur MariaDB (dans un contenaire Docker sur HA).

Je suis donc preneur si vous avez des idées parce que je sèche !
Merci

Ma configuration

System Information

version core-2023.3.2
installation_type Home Assistant OS
dev false
hassio true
docker true
user root
virtualenv false
python_version 3.10.10
os_name Linux
os_version 5.15.90
arch x86_64
timezone Europe/Paris
config_dir /config
Home Assistant Community Store
GitHub API ok
GitHub Content ok
GitHub Web ok
GitHub API Calls Remaining 4996
Installed Version 1.31.0
Stage running
Available Repositories 1242
Downloaded Repositories 27
Home Assistant Cloud
logged_in false
can_reach_cert_server ok
can_reach_cloud_auth ok
can_reach_cloud ok
Home Assistant Supervisor
host_os Home Assistant OS 9.5
update_channel stable
supervisor_version supervisor-2023.03.1
agent_version 1.4.1
docker_version 20.10.22
disk_total 117.4 GB
disk_used 117.4 GB
healthy true
supported true
board ova
supervisor_api ok
version_api ok
installed_addons Samba share (10.0.0), deCONZ (6.18.0), File editor (5.5.0), MariaDB (2.5.2), Mosquitto broker (6.1.3), NGINX Home Assistant SSL proxy (3.2.0), RPC Shutdown (2.2), AdGuard Home (4.8.2), Node-RED (14.0.4), SSH & Web Terminal (13.0.3), Z-Wave JS UI (1.7.1), Let’s Encrypt (4.12.8), Grafana (8.2.0), InfluxDB (4.5.0), phpMyAdmin (0.8.3), Home Assistant Google Drive Backup (0.110.1), ESPHome (2023.2.4), Glances (0.17.2)
Dashboards
dashboards 3
resources 16
views 24
mode storage
Recorder
oldest_recorder_run 12 mars 2022 à 13:13
current_recorder_run 9 mars 2023 à 10:58
estimated_db_size 44778.22 MiB
database_engine mysql
database_version 10.6.10
___
2

Hello

un bonjour en debut de message est toujours sympa :wink:

Ta base de donnés doit tout enregistré , si tu as des sondes de température il se peux que celle-ci envoi des infos toutes les 1 minutes par exemples, et donc sa gonfle ta base …

donc un script qui purge ta BD, et affine tes reglages avec recorder.

Divers topic parle de tout cela sur le forum.

3

bonjour, désolé, j’étais pris dans mon truc :wink:

Je comprends ton point de vue mais qu’est ce qui explique qu’après un reboot je retrouve 10 Go ?
Si tenté que ça soit une sonde un peu bavarde qui me cause ces pb, les enregistrements ne seraient pas supprimées au reboot.
Et puis surtout, mon install tourne depuis des mois sans que cela ne se soit rempli à cette vitesse…

Pour info, voici le début du fichier de config !

# Configure a default setup of Home Assistant (frontend, api, etc)
default_config:

logger:
  default: critical
  # logs:
    # custom_components.ipx800v4: debug
  
# DB MariaDB
recorder:
  db_url: !secret mariadb_url
  purge_keep_days: 180
  #auto_purge: true
  #auto_repack: true
  include:
    domains:
      - binary_sensor
      - climate
      - group
      - light
      - person
      - plant
      - sensor
      - switch
      - zone
      - input_number
      
  exclude:
    domains:
      - automation
      - camera
      - counter
      - cover
      - device_tracker
      - group
      - input_boolean
      - input_datetime
      - media_player
      - persistent_notification
      - remote
      - scene
      - script_started
      - sun
      - updater
      - weather
      - zwave
    event_types:
      - automation_triggered
      - browser_mod
      - call_service
      - component_loaded
      - feedreader
      - homeassistant_start
      - homeassistant_stop
      - platform_discovered
      - script_started
      - service_executed
      - service_registered
      - service_removed
      - timer_out_of_sync
    entity_globs:
      - sensor.nut_*
      - sensor.prise_usb_tablette_*
      - sensor.teleinfo_uptime_*
      - sensor.teleinfo_wifi_*
    entities:
      - sensor.teleinfo_hardware
4

Bjr
Ressemble plus à un pb de log qui grossit ( j’ai eu ce pb le pb le mois dernier a cause d’une clé USB mal installer sous proxmox. T’as rien installé ces derniets jours ?
Regarde la taille de tes logs " system"

5

où puis je trouver cette info ? C’est le fichier home-assistant.log qui est dans /config ?

6

dddddd
dddddd841×758 62.6 KB

7

je viens de redémarrer le serveur, j’ai regagné les 10 Go. Je viens de reperdre 100 Mo et le fichier home-assistant.log fait 3 Ko (puisque je n’ai demandé que les notif CRITICAL).
Donc a priori, c’est pas ça…

8

re,

a force de recherche j’ai retrouvé ceci qui ma etais fort utile.
@Guizmos , avais posté un lien pour voir ce qui bouffe la DB.

https://sqlitebrowser.org/blog/version-3-12-2-released/

regarde la au besoin

1 « J'aime »
9

@bennijamm n’a pas un souci de DB, vu qu’il a de façon délibéré choisi de garder 1 an dans le recorder et que c’est dans une db MariaDB…

C’est surement plus lié à un journal qui part en vrille, pas le .log mais ceux qui sont dans /var/log/journal de l’hôte.

Je vois que tu as SSH & Web Terminal installé, essayer d’ouvrir un terminal et de taper:

du -h /var/log/journal

Chz moi ça fait 1,6Go:

image

10

Je suis sur un base MariaDB donc c’est un peu différent mais sur le principe, avec d’autres outils, voici les résultats :
Etat de la BDD
image

Et le top 20 records :
image

Je pense que je vais lancer un grand nettoyage dans un premier temps même si je doute que ça soit ça le problème, sauf si au delà d’une certaine taille, HA le gère mal ?

11

Voici ce que ça donne :
image

12

Et je ne peux pas les supprimer :

image
image1618×957 327 KB

13

Pour info, depuis le début de ce fil de discussion, j’ai pris 2 Go dans la vue :wink: !
Les fichiers home-assistant.log et les fichiers de journaux n’ont pas bougé…

14

Quelque chose déconne… c’est peut-être un des add-ons…
HA de base ne génère pas autant de choses sur le disque…

Just au hasard, c’est surement pas ça mais: Tu te ferais pas attaquer par un DDOS sur ton NGINX?

Essayes de stopper chacun de tes add-ons, à commencer par les non essentiels et après chaque arrêt, regardes si ton disque grossit encore aussi vite… puis passes au suivant…
Je commencerais pas InfluxDB, Grafana, Nginx, AdGuard, Glances…

C’est normal du n’y à pas accès, le répertoire est monté en lecture seule dans le container.

15

ok, bonne idée, ça ne n’ai pas fait.
Je vais tout désactiver sous l’essentiel et voir si ça a un effet et si c’est le cas, je remettrais en fonction petit à petit.

16

Les logs de journalctl ne se supprime pas comme ça et se configuré pour limiter sa taille.

Mais pour moi, ton souci est ailleurs,car ça écrit read-only systeme.

Donc reboot et lance un fsck sur ta partition, …

17

Hello,

Le read only est normal… L’accès se fait par l’addon SSH, donc pas root sur le FS du core, c’est juste un montage de volumes entre les 2 containers.

Concernant la base, on peut débattre sur l’utilité de garde autant d’historique (180j => 6 mois et pas un an) quand il y a les valeurs du dashboard energy pour faire ça un peu plus finement mais il y a quand même de l’optimisation à faire : Autant on peut vouloir garder les valeurs ‹ energie › et pê les valeurs de luminance (dans le cas de PV ?!? ) mais les count pour le wifi et le MQTT et ça me semble moins utile.

Il faut vérifier le journal complet des logs HA (et pas se focaliser sur un loglevel : un truc en mode debug, ça crache un peu de données)

18

C’est clair qu’en plus de la partie énergie et en ayant InfluxDB aussi, avoir 180 ou 365 jours à part les ennuis et les temps de chargements rallongés ça n’apporte pas grand chose :confused:

Il l’a dit, il est en loglevel critical.
Je ne vois pas ce qui dans HA peut encore cracher autant de données… c’est pour ça que je disais de voir les add-ons, comme il y en a aussi une floppée d’installé.

19

Oui mais on peux avoir un loglevel minimal dans configuration.yaml, tout en ayant activé séparément les addons et les intégrations, y compris en dynamique depuis l’interface.
C’est quand même là qu’on voit les limites de HAOS, c’est pénible pour chercher comme dans une VM plus classique

1 « J'aime »
20

En l’occurence je ne sais pas trop comment on pourrait voir ça dans un autre contexte, quelle que soit l’installation.
Si le souci vient d’une intégration core ou custom, tout ce qu’on peut voir c’est le processus de HA qui consomme des ressources… mais pas plus d’infos sur ce qui se passe.

J’ai eu ça avec une intégration HACS qui déconnais, j’ai mis de temps à trouver d’où ça venait…