Purges des caches de catégories => gros ralentissements de la plateforme
Je viens voir ici si d'autres personnes partagent mon problème (et au mieux, comment ils l'ont résolu) :
Nous avons mis à jour notre plateforme moodle en version 3.1 il y a un mois. Depuis, nous constatons des pics de charges très important au niveau de nos serveurs apache. Au début, on se disait que c'était la rentrée, donc le trafic était élevé, que ça allait passer.
Maintenant, le pic de la rentrée s'est passé, nous constatons toujours de fortes montées en charge sporadiques. Après diagnostic, il apparaît que les charges soient liées au renouvellement du cache des catégories (cache Moodle : core_coursecattree dans le MUC). En effet, à chaque changement de nom de cours, de visibilité de cours, d'ajout/modifiation/suppression de cours ou de catégorie, le cache des catégories est régénéré dans le répertoire /cache/arche/core_coursecattree et ça engendre une très forte montée en charge de la machine (allant jusqu'à ralentir le site tout entier pendant un ou deux minutes - on a actuellement 1747 catégories, c'est long à recharger).
On a fait du tuning au niveau base de données, ça n'a rien changé, on a augmenté les CPU de nos machines apache, rien changé, bref, on a fait tout ce à quoi on pouvait pensait, ça n'a rien changé.
J'ai vu un ticket moodle qui résume mon problème (https://tracker.moodle.org/browse/MDL-48166) mais il ne semble pas avoir été pris en compte par les développeurs. Et vous, avez-vous déjà rencontré ce problème ?
Merci par avance pour vos éclaircissement
Re: Purges des caches de catégories => gros ralentissements de la plateforme
Bonjour Benjamin,
ma seule réponse actuellement est avant tout une réponse architecturale : à 1740 catégories de cours, le territoire pédagogique commence à être énorme. C'est le paradoxe de Moodle : plus moodle progresse, plus il offre des solutions en face du besoin "professionnel" de gestion du capital numérique, donc plus on en met et plus il y a gérer de données et métadonnées. Les caches sont le dernier rempart en effet de la performance, dans la mesure où la technologie principale n'a pas de fonctionnement en "Serveur d'application" (quatre tiers) alors que nous ne sommes qu'en trois tiers.
Les seules solutions que j'utilise depuis bien longtemps sont le découpage structurel de l'organisation de moodle en unités plus petites, découpées selon une logique en général "administrative" ou "politique" (établissement, composante). En virtualisant par VMoodle, cela ne fait au final toujours qu'une "installation" technique de Moodle et évidemment quelques problèmes "nouveaux" à gérer comme la circulation et l'alimentation distribuée des utilisateurs, mais côté performance, distribuer les utilsateurs sur 6 unités de 2000 cours diminue par plus de 4 la complexité et la charge d'une plate-forme unique. Toutes les manoeuvres un peu lourdes d'administration n'affectent qu'une "zone" et non plus la totalité.
Re: Purges des caches de catégories => gros ralentissements de la plateforme
Bonjour Benjamin,
Moi qui pensait que mon Moodle avait trop de catégories... Je n'en ai QUE 818. N'ayant pas mis en place d'accélérateur PHP ni de cache, mon retour d'expérience n'est pas pertinent... Désolé.
Est-ce qu'une refonte de l'arborescence ne serait pas utile ? Au delà des aspects techniques, j'imagine le casse-tête de la navigation.
A suivre...
Patrick
Re: Purges des caches de catégories => gros ralentissements de la plateforme
On a pas trop de soucis de navigation car nos étudiants vont directement dans leur profil qui leur indique les cours auxquels ils sont inscrits. Ils n'ont pas à s'y rendre à pied.
Par contre, si on ne trouve pas de réponse "technique" à notre problème, on va creuser pour patcher le code et essayer de ne purger le cache que des catégories impactées par une modification, ça sera beaucoup plus rapide et efficace.
Vous n'avez pas constaté de problème de ce type après votre mise à jour en 3.1 (pour ceux qui l'ont faite) ?
Re: Purges des caches de catégories => gros ralentissements de la plateforme
Re: Purges des caches de catégories => gros ralentissements de la plateforme
Vous n'avez pas constaté de problème de ce type après votre mise à jour en 3.1 (pour ceux qui l'ont faite) ?
Non. Mais nous avons nettement moins de catégories que toi !
J'ai cependant renoncé à utiliser la "surveillance d'événements" qui, chez moi, ralentissait toute la plateforme. Mais ce n'était pas une surprise puisqu'il est affiché une mise en garde.
Re: Purges des caches de catégories => gros ralentissements de la plateforme
Bonjour Benjamin,
on ne va pas faire un concours, mais nous avons 2400 categories...sans trop de soucis non plus de navigation.
Nous avons eu des soucis lors de la mise a jour en 3.0 lié a ce nombre de catégories, probablement du au theme essential .
Lors de notre passage à la 3.1, nous seront donc très vigilants.
Par contre , as tu un systeme de cache de type memcached? En effet nous avons eu pas mal de soucis de régénération du cache et avions mis en place memcached qui fonctionne plutôt bien et nous évite tous ces ralentissements.
Bonne journée
Anne
Re: Purges des caches de catégories => gros ralentissements de la plateforme
Merci pour le retour, nous n'utilisons encore pas memcached pour gérer nos caches, on utilise un montage mémoire sur notre filesystem.
Nous allons mettre en place un memcached afin de voir si cela résout notre problème, je vous tiendrai au courant.
Encore merci pour l'astuce.
Bonne journée
Re: Purges des caches de catégories => gros ralentissements de la plateforme
Pour mémoire (au cas où), le fichier de conf devrait se trouver dans /etc/sysconfig/memcached (sur une redhat/centos c'est le cas)
Re: Purges des caches de catégories => gros ralentissements de la plateforme
Bonjour Benjamin
voici ce que me donne la commande suivante. Ce n'est pas moi qui ai configuré le serveur
telnet localhost 11211
Trying ::1...
Trying 127.0.0.1...
Connected to localhost.
Escape character is '^]'.
stats settings
STAT maxbytes 67108864
STAT maxconns 1024
STAT tcpport 11211
STAT udpport 11211
STAT inter 127.0.0.1
STAT verbosity 0
STAT oldest 3108580
STAT evictions on
STAT domain_socket NULL
STAT umask 700
STAT growth_factor 1.25
STAT chunk_size 48
STAT num_threads 4
STAT num_threads_per_udp 4
STAT stat_key_prefix :
STAT detail_enabled no
STAT reqs_per_event 20
STAT cas_enabled yes
STAT tcp_backlog 1024
STAT binding_protocol auto-negotiate
STAT auth_enabled_sasl no
STAT item_size_max 1048576
STAT maxconns_fast no
STAT hashpower_init 0
STAT slab_reassign no
STAT slab_automove 0
STAT lru_crawler no
STAT lru_crawler_sleep 100
STAT lru_crawler_tocrawl 0
STAT tail_repair_time 0
STAT flush_enabled yes
STAT hash_algorithm jenkins
END
Bonne journee
Re: Purges des caches de catégories => gros ralentissements de la plateforme
On a mis en place le memcached ce matin, c'est un truc de fou, on passe d'un temps de 1 à 2 minutes de génération des caches (occasionnant d'énormes lenteurs) à 1 seconde !
J'attends un peu avant d'estimer la taille nécessaire globale, je pense que 100Mo seront largement suffisants au final pour tous nos caches.
Merci encore pour l'info, ça nous a bien aidé. J'étais resté sur ma solution de stockage en RAM pensant qu'on ne pourrait pas aller plus vite, je m'étais trompé. Peut-être que les développeurs moodle ont bien plus optimisé le traitement pour memcached.
Bonne journée
Re: Purges des caches de catégories => gros ralentissements de la plateforme
Ce serait super, quand tu auras stabilisé tes réglages, de les partager ici. Je suis très très intéressé.
Re: Purges des caches de catégories => gros ralentissements de la plateforme
Re: Purges des caches de catégories => gros ralentissements de la plateforme
Bonjour,
L'un de ces deux paramètres doit-il être activé dans les extensions php ?
Car dans la liste des paramètres serveur/environnement un seul semble s'en approcher "opcache" et est indiqué OK
Re: Purges des caches de catégories => gros ralentissements de la plateforme
Bonjour Benjamin,
Je tombe tardivement sur cette discussion, qui explique sans doute quelques montées en charge que nous avons pu constater. De mon côté, ma plateforme se rapproche plutôt de celle de Patrick, avec environ 800 catégories de cours.
Il semblerait qu'il y ait eu des avancées sur MDL-48166, en tout cas en commentaires et solutions de contournement possibles.
Pourrais-tu donner plus de renseignements sur la solution memcached mise en place chez vous, avec un maximum de détails précis ? Et sur ce que vous stockiez précédemment en RAM ?
Merci d'avance,
Séverin
Re: Purges des caches de catégories => gros ralentissements de la plateforme
Je vais essayer d'être le plus précis possible.
Jusque là, nous utilisions le système de cache de moodle couplé à un montage en RAM du filesystem dédié au cache (on utilise ça aussi pour les sessions PHP, je l'avais présenté juste avant toi en 2014 à Tours). Comme je l'ai expliqué ci-dessus, à chaque changement d'un cours ou d'une catégorie, l'intégralité de ce cache était régénéré, cela prenait entre 1 et 2 minutes pendant lesquelles la plateforme était quasi inutilisable (je ne vous raconte pas les plaintes des enseignants pour la rentrée). J'ajoute que ce problème a été rencontré à partir de notre mise à jour de 2.8 vers 3.1, nous n'avions pas le problème avant (avec, pourtant, autant de catégories).
Du coup, sur les bons conseils d'Anne (merci encore Anne, si un jour on se voit dans la vraie vie, tu mérites une bière - ou un café), j'ai mis en place un serveur memcached. La mise en place est très simple : yum/apt-get install memcached puis j'ai mis cette configuration dans le fichier /etc/sysconfig/memcached (le fichier peut varier en fonction de la distribution - centos7 chez nous) :
PORT="11211"
USER="memcached"
MAXCONN="1024"
#CACHESIZE="64"
CACHESIZE="100"
OPTIONS="-v"
# journalctl -u memcached pour avoir les logs
En modifiant uniquement le mapping des caches de l'arbre des catégories du filesystem RAM vers le memcached, cela a résolu nos problèmes : moins d'une seconde entre chaque régénération du cache, il semble que les dev' aient bien optimisé le code pour memcahed.
J'en ai tout de même profité pour mapper quelques entrées de cache qui doivent être partagées entre nos différents serveurs :
- Définitions des questions
- Information du groupe de cours
- Réglages
- Arbre des catégories de cours
Je m'en tiens là pour le moment. Avec ces caches, l'espace occupé dans memcached est monté à 9Mo et en moyenne 3Mo (pour environ 7500 entrées), autant dire rien du tout. On peut voir qu'il est extrêmement sollicité en faisant un tcpdump sur le serveur memcached : tcpdump port 11211
Je joins à ce message une capture de la charge d'une de nos 4 machines, vous pouvez clairement voir à partir de quand on a changé les caches Je termine avec une indication de la fréquentation de notre plateforme : toujours entre 3000 et 8000 utilisateurs connectés simultanément avec un pic à 11000 la semaine dernière. Plus rien n'est lent, que ça soit avec 3000 ou 11000 utilisateurs, la plateforme réponds toujours aussi rapidement.
Si vous avez d'autres questions, n'hésitez pas !
Re: Purges des caches de catégories => gros ralentissements de la plateforme
Merci pour ton partage,
En fait , memecached était installé depuis 3 ans mais lors de notre mise à jour de 2.7 vers 3.0, nous avions des correspondances de cache qui n'étaient plus a jour, avec des ralentissements très importants (voire une indisponibilité de la plateforme quelques minutes). Lorsque j'ai remis les bonne correspondances tout est revenu dans l'ordre.
Ton post m'a forcement penser a cela, d'autant plus que nous devons avoir des plateformes de taille similaire...
Sinon pour la bierre, en prochain MoodleMoot à Lyon
Anne
Re: Purges des caches de catégories => gros ralentissements de la plateforme
Bonjour,
Je suis le nouveau responsable du domaine pédagogique de la direction informatique à l'Université de Strasbourg. C'est avec beaucoup d'intérêt que j'ai parcouru ce topic. Nous avons migré de la version 2.x (je ne sais plus laquelle) vers la version 3.0.5 de Moodle en Juin dernier, depuis nous rencontrons de gros ralentissements, pas seulement lors d'une édition de cours mais également lors de passage de tests.
Les memcached ont été mis en place (plugin memcache et non pas memcached, cela fait-il une différence ?) et malgré cela, les performances ne sont absolument pas satisfaisantes (plusieurs minutes de temps de réponse pour des tests dont la durée est limitées n'est pas normal). Je n'ai pas tout compris mais pourriez-vous détailler ce que vous appeler le mappage au niveau des caches ?
Nous fonctionnons avec 5 machines virtuelles (4 CPU et 16 Go de RAM) en load balancer. En monitorant les mémoires des machines on s'aperçoit que régulièrement il y a du flush de la mémoire cached, nous n'avons pas encore isolé la cause.
En tout cas merci pour ce topic, plein d'informations précieuses.
à bientôt
Re: Purges des caches de catégories => gros ralentissements de la plateforme
Désolé pour le retard, je n'avais pas vu ton message.
Concernant la différence entre memcache et memcached, il semble qu'elle ne soit pas significative. D'après ce que j'ai pu lire et entendre, memcache n'est plus développé alors que memcached continue à l'être. J'ai également vu un benchmark qui montre que memcached est un peu plus rapide.
Quand je parle du mappage au niveau des caches, je veux dire que j'ai choisi de mettre certains types de cache en memcached (voir la liste dans mon précédent post) et d'autres en filesystem. Cela se définit dans Administration du site > Plugins > Cache > Configuration.
À mon avis, tu devrais essayer de mettre en place un memcached et de mapper les caches memcache vers le memcached pour voir si cela change quelque chose, peut-être que les dev' ont pris plus de soin sur memcached (j'en sais rien hein, je dis ça comme ça)
Re: Purges des caches de catégories => gros ralentissements de la plateforme
Bonjour Benjamin,
Merci pour ton retour.
Nous allons essayer de mettre en place la solution préconisée. Mais avant nous allons passer nos chat en mode daemon, à priori une autre source de ralentissements si nous avons des chat sur des serveurs chargés.
à bientôt