[recorder MariaDB] ERROR (MainThread) [homeassistant.components.recorder.core] The recorder backlog queue reached the maximum size

[FillR2]

Bonjour à tous,

Depuis une semaine, mon recorder (sous MariaDB) s’arrête vers 2 heures du matin (pendant ma grosse sauvegarde journalière qui démarre à 01h00).

Je suis sur un Raspberry PI4 4GO SSD au tout au dernier niveau et j’utilise MariaDB comme recorder avec ces paramètres:

recorder:
  db_url: mysql://homeassistant:homeassistant@core-mariadb/homeassistant?charset=utf8mb4
  auto_purge: true
  purge_keep_days: 14
  commit_interval: 60
  exclude:
    domains:
      - uptime
      - time_date
      - device_tracker
      - localtuya
      - camera
    entity_globs:
      - sensor.clock*
      - sensor.date*
      - sensor.time*
      - sensor.uptime*
      - sensor.ty*
      - switch.ty*
      - sensor.*_estimated_distance
    entities:
      - sensor.home_assistant_v2_db

Le message d’erreur est le suivant:

ERROR (MainThread) [homeassistant.components.recorder.core] The recorder backlog queue reached the maximum size of 40000 events; usually, the system is CPU bound, I/O bound, or the database is corrupt due to a disk problem; The recorder will stop recording events to avoid running out of memory

Ce que je comprends, c’est que mon système de suit pas au niveau des entrées/sorties, de fait:

• Y-a-t-il moyen de suivre les IO sur PI4 ?

• D’une façon générale, je trouve que les I/O sont très mauvaises sur HA PI4 SSD, alors que le hardware semble efficace, par exemple, lors je télécharge une sauvegarde via HA, c’est 10 fois plus lent que lorsque je copie le fichier directement via Samba. il n’y a pas de paramêtres d’optimisation quelque part ?

• Y-a-t-il moyen de savoir comment réduire le volume de de données du recorder, ce qui génère le plus d’I/O , du SQL sur MariaDB via phpAdmin ?

• Autres idées ?

Merci pour votre aide.

[WarC0zes]

Ton RPI4 chauffe trop et le CPU aime pas trop, j’ai vu qu’il tourner entre 60-70°C. La température arrive pas vers les 80 quand ca fait ton backup ?

[FillR2]

Bonne question, mais non (courbe du haut):

Je pense vraiment à un problème d’I/O, mais je ne trouve aucun sensor sur le sujet, pourtant c’est fondamental !

[FillR2]

1/ Je suis allé faire un tour dans ma base MariaDB qui stocke le recorder avec 14 jours d’historique, notamment la table states

2/ Je suis ensuite allé voir les entités qui ramenaient le plus d’enregistrements pour vérifier qu’ils étaient utiles:

SELECT entity_id, count(*) nb_enrgt FROM states where last_updated > STR_TO_DATE('2023-01-10 04:00:00', '%Y-%m-%d %H:%i:%s')
group BY entity_id having nb_enrgt > 10000 order by nb_enrgt desc ;

3/ Je désactive ce qui n’est pas nécessaire:

recorder:
  db_url: mysql://homeassistant:homeassistant@core-mariadb/homeassistant?charset=utf8mb4
  auto_purge: true
  purge_keep_days: 14
  commit_interval: 60
  exclude:
    domains:
      - uptime
      - time_date
      - device_tracker
      - localtuya
      - camera
      - call_service
      - automation_triggered
      - auto_backup
    entity_globs:
      - device_tracker.*
      - sensor.ubnt*
      - sensor.clock*
      - sensor.date*
      - sensor.time*
      - sensor.uptime*
      - sensor.ty*
      - switch.ty*
      - sensor.*_estimated_distance
      - automation.*
    entities:
      - sensor.home_assistant_v2_db
      - sensor.auto_backup
      - automation.camera_snapshots_garage_15_secondes
      - automation.trigger_heartbeat_garage_beat
      - sensor.cosphi_mn
      - sensor.cosphi_h
      - sensor.fire_tablet_ram_free_memory

4/ Je vérifie que mon nombre d’enregistrements par jour est en baisse:

SELECT date(last_updated) date, count(*) Nb_Enrgt FROM states where last_updated > STR_TO_DATE('2023-01-10 04:00:44', '%Y-%m-%d %H:%i:%s')
group BY date desc order by date desc;

Et que les enregistrements supprimés ne sont plus enregistrés à partir d’une certaine date:

SELECT entity_id, date(last_updated) date, count(*) nb_enrgt FROM states where last_updated > STR_TO_DATE('2023-01-27 04:00:00', '%Y-%m-%d %H:%i:%s')
group BY entity_id, date having nb_enrgt > 10000 order by entity_id, date;

A suivre donc…

[FillR2]

Il semble qu’avec la version 2.5.2 de MariaDB, il y ait des modifications dans la base, le champ last_updated n’est plus systématiquement renseigné, mais il existe un champ last_updated_ts (timestamp).

Les requêtes peuvent être modifiées en remplaçant

last_updated

par

from_unixtime(last_updated_ts)

Et comme indiquée, les performances lors de la consultation de l’historique ont été grandement améliorées !