Requête SQL et affichage bloqués lors du nettoyage de la Timeline

Bonjour,

Jeedom V4.3.17 Sur Rpi4 avec Rasbian 10.13

Lors de l’accès à la timeline, un clean automatique est effectué, mais lorsque l’on y va très peu, le nettoyage n’est pas fait et au prochain accès la quantité de ligne à traiter est trop importante pour la requête de déduplication qui reste alors bloqué et empêche l’affichage de la timeline.

La requête en question se trouve ici :

Sur la table timeline j’ai 60100 lignes et ça fait 2 heure 7 minutes et 26 secondes (7649 sec) que la requête tourne.

Voici mon SHOW FULL PROCESSLIST; sur cette requête

+--------+-------------+-----------+--------+---------+------+--------------------------+-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+----------+
| Id     | User        | Host      | db     | Command | Time | State                    | Info                                                                                                                 | Progress |
+--------+-------------+-----------+--------+---------+------+--------------------------+-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+----------+
| 378486 | jeedom      | localhost | jeedom | Query   | 7649 | Sending data             | DELETE t1 FROM timeline t1 INNER JOIN timeline t2 WHERE t1.id < t2.id AND t1.type = t2.type AND t1.subtype = t2.subtype AND t1.datetime = t2.datetime AND t1.options = t2.options AND t1.folder = t2.folder AND t1.link_id = t2.link_id |    0.000 |

Note : 2h après cette commande, la requête est terminé et la timeline n’a plus que 530 lignes. Je ne sais pas exactement combien de temps elle a pris, mais bien plus de 2h !

Le problème se situe au niveau du INNER JOIN qui va créer 60100^2 lignes, soit 3 612 010 000 lignes avant d’appliquer la clause WHERE.
Il me semble que cela arrive lorsque l’on ne consulte pas souvent la Timeline car c’est uniquement la visualisation qui lance le nettoyage. Il ne semble pas y avoir de nettoyage automatique externe.
Plus il y aura de ligne et plus ça durera longtemps en rendant le Timeline inutilisable.

Corrections à étudier :

  • Optimisation du code/de la requête de déduplication pour éviter de faire un INNER JOIN
  • Mise en place d’un Cron journalier pour pro-activement nettoyer la timeline et ne pas attendre la visite de l’écran de Timeline pour le faire.

Les sujets suivants semblent liés car le problème d’allocation mémoire pourrait venir de cette requête qui consomme beaucoup de mémoire :

2 « J'aime »

Bonjour,
Merci pour ton retour, ce soucis a été corrigé il y a quelques mois en 4.4.

1 « J'aime »

Super !

En effet, je viens de voir que le clean avait été ajouté au cron Daily sur la branche alpha.

Merci pour votre retour.

1 « J'aime »

Ce sujet a été automatiquement fermé après 24 heures suivant le dernier commentaire. Aucune réponse n’est permise dorénavant.