supprimer les enregistrements de la table mdl_logstore_standard_log dont l'action est "updated" ?

supprimer les enregistrements de la table mdl_logstore_standard_log dont l'action est "updated" ?

par Jean-Gabriel DEPINOY,
Nombre de réponses : 28
Avatar Moodleurs particulièrement utiles

Bonjour à tous,

J'ai un Moodle 4.1 qui tourne avec PHP 8.0.

Depuis quelques temps je remarque que ma table mdl_logstore_standard_log explose (plusieurs millions d'enregistrements) et pose des problèmes quand il faut cloner mon site ou réimporter une sauvegarde du site. Pourtant j'ai limité les enregistrements à un historique d'un an et nous n'avons que 300 étudiants qui l'utilisent.

En fouillant un peu dans ma table (71 078 149 enregistrements), j'ai constaté que la plupart (70 780 688) des enregistrements concernait l'action "updated" qui ont pour champ target "user". Je voulais savoir si quelqu'un savait à quoi correspondait cette valeur et si je pouvais supprimer ces enregistrements.

J'ai une deuxième table qui prend de la place (mdl_lanalytics_log) avec plus de 10 millions d'enregistrements. Mais  il y a moins de champs et je ne vois pas trop comment élaguer cette table. Peut-être les enregistrements dont le champ courseid=0 ?

Merci de vous idées.

Moyenne des évaluations  -
En réponse à Jean-Gabriel DEPINOY

Re: supprimer les enregistrements de la table mdl_logstore_standard_log dont l'action est "updated" ?

par Olivier Valentin,
Avatar Développeurs de plugins Avatar Moodleurs particulièrement utiles
Bonjour Jean-Gabriel,

pour la première question : les logs avec l'action "updated" et avec la cible "user", c'est généralement la mise à jour du profil. A moins que l'information ne soit stratégique, il y a peut-être bien moyen de faire du tri !
Pour la deuxième table, ça concerne la brique Learning Analytics de Moodle. Est-ce bien une volonté de ta part qu'elle soit active ? J'ai eu le cas de figure où la brique était active, mais je ne l'utilisais pas... sourire

Personnellement, pour la partie logs, je serais plus d'avis de faire du tri en fonction de la date de création. As-tu besoin de tous les logs de ta plateforme, ou est-ce que tu ne pourrais pas supprimer antérieurement à une certaine date ?

71 millions de lignes de logs ? Chapeau... J'en ai que 18 ! :D

Olivier
Moyenne des évaluations Utile (1)
En réponse à Olivier Valentin

Re: supprimer les enregistrements de la table mdl_logstore_standard_log dont l'action est "updated" ?

par Séverin Terrier,
Avatar Documentation writers Avatar Moodleurs particulièrement utiles Avatar Testeurs Avatar Traducteurs
Bonjour,

Effectivement, pour ma part, j'ai pour la table de log :

  • de la plateforme 2021-2022 (en 3.11) : 45,7 millions de lignes
  • de la plateforme 2022-2023 (en 4.0) : 38,5 millions de lignes
Alors que nous sommes une université qui tourne généralement entre 6 000 et 7 000 utilisateurs différents connectés dans la journée (10 000 maximum).

Il faudrait sans doute affiner les recherches (en intégrant notamment eventname), pour comprendre ce qui apparait en nombre, et voir si ce ne serait pas lié à un bogue (j'avais rencontré un problème de ce type avec les méta-cours il y a quelques années).

Et éventuellement savoir ce qui a changé "il y a quelques temps...".

Tu pourrais essayer de lancer la requête suivante (attention, très lourde, et qui va certainement durer de nombreuses minutes, 17 minutes sur mon instance 2021-2022) :
SELECT eventname, COUNT(1) AS Nb
FROM mdl_logstore_standard_log
GROUP BY eventname
ORDER BY Nb DESC
LIMIT 50;
Il faudra ensuite fouiller et affiner pour mieux comprendre dans le détail à quoi cela correspond (quel cours, action...).

Séverin
Moyenne des évaluations Utile (2)
En réponse à Séverin Terrier

Re: supprimer les enregistrements de la table mdl_logstore_standard_log dont l'action est "updated" ?

par Jean-Gabriel DEPINOY,
Avatar Moodleurs particulièrement utiles
Merci à tous les deux pour vos pistes.
@ Séverin: Voici le résultat de ta requête:

eventname                                                                      Nb   
\core\event\user_updated 70853199
\core\event\course_viewed 150816
\core\event\webservice_function_called 78163
\core\event\course_category_viewed 43197
\mod_quiz\event\course_module_viewed 43172
\core\event\grade_deleted 39104
\mod_quiz\event\attempt_viewed 36794
\mod_assign\event\course_module_viewed 30007
\mod_quiz\event\attempt_updated 28010
\mod_assign\event\submission_status_viewed 22132
\core\event\user_graded 16480
\mod_resource\event\course_module_viewed 15570
\core\event\dashboard_viewed 15285
\mod_quiz\event\attempt_autosaved 14843
\core\event\user_loggedin 13413
\core\event\grade_item_updated 11787
\core\event\course_module_completion_updated 11432
\mod_quiz\event\attempt_reviewed 11406
\auth_oidc\event\action_failed 8473
\core\event\search_indexed 8067
\mod_book\event\chapter_viewed 6486
\core\event\group_member_added 5196
\mod_assign\event\submission_graded 4970
\mod_quiz\event\attempt_started 4378
\mod_quiz\event\attempt_submitted 4344
\auth_oidc\event\user_loggedin 4329
\core\event\role_assigned 4186
\core\event\notification_sent 4182
\mod_assign\event\grading_form_viewed 4154
\core\event\user_enrolment_created 4100
\mod_quiz\event\attempt_summary_viewed 4058
\mod_assign\event\grading_table_viewed 3656
\core\event\question_deleted 3520
\core\event\group_member_removed 3438
\core\event\question_created 3416
\core\event\tag_added 3398
\core\event\course_module_updated 3358
\core\event\role_unassigned 3276
\core\event\user_login_failed 3107
\core\event\user_enrolment_deleted 2856
\core\event\question_category_viewed 2664
\mod_quiz\event\report_viewed 2605
\core\event\calendar_event_updated 2382
\mod_assign\event\submission_form_viewed 2217
\gradereport_user\event\grade_report_viewed 2203
\core\event\course_backup_created 2055
\core\event\config_log_created 1838
\mod_h5pactivity\event\course_module_viewed 1817
\core\event\mycourses_viewed 1738
\core_h5p\event\h5p_viewed 1689


J'ai du mal à croire qu'il y ait 70 millions de mises à jour des profils des utilisateurs. Il faut donc que je creuse dans les différents champs de cette table pour essayer de trouver un cours ou un utilisateur qui sortirait du lot...

J'en profite d'ailleurs pour te féliciter Séverin pour la discussion vers laquelle tu m'as redirigé qui est très fournie, même si, effectivement, tu as dû te sentir un peu seul dans la résolution de ton problème...

Je vais essayer de m'inspirer de ta démarche mais je pense que ça va être long. Je n'ai pas forcément les compétences pour comprendre le fonctionnement fin de Moodle et trouver la faille dans ma plateforme. Et chaque requête mettant de très nombreuses minutes avant de récupérer un résultat, il faut que je me prépare à de très longues soirées 😋

Je viens de lancer une requête afin de voir si un utilisateur sortait du lot:  SELECT userid, count(*) FROM `mdl_logstore_standard_log`where action='updated' and target='user' GROUP BY userid

Il se trouve que la plupart des utilisateurs qui ressortent de cette requête ont 1 ou 2 occurrences excepté le compte administrateur de la plateforme qui a 70 859 222 occurrences. C'est donc ce compte qui fait grossir ma base de données. Par contre, je ne sais pas où chercher pour trouver la source du problème.

Moyenne des évaluations  -
En réponse à Jean-Gabriel DEPINOY

Re: supprimer les enregistrements de la table mdl_logstore_standard_log dont l'action est "updated" ?

par Olivier Valentin,
Avatar Développeurs de plugins Avatar Moodleurs particulièrement utiles
Une autre piste : pourquoi ne pas mettre en place une règle de surveillance sur cet événement ? J'ai conscience que cet outil ralentit quelques fois la plateforme, mais au moins, tu pourrais peut-être mieux enquêter et comprendre ce qui déclenche autant cela ? C'est en effet très étrange qu'il y ait autant d’occurrences !
Olivier
Moyenne des évaluations Utile (1)
En réponse à Jean-Gabriel DEPINOY

Re: supprimer les enregistrements de la table mdl_logstore_standard_log dont l'action est "updated" ?

par Séverin Terrier,
Avatar Documentation writers Avatar Moodleurs particulièrement utiles Avatar Testeurs Avatar Traducteurs
Re-bonjour Jean-Gabriel,

Zut, fausse manip, j'ai perdu tout le message que j'avais rédigé ; je recommence donc (avec moins de détails)...

Tu as déjà malgré tout bien cerné le problème. Il reste à affiner un peu plus, pour voir tout ce qui est commun, et ce qui diffère. Mais lié au compte administrateur, ça veut certainement dire que c'est une action générique, et certainement avec comme origine "cli", c'est à dire quelque chose généré automatiquement par la plateforme.

Tu peux essayer :
SELECT eventname, component, action, target, origin, courseid, userid, COUNT(1) AS Nb
FROM mdl_logstore_standard_log
WHERE eventname = '\\core\\event\\user_updated'   -- Il faut doubler les \
  AND timecreated > UNIX_TIMESTAMP ('2023-01-01')
GROUP BY eventname, component, action, target, origin, courseid, userid
ORDER BY Nb DESC
LIMIT 30;
Tu devrais limiter très fortement les cas. Il restera à voir à quel moment ils se produisent, pour savoir à quoi s'est lié.

J'essaie d'anticiper la suite avec une idée (si ce n'est pas très gênant) : baisser la fréquence des cron (ou de certaines tâches), pour voir si cela baisse de façon similaire ces occurrences.

Séverin
Moyenne des évaluations Utile (1)
En réponse à Séverin Terrier

Re: supprimer les enregistrements de la table mdl_logstore_standard_log dont l'action est "updated" ?

par Séverin Terrier,
Avatar Documentation writers Avatar Moodleurs particulièrement utiles Avatar Testeurs Avatar Traducteurs
Si tu constates que la plupart des éléments sont identiques, plus besoin de les reprendre pour la suite des requêtes, tu peux essayer quelque chose comme :
SELECT FROM_UNIXTIME(timecreated) AS Date, COUNT(1) AS Nb
FROM mdl_logstore_standard_log
WHERE  eventname = '\\core\\event\\user_updated'   -- Il faut doubler les \
  AND timecreated > UNIX_TIMESTAMP ('2023-01-01')
GROUP BY timecreated
HAVING Nb > 100
ORDER BY Date DESC
LIMIT 30;
Cela te permettra de voir si un grand nombre d'actions de type similaire ont lieu au même moment. Pour ma part, je constate (avec logique) que cela tombe sur l'exécution de la tâche "Synchronisation des utilisateurs CAS" qui synchronise les utilisateurs par rapport à l'annuaire LDAP, et met à jour les informations des utilisateurs. Si la requête ne renvoi rien, tu peux baisser la valeur à 50 ou 20.

Séverin
Moyenne des évaluations Utile (2)
En réponse à Séverin Terrier

Re: supprimer les enregistrements de la table mdl_logstore_standard_log dont l'action est "updated" ?

par Jean-Gabriel DEPINOY,
Avatar Moodleurs particulièrement utiles
Merci encore à vous deux pour vos idées et votre réactivité.

Concernant les règles de surveillance, il faudrait que je me penche sur le sujet car je n'ai jamais fait. C'est simple à faire ? Et surveiller quoi ?

Pour la requête de Séverin, j'ai effectivement 25 580 091 enregistrements qui viennent du cli . Pour le reste, je n'ai que 3 autres lignes sans intérêt qui ne concernent pas l'administrateur (une ligne avec 645 occurrences et 2 lignes avec 1 occurrence chacune). Donc il y a à priori, si je calcule bien, environ 45 000 000 occurrences qui ont eu lieu avant le 1er janvier 2023...

Pour info, même si ce n'est pas directement lié, je parlais dans mon premier message de 2 tables qui posaient problème: mdl_logstore_standard_log et mdl_logstore_lanalytics_log. Hier soir vers 23 heures, j'ai voulu cloner ma plateforme avec Softaculous (je suis chez o2switch). Aujourd'hui, après 18 heures de lancement de la procédure, mon clonage est toujours en cours. C'est la table mdl_logstore_lanalytics_log qui est en cours de clonage et qui met très longtemps à se copier. Ensuite, viendra la table mdl_logstore_standard_log qui risque de mettre un à 2 jours à se copier. Et plus étrange encore, la table mdl_logstore_lanalytics_log clonée en est à peu près à 46 152 000 enregistrements (alors qu'elle n'a pas fini de se copier) tandis que ma table mdl_logstore_standard_log originale ne comprend qu'environ 10 675 000 enregistrements.
Vous y comprenez quelque chose ???
Moyenne des évaluations  -
En réponse à Jean-Gabriel DEPINOY

Re: supprimer les enregistrements de la table mdl_logstore_standard_log dont l'action est "updated" ?

par Jean-Gabriel DEPINOY,
Avatar Moodleurs particulièrement utiles
J'ai l'impression que ça grossit vite. Voici Séverin le résultat de ta dernière requête (beaucoup d'occurrences en 1/4 d'heure !!!) :
SELECT FROM_UNIXTIME(timecreated) AS Date, COUNT(1) AS Nb
FROM mdl_logstore_standard_log
WHERE eventname = '\\core\\event\\user_updated' -- Il faut doubler les \
AND timecreated > UNIX_TIMESTAMP ('2023-01-01')
GROUP BY timecreated
HAVING Nb > 100
ORDER BY Date DESC
LIMIT 30


Date Nb
2023-02-23 17:24:06 201
2023-02-23 17:23:06 226
2023-02-23 17:22:06 113
2023-02-23 17:22:05 181
2023-02-23 17:21:06 180
2023-02-23 17:21:05 149
2023-02-23 17:20:07 215
2023-02-23 17:20:06 114
2023-02-23 17:19:06 147
2023-02-23 17:19:05 182
2023-02-23 17:18:07 131
2023-02-23 17:17:19 143
2023-02-23 17:17:18 186
2023-02-23 17:16:06 135
2023-02-23 17:16:05 194
2023-02-23 17:15:10 138
2023-02-23 17:15:09 190
2023-02-23 17:14:07 126
2023-02-23 17:14:06 203
2023-02-23 17:13:05 224
2023-02-23 17:13:04 102
2023-02-23 17:12:07 153
2023-02-23 17:12:06 154
2023-02-23 17:11:06 103
2023-02-23 17:11:05 184
2023-02-23 17:10:08 197
2023-02-23 17:10:07 118
2023-02-23 17:09:06 129
2023-02-23 17:09:05 200
2023-02-23 17:08:06 203
Moyenne des évaluations  -
En réponse à Jean-Gabriel DEPINOY

Re: supprimer les enregistrements de la table mdl_logstore_standard_log dont l'action est "updated" ?

par Olivier Valentin,
Avatar Développeurs de plugins Avatar Moodleurs particulièrement utiles
La surveillance d'événements se trouve dans Administration des cours > Rapports > Règles de surveillance d'événement. En l'activant, on peut alors programmer des alertes, qui envoient un mail à l'administrateur lorsque certains événements se produisent. Par événements, j'entends bien sûr des logs précis de la plateforme. C'est très simple à utiliser et très efficace, mais comme il faut régler la fréquence de l’avertissement, si la fréquence est trop élevée, cela peut ralentir la plateforme.
Plus d'infos dans la doc : https://docs.moodle.org/4x/fr/Surveillance_d'%C3%A9v%C3%A9nements

Je relis toutefois tous tes échanges avec Séverin : ce n'est peut-être pas une bonne idée d'activer cet outil si tu risques de recevoir 300 mails d'avertissements ! Ou tout du moins, il faut s'y préparer ! Mais si c'est bien ton compte admin qui génère tout cela, ça peut en valoir la peine.

Olivier
Moyenne des évaluations Utile (2)
En réponse à Olivier Valentin

Re: supprimer les enregistrements de la table mdl_logstore_standard_log dont l'action est "updated" ?

par Jean-Gabriel DEPINOY,
Avatar Moodleurs particulièrement utiles
Merci Olivier,
Mais qu'est-ce que je dois surveiller concrètement ? J'avoue que je suis un peu perdu... Est-ce que tu saurais m'aider sur ce point ?
Moyenne des évaluations  -
En réponse à Jean-Gabriel DEPINOY

Re: supprimer les enregistrements de la table mdl_logstore_standard_log dont l'action est "updated" ?

par Christian Bocquet,
Avatar Moodleurs particulièrement utiles

Bonsoir Jean-Gabriel,

En consultant les journaux, retrouve-t-on des informations plus parlantes concernant l'événement "Utilisateur modifié" ?



Et quelle est la source cli ou web ? Quelle adresse IP ?

Christian



Moyenne des évaluations Utile (1)
En réponse à Christian Bocquet

Re: supprimer les enregistrements de la table mdl_logstore_standard_log dont l'action est "updated" ?

par Jean-Gabriel DEPINOY,
Avatar Moodleurs particulièrement utiles
Bonjour Christian,
Merci de t'intéresser à mon problème.
Quand je regarde les journaux de mon compte administrateur, j'ai énormément de requêtes dans les journaux standard (environ 20000 par heure)

Je n'ai rien dans les journaux obsolètes, et quand j'essaye de consulter le Journal dans la base de données externe, j'ai un message d'erreur :

La source des requêtes est cli:


Toutes les heures, chaque utilisateur est modifié par l'administrateur.

Moyenne des évaluations  -
En réponse à Jean-Gabriel DEPINOY

Re: supprimer les enregistrements de la table mdl_logstore_standard_log dont l'action est "updated" ?

par Olivier Valentin,
Avatar Développeurs de plugins Avatar Moodleurs particulièrement utiles
Bonjour Jean-Gabriel,

la surveillance d'événement permet de t'avertir dès que ton système enregistre un log que tu as prédéfini. En gros, si tu veux averti chaque fois que la ligne de log "user_updated" est créée, tu en as la possibilité avec cet outil. Mais dans ton cas, je pense que tu peux oublier cette idée, ce n'est clairement pas pertinent dans ton problème.

Au passage, une question : Séverin a évoqué la synchronisation LDAP, est-ce bien ta méthode d'authentification ? Je retrouve d'anciens tickets qui évoquent un problème similaire, où la synchro tente de mettre à jour tous les utilisateurs même s'il n'y a rien : https://tracker.moodle.org/browse/MDL-57976 et https://tracker.moodle.org/browse/MDL-59126 Mais depuis le temps, ils devraient être résolus !

Olivier
Moyenne des évaluations Utile (1)
En réponse à Olivier Valentin

Re: supprimer les enregistrements de la table mdl_logstore_standard_log dont l'action est "updated" ?

par Jean-Gabriel DEPINOY,
Avatar Moodleurs particulièrement utiles
Bonjour Olivier,
Merci pour l'info. Effectivement, la surveillance d'événement n'est pas utile pour moi maintenant que je sais quel événement se produit. Le problème est maintenant de comprendre pourquoi...
Pour ma part, j'utilise la connexion OpenID avec Microsoft Azure AD.
Moyenne des évaluations  -
En réponse à Jean-Gabriel DEPINOY

Re: supprimer les enregistrements de la table mdl_logstore_standard_log dont l'action est "updated" ?

par Séverin Terrier,
Avatar Documentation writers Avatar Moodleurs particulièrement utiles Avatar Testeurs Avatar Traducteurs
Bonjour Jean-Gabriel,

Effectivement, origine = cli et lié au compte administrateur signifie que c'est une action automatique de la plateforme, certainement liée à une tâche programmée (ou ad-hoc).

La surveillance d'événement ne te sera effectivement d'aucune utilité, sachant que tu sais déjà d'où vient le problème.

Du coup, afin de mieux comprendre s'il y a un bogue, et lequel exactement, tu vas pouvoir tester différentes approches :
  • chercher dans le traqueur s'il y a des bogues déclarés liés à cette méthode d'authentification (et/ou Microsoft Azure AD)
  • s'il y a une tâche de synchronisation, essayer de la désactiver (ou la lancer moins souvent)
  • tu disais, depuis "quelques temps" ; est-ce qu'il y a eu des choses particulières il y a "quelques temps", genre changement de version PHP, ou Moodle, ou plugin d'authentification, ou annuaire AD... ?
  • est-ce que des données particulières dans l'annuaire (caractère spécial...) pourraient engendrer ce problème ?
En tout cas, je pense que tu vas pouvoir effectuer une coupe franche dans ces log, afin d'alléger ta base de données. Simplement, ça pourrait être intéressant de trouver la date à laquelle cela a débuté, afin de corréler cela avec d'autres actions effectuées à ce moment.

Séverin
Moyenne des évaluations Utile (1)
En réponse à Séverin Terrier

Re: supprimer les enregistrements de la table mdl_logstore_standard_log dont l'action est "updated" ?

par Séverin Terrier,
Avatar Documentation writers Avatar Moodleurs particulièrement utiles Avatar Testeurs Avatar Traducteurs

Re-bonjour,

Concernant les logs, et leur nettoyage, tu peux essayer les éléments suivants.

Pour (essayer de) trouver depuis quand cela a commencé (je cible fin 2022, vu les nombres de log indiqués précédemment) :

SELECT FROM_UNIXTIME(timecreated) AS Date, COUNT(1) AS Nb
FROM mdl_logstore_standard_log
WHERE eventname = '\\core\\event\\user_updated' AND origin='cli' AND courseid=0 
  AND timecreated BETWEEN UNIX_TIMESTAMP ('2022-10-01') AND UNIX_TIMESTAMP ('2023-01-01')
GROUP BY timecreated
HAVING Nb > 100
ORDER BY Date ASC
LIMIT 20;

Suivant les résultats, monter la valeur à 200, ou au contraire la baisser à 50... car il est sans doute normal, lors d'une synchronisation, d'avoir pas mal de mises à jour d'utilisateurs. Ce qui est plus anormal est que cela soit relancé sans arrêt.

Pour connaitre le nombre de log entre deux dates liés à cela :

SELECT COUNT(1) AS Nb
FROM mdl_logstore_standard_log
WHERE eventname = '\\core\\event\\user_updated' AND origin='cli' AND courseid=0 
  AND timecreated BETWEEN UNIX_TIMESTAMP ('2022-12-01') AND UNIX_TIMESTAMP ('2023-02-01');
Et pour les supprimer (tu ne perdras rien d'utile et allègeras ta BDD), il suffit de remplacer la première ligne (entière) de la requête précédente par "DELETE".

Séverin

Moyenne des évaluations Utile (2)
En réponse à Séverin Terrier

Re: supprimer les enregistrements de la table mdl_logstore_standard_log dont l'action est "updated" ?

par Séverin Terrier,
Avatar Documentation writers Avatar Moodleurs particulièrement utiles Avatar Testeurs Avatar Traducteurs
Pour trouver la date d'origine, cela sera certainement plus efficace en groupant par jour (plutôt que par seconde) :

SELECT DATE_FORMAT(FROM_UNIXTIME(timecreated), '%Y-%m-%d') AS Date, COUNT(1) AS Nb
FROM mdl_logstore_standard_log
WHERE eventname = '\\core\\event\\user_updated' AND origin='cli' AND courseid=0
AND timecreated BETWEEN UNIX_TIMESTAMP ('2022-10-01') AND UNIX_TIMESTAMP ('2023-01-01')
GROUP BY Date
HAVING Nb > 1000
ORDER BY Date ASC
LIMIT 20;
Le cas échéant, faire varier la valeur pour trouver des résultats probants...

Question subsidiaire : tu nous indiques avoir 300 utilisateurs actifs, mais combien de personnes dans l'annuaire ? Et de comptes utilisateurs sur Moodle ?

Et si tu n'utilises pas les journaux obsolètes, ni les journaux en base de donnée externe, tu devrais les désactiver, cela simplifiera l'interface, et évitera des risques de mélange.

Par ailleurs, ne relance surtout pas de clonage de ta base ou autre opération lourde avant d'avoir fini ton nettoyage. Avoir de multiples opérations lourdes en parallèle sur une base de données n'est jamais une bonne idée...

Séverin
Moyenne des évaluations Utile (1)
En réponse à Jean-Gabriel DEPINOY

Re: supprimer les enregistrements de la table mdl_logstore_standard_log dont l'action est "updated" ?

par Christian Bocquet,
Avatar Moodleurs particulièrement utiles

Bonjour Jean-Gabriel,

Je ne connais pas OpenID et Microsoft Azure AD.
Puisque la source est CLI, n'y aurait-il pas une tâche programmée ajoutée à la liste de toutes les tâches programmées standards par un plugin (OpenID Connect ? ou Azure... ?) qui lance toutes les heures  une mise à jour des comptes utilisateurs, même ceux sans réelle modification ?

Christian


Moyenne des évaluations Utile (1)
En réponse à Christian Bocquet

Re: supprimer les enregistrements de la table mdl_logstore_standard_log dont l'action est "updated" ?

par Jean-Gabriel DEPINOY,
Avatar Moodleurs particulièrement utiles
Merci Séverin et Christian pour vos pistes,
J'ai commencé à essayer de supprimer ces lignes de ma table mais le problème c'est qu'il y a tellement de lignes à supprimer que quand je lance la requête dans PhpMyAdmin, j'ai régulièrement un message "MYSQL server has gone away" sûrement à cause d'un timeout fixé par o2switch.
Comme en parallèle ma table continuait à s'alimenter toutes les minutes (pas toutes les heures comme indiqué dans mon message précédent), ma table augmentait plus vite que je n'arrivais à effacer des enregistrements.
Sur vos conseils, j'ai désactivé provisoirement plusieurs tâches en lien avec Microsoft Azure AD qui se produisaient toutes les minutes et ma table arrête déjà de croître.
Il faut maintenant que j'arrive à trouver une solution pour exécuter ma requête sans que je sois bloqué régulièrement par ce message "MYSQL server has gone away", sinon, j'arriverai jamais à bout du nettoyage de cette table.
Si l'un d'entre vous a des connaissances dans ce domaine, je suis preneur...
Merci encore pour votre aide. On avance...
Moyenne des évaluations  -
En réponse à Jean-Gabriel DEPINOY

Re: supprimer les enregistrements de la table mdl_logstore_standard_log dont l'action est "updated" ?

par Séverin Terrier,
Avatar Documentation writers Avatar Moodleurs particulièrement utiles Avatar Testeurs Avatar Traducteurs
Du coup, tu peux t'appuyer sur la requête de suppression de mon message précédent, en réduisant les écarts de dates (à une semaine, voire 3 jours) clin d’œil

A ta place, je laisserai quand même les tous derniers (1 ou 2 jours), et si possible les premiers, pour permettre de trouver la date d'origine.

Pour les tâches impliquées, il faudrait aller consulter les résultats d'exécution et durées d'exécution, depuis "Administration du site > Serveur > Tâches > Journaux des tâches programmées". Tu devrais vite repérer laquelle est concernée.

Séverin
Moyenne des évaluations Utile (1)
En réponse à Jean-Gabriel DEPINOY

Re: supprimer les enregistrements de la table mdl_logstore_standard_log dont l'action est "updated" ?

par Olivier Valentin,
Avatar Développeurs de plugins Avatar Moodleurs particulièrement utiles
Face aux problèmes de déconnexion, la meilleure solution est encore de lancer la requête en ligne de commande, mais encore faut-il que tu y aies accès...
Sinon, normalement, c'est en modifiant le max_execution_time du fichier php.ini du serveur, qui permettrait de donner plus de temps pour exécuter la requête, mais j'imagine qu'il ne doit pas être modifiable directement par tes soins. Tu peux vérifier la valeur actuelle dans Administration du site > Serveur > Infos PHP.
Olivier
Moyenne des évaluations Utile (1)
En réponse à Olivier Valentin

Re: supprimer les enregistrements de la table mdl_logstore_standard_log dont l'action est "updated" ?

par Jean-Gabriel DEPINOY,
Avatar Moodleurs particulièrement utiles
@Olivier : Max_execution_time est égal à 3600
Moyenne des évaluations  -
En réponse à Jean-Gabriel DEPINOY

Re: supprimer les enregistrements de la table mdl_logstore_standard_log dont l'action est "updated" ?

par Jean-Gabriel DEPINOY,
Avatar Moodleurs particulièrement utiles
@Séverin: J'ai bien accès aux résultats d'exécution des tâches programmées mais je n'arrive pas à identifier celle qui pose problème... Comment faut-il faire ?
En fait, je pense que le problème existe depuis toujours. Simplement, les historiques ne sont conservés qu'à partir du 1er septembre.
Ta requête donne environ 400 000 requêtes par jour depuis le début.
Moyenne des évaluations  -
En réponse à Jean-Gabriel DEPINOY

Re: supprimer les enregistrements de la table mdl_logstore_standard_log dont l'action est "updated" ?

par Christian Bocquet,
Avatar Moodleurs particulièrement utiles

N'est-ce pas celle liée au plugin Microsoft Azure AD ?

Sinon peut-être en consultant les "Tâches en cours actuellement" ?
Lien:
tonsitemoodle/admin/tool/task/runningtasks.php

Documentation en anglais :
https://docs.moodle.org/401/en/Scheduled_tasks#Tasks_running_now

Moyenne des évaluations  -
En réponse à Jean-Gabriel DEPINOY

Re: supprimer les enregistrements de la table mdl_logstore_standard_log dont l'action est "updated" ?

par Séverin Terrier,
Avatar Documentation writers Avatar Moodleurs particulièrement utiles Avatar Testeurs Avatar Traducteurs
Je pensais qu'en triant (sur les entêtes de tableau) tu pourrais trouver facilement celles dont "Résultat" est "Échec", ou celles dont "Durée" est importante.
Attention : tu peux avoir un filtrage, qui reste actif (à réinitialiser le cas échéant).

Mais peut-être que malgré tout, ces tâches s'exécutent rapidement, et correctement, mais passent simplement leur temps à mettre à jour des choses (qui n'en ont pas forcément besoin).

Dans les tâches programmées, as-tu vérifié leur programmation, en terme de répétition jour/heure/minute... (par rapport à ce qui est prévu par défaut) ? Est-ce qu'il y a des choses anormales, ou qui pourraient être améliorées ?

Séverin
Moyenne des évaluations  -
En réponse à Jean-Gabriel DEPINOY

Re: supprimer les enregistrements de la table mdl_logstore_standard_log dont l'action est "updated" ?

par Jean-Gabriel DEPINOY,
Avatar Moodleurs particulièrement utiles
Grâce à votre aide (Séverin, Olivier et Christian), j'avance. Je suis obligé de supprimer les logs par période de 10 jours, sinon j'obtiens un message de "server has gone away".
J'ai déjà supprimé les logs des mois de septembre et octobre 2022. Je suis passé de 71 000 000 enregistrements à 59 000 000.
Concernant les tâches en échec, je n'en ai qu'une: il s'agit de la création de cache pour le plugin securepdf. Mais cette tâche effectue des lectures mais aucune écriture dans la BDD.
Par contre, il y a bien la tâche "Synchronisez les utilisateurs avec Azure AD" qui s'effectuait bien toutes les minutes avec 918 écritures dans la BDD.
Moyenne des évaluations  -
En réponse à Jean-Gabriel DEPINOY

Re: supprimer les enregistrements de la table mdl_logstore_standard_log dont l'action est "updated" ?

par Olivier Valentin,
Avatar Développeurs de plugins Avatar Moodleurs particulièrement utiles
Re,
je déterre un message similaire au tien avec la même ligne de log en surnombre et avec la même origine : la synchro des comptes avec Azure : https://moodle.org/mod/forum/discuss.php?d=420602
Est-ce que ta tâche de synchronisation passe bien ? Cela semblait être à l'origine du problème ! Peut-être qu'en contactant la personne, tu pourras trouver une solution !
Olivier
Moyenne des évaluations Utile (1)
En réponse à Olivier Valentin

Re: supprimer les enregistrements de la table mdl_logstore_standard_log dont l'action est "updated" ? [Résolu]

par Jean-Gabriel DEPINOY,
Avatar Moodleurs particulièrement utiles

Bonjour à tous,

Je reviens vers vous pour vous indiquer que mon problème est résolu.

J'ai supprimé tous les enregistrements de la table mdl_logstore_standard_log qui avaient les caractéristiques suivantes :

     - action: updated

     - courseid: 0

     -userid: 2

J'ai réactivé les tâches programmées en lien avec Microsoft Azure. J'en ai profité pour reprogrammer la tâche "Synchronisez les utilisateurs avec Azure AD" à une fois par jour au lieu de toutes les minutes (c'est cette tâche qui créait des millions d'enregistrements dans ma BDD).

Par la même occasion, j'ai supprimé tous les enregistrements de la table mdl_logstore_lanalytics_log qui avaient pour valeur du champ eventid=1 (qui correspond à la mise à jour des utilisateurs).

Chacune de ces deux tables ont donc TRES fortement perdu du poids. On est passé respectivement de plus de 70 millions et plus de 11 millions d'enregistrements à 750 000 et 250 000 enregistrements.

Ces 2 tables qui occupaient plusieurs dizaines de giga-octets dans ma BDD ne font plus que 350Mo et 20Mo !!!

Un grand merci à Séverin, Olivier et Christian pour leur aide précieuse.

Moyenne des évaluations Utile (4)