Je sais que ça va faire plaisir à certains, mais après une profonde introspection dans les arcanes de la nouvelle organisation de la journalisation de Moodle, les blocs Use_Stats et rapports de session et autres plugins de mon parc qui utilisent les logs vont être rénovés et mis à niveau pour fonctionner avec tout les dépôts d'historiques internes de Moodle post 2.6.
Publication à prévoir pour début Mars...
Valéry.
Bonjour,
Du coup, je suppose qu'on pourra désactiver alors les logs obsolètes ?
En mode debug ce bloc donne une liste d'erreurs qui je suppose disparaîtront également ...
Bonjour,
A propos du bloc "Mesure d'activité" (bloc use_stats), j'ai voulu le tester sous Moodle 2.9 (avec la dernière version connue, officiellement compatible 2.7), et je rencontre un problème : il n'y a pas moyen de supprimer un bloc mis en place !
En effet, j'ai bien, dans le menu déroulant des paramètres du bloc, la possibilité de modifier, cacher ou attribuer des rôles, mais pas celle de le supprimer (contrairement à tous les autres blocs de la page).
Et ceci, alors même que j'ai le rôle d'administrateur. Pas mieux si j'essaie de m'attribuer le rôle d'enseignant dans le cours, ni si j'essaie le thème "More" au lieu de "Essential"
Est-ce un problème connu ? Quelqu'un aurait une solution ?
Séverin
Bonjour,
J'ai aussi ce problème en 2.7.
Pour m'en sortir je crois que j'avais carrément supprimé puis réinstallé le bloc .
Et ne l'ai plus installé dans les cours, mais en un seul exemplaire dans la partie visible de l'administrateur en page d'accueil. (Thème Essential)
La commande de suppression du bloc n'existe pas.
bonjour
je confirme que quand je l'utilisais en 2.7, pas de suppression
d'où mes désinstallations après installation et mise en partie visible pour l'administrateur sur la page d'accueil avec le thème Essential...
Bonjour,
c'est un souci effectivement, notamment pour des utilisateurs qui ont beaucoup de cours (temps de réponse très long) par exemple les gestionnaires ou les administrateurs:
1ère solution: le désinstaller
2ème solution: cacher le bloc
3ème solution: le faire afficher, non plus sur la page d'Accueil mais sur une partie du cours moins utilisée
Bonjour a tous.
Quelques infos sur ce bloc que je viens de retravailler assez profondément. Ce bloc a du subir des transformations importantes pour tenir compte du changement radical de politique de stockage des historiques.
Le bloc est actuellement republié en 2.7 sur une version testée. en 2.8 et en 2.9. Les premiers tests 2.9 montrent un problème d'accès aux "readers" d'historiques et demandent un peu plus d'introspection.
Concernant la charge de calcul, j'ai pu constater que lorsqu'une stratégie d'alimentation automatique de compte quotidienne existait et injectait des milliers (voire des centaines de milliers d'événement dans les historiques, ce bloc peut commencer à consommer pas mal de temps de calcul. Il faut alors réduire la "fenêtre d'exploration par défaut" (à quelques jours par exemple) et ne pas tenter d'extraire plusieurs mois de données avant d'avoir nettoyé les historiques des nombreux événements automatiques attribués à l'administrateur.
Cdt
A suivre : le rapport corollaire "Sessions de formation" en cours de revision.
Merci Valery pour ces explications et ton implication sur ce bloc très ... utile.
Bonjour Valery,
Merci pour cette mise à jour rapide de ce bloc, maintenant officiellement compatible Moodle 2.9, qui corrige l'impossibilité de suppression.
J'ai donc mis à jour ce bloc sur la plateforme ou je l'avais installé. Je constate depuis une charge (relativement) importante du serveur, et des nouvelles lignes qui apparaissent dans l'exécution de chaque cron, de cette forme :
Execute scheduled task: Compilation des temps
... started 13:50:06. Current memory use 55.1Mo.
... Compiling gaps from : 1412687606
... 8340 logs gapped
... used 29164 dbqueries
... used 966.65971302986 seconds
Scheduled task complete: Compilation des temps
Cela occupe effectivement beaucoup de temps (heureusement, mon cron ne tourne que toutes les 30 minutes sur cette instance), et vu les dates auxquelles cela correspond (octobre 2014), j'ai peur que ça tourne pendant quelques jours...
grep "Compiling gaps from" cron.2015-10-28.*
cron.2015-10-28.11h20.txt:... Compiling gaps from : 0
cron.2015-10-28.11h50.txt:... Compiling gaps from : 1410759524
cron.2015-10-28.12h20.txt:... Compiling gaps from : 1411191570
cron.2015-10-28.12h50.txt:... Compiling gaps from : 1411665720
cron.2015-10-28.13h20.txt:... Compiling gaps from : 1412199601
cron.2015-10-28.13h50.txt:... Compiling gaps from : 1412687606
cron.2015-10-28.14h20.txt:... Compiling gaps from : 1413112414
Autre question : qu'est-ce qui est repris exactement dans la table mdl_block_use_stats_log ? Parce qu'elle contient très vite un très grand nombre d'enregistrements...
Séverin
Bonjour,
Pour le moment, les cron continuent de calculer des informations à chaque exécution.
Si la première date (1410759524) correspondait au 15/09/2014, ça a avancé maintenant jusqu'au 25/05/2015. Encore deux jours et ça devrait (enfin) être réglé...
Séverin
Bonjour,
Le traitement avance encore : j'arrive à la date du 12/09/2015, et j'ai 664 000 enregistrements dans mdl_block_use_stats.
Séverin
Bonjour,
Mes craintes étaient fondées en ce qui concerne le temps de calcul : j'arrive maintenant (après plus d'une semaine, et un cron toutes les 30 minutes) au calcul des éléments liés au 19/09/2015, et j'en suis à 847610 enregistrements dans mdl_block_use_stats !
Séverin
Bonjour,
Conclusion : En langage de béotien que faut-il faire ?
Désinstaller (ou désactiver) ce bloc ?
Bonjour Daniel,
Et bien, tout dépend si cela charge ton serveur (ou pas). Peut-être que le problème (pour moi) est surtout lié au fait que ce soit une installation nouvelle, et qu'il faut calculer tout l'historique (lourd) existant ?
En tout cas, la charge est toujours présente
Je suis maintenant rendu au 29/09/2015 (1443505101).
Ce qui est étrange, c'est qu'à chaque exécution, il n'arrive pas à avancer beaucoup (quelques secondes traitées) :
grep "Compiling gaps from" cron.2015-11-1* | tail -5
cron.2015-11-10.07h50.txt:... Compiling gaps from : 1443505071
cron.2015-11-10.08h20.txt:... Compiling gaps from : 1443505078
cron.2015-11-10.08h50.txt:... Compiling gaps from : 1443505086
cron.2015-11-10.09h20.txt:... Compiling gaps from : 1443505093
cron.2015-11-10.09h50.txt:... Compiling gaps from : 1443505101
Alors que le temps de calcul est très important (nombre de requêtes et durée) :
grep -A 3 "Compiling gaps from" cron.2015-11-1* | tail -15
cron.2015-11-10.08h50.txt:... Compiling gaps from : 1443505086
cron.2015-11-10.08h50.txt-... 800 logs gapped
cron.2015-11-10.08h50.txt-... used 2406 dbqueries
cron.2015-11-10.08h50.txt-... used 913.22857809067 seconds
--
cron.2015-11-10.09h20.txt:... Compiling gaps from : 1443505093
cron.2015-11-10.09h20.txt-... 970 logs gapped
cron.2015-11-10.09h20.txt-... used 2917 dbqueries
cron.2015-11-10.09h20.txt-... used 918.66210699081 seconds
--
cron.2015-11-10.09h50.txt:... Compiling gaps from : 1443505101
cron.2015-11-10.09h50.txt-... 800 logs gapped
cron.2015-11-10.09h50.txt-... used 2406 dbqueries
cron.2015-11-10.09h50.txt-... used 989.58330082893 seconds
Le nombre d'enregistrements a encore bien augmenté :
SELECT COUNT(1) FROM mdl_block_use_stats_log; +----------+
| COUNT(1) |
+----------+
| 1073180 |
+----------+
Il semblerait donc qu'il y a des requêtes qui ne doivent pas être optimisées...
Je ne sais pas si je le laisse aller jusqu'au bout de ses calculs, pour voir si ça s'améliore ensuite, ou si je désinstalle tout.
Séverin
Bonjour,
Non la part serveur qui m'est allouée montre que mon CPU n'est guère chargé.
Le seul cas où je l'ai vu en surcharge c'est quand j'avais des problèmes de sauvegardes automatiques qui s'éternisaient et ne se faisaient plus correctement pour certains "gros" cours.
Bonjour,
Une semaine plus tard, j'ai avancé dans le traitement (je suis à 1444282705, soit le 8/10/2015), mais juste d'une semaine environ
Et dans mdl_block_use_stats_log, j'ai maintenant 1314941 lignes !
A ce rythme, ça risque de prendre encore un sacré moment avant que tout soit traité
Séverin
Bonjour,
Après 3 semaines de patience, voyant que le calcul des éléments n'avance pas de façon notable, et que cela surcharge le serveur de façon continue, je jette l'éponge, et désinstalle ce bloc !
Peut-être ferais-je un nouvel essai dans quelques mois, s'il y a des améliorations (conséquentes)...
Séverin
J'en profite pour signaler une mise à jour du plugin dispo ici :
https://github.com/vfremaux/moodle-block_use_statsdeux filtres nouveaux : tri par utilisateur et par durée (temps descendant)
et super utile ds les réglages pour le bloc via l'admin : filtrage de la liste au delà d'un seuil de temps.
Merci Florence,
Utile pour les fans de ce plugin dont je suis.
Mais il semble que cette version github date déjà de trois ans ???
Celle disponible sur Moodle.org a été revue en septembre 2015.
Logiquement elle devrait être plus récente non ?
On peut donc installer celle dont tu nous proposes le lien Github ?
Je suis sur 2.9.
Daniel,
Attends un poil , je te fais signe, pleins de bugfix en cours par son auteur. Relance moi d'ici quelques jours si besoin.Ce sera ok pour v 2.9 et 3.0 . D'ailleurs si tu viens au moodle moot je pense qu'il va en parler grandes mailles.
Bonjour,
Ce plugin est déjà en service chez moi en 2.9. La version figurant dans la liste des plugins de Moodle (à peu près les seuls que j'installe).
Je ne l'ai pas installé sur Moodle 3.
Pour moi, aucune urgence. Il me convient comme cela.