Le disk est saturé!

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

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"

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

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…

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 »

@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

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 ?

Voici ce que ça donne :
image

Et je ne peux pas les supprimer :

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é…

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.

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.

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, …

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)

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é.

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 »

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…

Disons qu’un accès aux volumes docker depuis l’hôte ça permet un autre regard, c’est pas la solution miracle mais ça permet de pointer l’endroit et de remonter un peu la pile

Oui, il y a de l’optimisation à faire dans ce que je conserve, c’est certain…
Garder 12 mois a du sens pour moi pour faire des comparatifs sur des périodes comparables (en termes de température, de conso, de rendement solaire… bref, c’est tout l’objet d’une BDD en fait !).
Je ne sais pas si ça existe mais mon idéal serait d’avoir des données à la minute pour l’analyse immédiate puis qu’ensuite un script vienne supprimer les données détaillées pour ne garder qu’un détail à l’heure par exemple (pour diminuer le nb d’enregistrement en base). ça vous parle ?

Pour vous tenir informés, j’ai arrêté tous les les add-ons sauf Node-Red et MariaDB : la croissance du volume s’est poursuivi.
J’ai ensuite arrêté Node Red et MariaDB + coupé la redirection de port wan to lan (au cas où si DDOS…) : le volume est redescendu et a arrêté de croitre.
Je vais commencer à réactiver les modules un par un.

Si c’est le module MariaDB, si je le supprime et que je le remets, quel impact ? perte de tout l’historique « seulement » ?

Merci pour votre aide