« Cron » : différence entre les versions

De MoodleDocs
Aller à :navigation, rechercher
(Ajouts utiles (à traduire))
(Traduction terminée)
 
(4 versions intermédiaires par 2 utilisateurs non affichées)
Ligne 1 : Ligne 1 :
{{Traduction}}{{Installation}}Le processus Moodle ''cron'' est un script PHP, partie intégrante de la distribution standard de Moodle, qui '''doit être lancé régulièrement'''. Ce script lance diverses tâches programmées à différents intervalles.
{{Installation}}Le processus Moodle ''cron'' est un script PHP, partie intégrante de la distribution standard de Moodle, qui '''doit être lancé régulièrement'''. Ce script lance diverses tâches programmées à différents intervalles.


'''IMPORTANT ! Ne sautez pas l'étape de configuration du processus cron sur le serveur hébergeant votre installation de Moodle. Votre site ne fonctionnera pas correctement sans lui !'''
'''IMPORTANT ! Ne sautez pas l'étape de configuration du processus cron sur le serveur hébergeant votre installation de Moodle. Votre site ne fonctionnera pas correctement sans lui !'''
Ligne 88 : Ligne 88 :
</table>
</table>


== Debugging Scheduled Tasks ==
== Débogage des Tâches programmées ==
Parfois, une tâches programmées particulière peut ne pas fonctionner correctement. Dans les versions de Moodle antérieures à la 2.7 - toute tâche programmées qui déclenchait des erreurs empêchait le reste du CRON de fonctionner. La seule solution pour vérifier si le CRON arrivait à chaque fois à son terme était d'ajouter un mécanisme de vérification automatique exploitant la sortie du CRON en cours (par exemple, en recherchant la chaîne "Cron terminé à").


Sometimes, a particular cron task may not be working correctly. In Moodle versions before 2.7 - any cron task that was throwing exceptions would prevent the rest of cron from running. The only way to monitor if cron was completing each time, was to add some automated checking of the output of running cron (e.g. searching for the string "Cron completed at ").
Dans Moodle 2.7 et suivants, une seule tâche programmées défaillante n'empêchera plus les tâches restantes de s'achever. Lorsqu'une tâche programmée échoue, elle est marquée comme un échec et programmée pour être réessayée. Si la tâche continue d'échouer, la prochaine tâche programmée sera annulée jusqu'à ce qu'elle soit tentée au maximum une fois toutes les 24 heures. Mais en consultant la page d'administration des [[Tâches programmées]], vous pouvez voir si une tâche est encore en échec (elle aura un délai d'échec non nul ce qui représente le nombre de secondes à attendre avant de réessayer une tâche échouée). Un moyen simple de déboguer une tâche défaillante est de l'exécuter immédiatement en utilisant le [[Administration_en_ligne_de_commande#T.C3.A2ches_programm.C3.A9es|gestionnaire de tâches programmées]] et de surveiller sa sortie.


In Moodle 2.7 and later, a single failing scheduled task will not prevent the remaining tasks from completing. When any single scheduled task fails, it is marked as a failure, and scheduled to be reattempted. If the task keeps failing, the next scheduled time will be backed off until it is attempted at most once every 24 hours. But checking the [[Scheduled tasks]] admin page, you can see if any task is currently failing (it will have a non-zero fail delay - which is the number of seconds to wait before reattempting a failed task). A simple way to debug a failing task, is to run it immediately using the [[Administration via command line#Scheduled_tasks|cli scheduled task runner]] and monitor the output.
== Journalisation et surveillance ==


== Logging and monitoring ==
Idéalement, vous devriez également enregistrer la sortie de cron quelque part et la surveiller pour détecter d'éventuels problèmes. Vous pouvez surveiller l'état général de cron pour vous assurer qu'il n'y a pas d'erreurs en visitant :


Ideally you should also be logging the output of cron somewhere and monitoring it for issues. You can monitor the overall status of cron to make sure there are no errors by visiting:
Administration du site > Rapports > Statut du système (/report/status/index.php)


Site administration / Reports / System status (/report/status/index.php)
Vous pouvez également connecter ce rapport d'état à des outils comme Icinga / Nagios à l'aide de l'API de vérification (https://docs.moodle.org/dev/Check_API) ou à l'aide de plugins comme https://github.com/catalyst/moodle-tool_heartbeat.
 
You can also wire this status report up to tools like Icinga / Nagios using the Check API (https://docs.moodle.org/dev/Check_API) cli commands or with the help of plugins like https://github.com/catalyst/moodle-tool_heartbeat.


<code sh>
<code sh>
Ligne 106 : Ligne 105 :
</code>
</code>


If there are errors then you can get more details for recently run tasks from the Logs column on the Scheduled task page, but this won't show ad hoc task failures:
S'il y a des erreurs, vous pouvez obtenir plus de détails sur les tâches récemment exécutées dans la colonne Journaux de la page Tâche programmées, mais cela n'affichera pas les échecs des tâches ad hoc :


Site administration / Server / Tasks / Scheduled tasks (/admin/tool/task/scheduledtasks.php)
Administration du site > Serveur > Tâches > Tâches programmées (/admin/tool/task/scheduledtasks.php)


To see ad hoc task failures you either need to rerun the task manually yourself and see the errors, or you need to have already collected the logs for review. For a Moodle running on a single box you could log to a simple log file, or for a cluster you might want to use syslogd or similar, e.g.:
Pour voir les échecs de tâches ad hoc, vous devez soit réexécuter la tâche manuellement et voir les erreurs, soit avoir déjà collecté les journaux pour examen. Pour un Moodle exécuté sur un seul serveur, vous pouvez vous connecter à un simple fichier journal, ou pour un cluster, vous pouvez utiliser syslogd ou similaire, par exemple :  


<pre>
<pre>
  * * * * * /usr/bin/php  /path/to/moodle/admin/cli/cron.php 2>&1 | /usr/bin/logger ...
  * * * * * /usr/bin/php  /chemin/vers/moodle/admin/cli/cron.php 2>&1 | /usr/bin/logger ...
</pre>
</pre>


== Low latency adhoc tasks ==
== Lenteurs sur les tâches adhoc==
Chaque fois que le CRON est exécuté, les « tâches ad hoc » sont également exécutées une fois que les tâches programmées sont toutes terminées. Alors que les tâches programmées peuvent être exécutées au maximum une fois par minute, les tâches ad hoc peuvent être mises en file d'attente à tout moment, et généralement, vous souhaitez qu'elles soient traitées le plus rapidement possible et ne pas devoir attendre que les tâches programmées soient exécutées en premier. Si vous n'exécutez que la commande principale admin/cli/cron.php, non seulement il se peut que vous deviez attendre que toutes les tâches programmées se terminent en premier, mais même si elles sont terminées, vous devrez peut-être attendre la minute suivante pour que CRON redémarre afin qu'elle soit traitée.


Each time cron is run, after the scheduled tasks the ad hoc tasks are also run. While scheduled tasks can run at most once a minute, ad hoc tasks can be queued at any moment, and generally you want them processed as soon as possible and to not have to wait for the scheduled task to run first. If you only run the normal admin/cli/cron.php then not only might it have to wait to process all the scheduled tasks first, if it has already finished you will have to wait until the next minute for cron to start again for it to be processed.
Au lieu de cela, vous pouvez utiliser un ou plusieurs processus de « tâches ad hoc » qui fonctionnent en parallèle avec le processus CRON principal.
 
Instead you can run one or more dedicated ad hoc task processors which run in parallel to the main cron process.


Exemple :
<pre>
<pre>
  * * * * * /usr/bin/php  /path/to/moodle/admin/cli/adhoc_task.php --execute --keep-alive=59
  * * * * * /usr/bin/php  /chemin/vers/moodle/admin/cli/adhoc_task.php --execute --keep-alive=59
  * * * * * /usr/bin/php  /path/to/moodle/admin/cli/adhoc_task.php --execute --keep-alive=59
  * * * * * /usr/bin/php  /chemin/vers/moodle/admin/cli/adhoc_task.php --execute --keep-alive=59
...
...
</pre>
</pre>
À partir de Moodle 3.9, l'option ''keep-alive'' ("garder en vie") agit comme un [https://fr.wikipedia.org/wiki/Daemon_(informatique) démon]. Ainsi, lorsque la file d'attente est vide, plutôt que de se terminer, celui-ci attend que de nouvelles tâches soient mises en file d'attente afin de pouvoir commencer le traitement dès que possible.


Starting from Moodle 3.9 the—keep-alive option runs like a daemon so when the queue is empty rather than exiting it waits for new tasks to be queued so it can start processing as soon as possible.
== Montée en charge de cron avec plusieurs processus ==


== Scaling up cron with multiple processes ==
Au fur et à mesure que votre site grandit, de nombreuses tâches programmées prendront plus de temps à s'accomplir, et il y aura également plus de tâches ad hoc en file d'attente qui doivent être traitées. Le système cron est conçu pour fonctionner en parallèle, mais chaque processus individuel ne peut traiter qu'une tâche à la fois, vous devez donc exécuter plusieurs cron cli. Vous pouvez généralement exécuter un nombre assez élevé de processus cron sur une instance cron dédiée avant de devoir exécuter plusieurs instances cron. Pour exécuter plusieurs processus, générez simplement plusieurs processus cron chaque minute :


As your site grows many of the scheduled tasks will take longer to complete, and also there will be more ad hoc tasks queued which need to be processed. The cron system is designed to work in parallel but each individual process can only process one task at a time so you must run multiple cron cli's. You can generally run a fairly high number of cron processes on a dedicated cron instance before needing to run multiple cron instances. To run more than one process simply spawn multiple cron processes each minute:
<pre>
 
  * * * * * /usr/bin/php  /chemin/vers/moodle/admin/cli/cron.php
<code>
  * * * * * /usr/bin/php  /chemin/vers/moodle/admin/cli/cron.php
  * * * * * /usr/bin/php  /path/to/moodle/admin/cli/cron.php
  * * * * * /usr/bin/php  /chemin/vers/moodle/admin/cli/cron.php
  * * * * * /usr/bin/php  /path/to/moodle/admin/cli/cron.php
  * * * * * /usr/bin/php  /path/to/moodle/admin/cli/cron.php
...
...
  * * * * * /usr/bin/php  /path/to/moodle/admin/cli/adhoc_task.php --execute --keep-alive=59
  * * * * * /usr/bin/php  /chemin/vers/moodle/admin/cli/adhoc_task.php --execute --keep-alive=59
  * * * * * /usr/bin/php  /path/to/moodle/admin/cli/adhoc_task.php --execute --keep-alive=59
  * * * * * /usr/bin/php  /chemin/vers/moodle/admin/cli/adhoc_task.php --execute --keep-alive=59
  * * * * * /usr/bin/php  /path/to/moodle/admin/cli/adhoc_task.php --execute --keep-alive=59
  * * * * * /usr/bin/php  /chemin/vers/moodle/admin/cli/adhoc_task.php --execute --keep-alive=59
...
...
</code>
</pre>
 
Il peut être particulièrement important d'augmenter le nombre de processus adhoc_task.php car certains plugins et systèmes peuvent générer un très grand nombre de tâches ad hoc, ou des tâches qui peuvent prendre beaucoup de temps à traiter. En particulier, les tâches telles que les conversions de documents et les sauvegardes automatiques peuvent s'accumuler plus rapidement qu'elles ne sont traitées si elles sont laissées sur les paramètres par défaut.
 
Par défaut, seules 3 tâches programmées et 3 tâches ad hoc peuvent être exécutées simultanément, de sorte que lorsque vous ajoutez plus de processus, vous devez augmenter le niveau de simultanéité autorisé :


It can be especially important to increase the number of adhoc_task.php processes as certain plugins and systems can generate very large numbers of ad hoc tasks, or tasks that can take a long time to process. Especially tasks like document conversions and automated backups can build up more quickly than they are processed if they are left on default settings.
Administration du site > Serveur > Tâches > Traitement des tâches


By default only 3 scheduled tasks and 3 ad hoc tasks can be run concurrently so as you add more processes you need to increase the level of allowed concurrency:
Ou dans <code>config.php</code> :


Site administration > Server > Tasks > Task processing
<syntaxhighlight lang="php">
$CFG->task_scheduled_concurrency_limit = 20; // Défaut à 3
$CFG->task_adhoc_concurrency_limit    = 50; // Défaut à 3
</syntaxhighlight>


<code php>
Quoi que vous définissiez, assurez-vous que le ou les serveurs qui les hébergent peuvent gérer confortablement ces nombreux processus. Souvent, le goulot d'étranglement sera un service partagé, généralement la base de données.
config.php:
$CFG->task_scheduled_concurrency_limit = 20; // Defaults to 3
$CFG->task_adhoc_concurrency_limit = 50;  // Defaults to 3
</code>


Whatever you set these too make sure the server(s) hosting them can comfortably handle this many processes. Often the bottleneck will be a shared service, usually the database.
Vous pouvez constater que certains types de tâches très longues consomment tous les processus de tâches disponibles, ce qui signifie qu'aucune autre tâche ne s'exécutera. Par exemple, si vous avez 5 processus cli, mais que la file d'attente des tâches comporte 20 tâches ad hoc de sauvegarde automatique, dont chacune prendra dix minutes, alors très rapidement les 5 processus seront consommés par les sauvegardes et rien d'autre. D'autres petites tâches très rapides et légères comme une conversion de document ou des courriels de forum ne seront pas exécutées tant que les sauvegardes ne seront pas terminées et qu'un processus ne sera pas libéré. Pour gérer cela, vous pouvez limiter la simultanéité de types spécifiques de tâches ad hoc. Une bonne règle de base est que si toutes les tâches « lourdes » consomment toutes leurs propres limites, vous devriez encore avoir quelques autres processus en attente pour tout ce qui peut être ajouté à la file d’attente.


You may find that certain types of very long running tasks will consume all the available task processes which means no other tasks will run. e.g. if you have 5 cli processes, but in the task queue there are 20 ad hoc tasks for an automated backup, each of which will take ten minutes to complete, then very quickly all 5 processes will be consumed by backups and nothing else. Other small very fast and light tasks like a document conversion or forum emails will not get sent until the backups are complete and a process frees up. To manage this you can limit the concurrency of specific types of ad hoc tasks. A good rule of thumb is that if all of the 'heavy' tasks consume all of their own limits then you should still have another few processes standing by on idle waiting for anything else which may be added to the queue.
Les sauvegardes automatiques sont le pire contrevenant connu, donc hypothétiquement si vous exécutez 50 processus de tâches ad hoc simultanément, une restriction raisonnable pourrait être de limiter les sauvegardes pour qu'elles ne consomment pas plus de la moitié de ces processus, c'est-à-dire 25 au maximum :


Automated backups are the worst known offender, so hypothetically if you are running 50 ad hoc task processes concurrently a reasonable restriction might be to cap the backups to consume no more than half of those processes, ie 25 at most:
Dans <code>config.php</code> :


<code php>
<syntaxhighlight lang="php">
config.php:
$CFG->task_concurrency_limit = [
$CFG->task_concurrency_limit = [
     'core\task\course_backup_task' => 25,
     'core\task\course_backup_task'           => 25,
     'core_course\task\course_delete_modules' => 5,
     'core_course\task\course_delete_modules' => 5,
];
];
</code>
</syntaxhighlight>


== Voir aussi ==
== Voir aussi ==

Dernière version du 17 septembre 2021 à 11:23

Le processus Moodle cron est un script PHP, partie intégrante de la distribution standard de Moodle, qui doit être lancé régulièrement. Ce script lance diverses tâches programmées à différents intervalles.

IMPORTANT ! Ne sautez pas l'étape de configuration du processus cron sur le serveur hébergeant votre installation de Moodle. Votre site ne fonctionnera pas correctement sans lui !

Il est recommandé de lancer le cron à une fréquence d'une fois par minute, comme cela est requis pour la suppression synchrone des activités lors de l'utilisation de la corbeille.

Le programme cron (qui lance le script cron de Moodle) fait partie de façon standard des systèmes Unix (y compris Linux et macOS) et est utilisé pour lancer toutes sortes de services dépendant de l'heure. Sous Windows, la solution la plus simple pour répliquer ce comportement est de créer une tâche dans le Gestionnaire des tâches Windows et de la faire lancer à intervalles réguliers. Sur les serveurs mutualisés, il vous faudra trouver la documentation (ou demander de l'assistance) sur la façon de configurer le cron. La plupart des serveurs mutualisés offrent CPanel pour gérer les sites, et auront donc une section pour configurer les tâches Cron sur le panneau de configuration.

Normalement, pour configurer le cron, il s'agit d'ajouter une unique commande à la liste des activités du cron déjà existantes sur votre système. Sur les systèmes Unix, cette liste est contenue dans le fichier dénommé crontab, propre à chaque utilisateur.

Discussion générale

Ce paragraphe détaille diverses informations de base. Voyez plus loin pour des instructions propres à votre type de serveur.

Deux étapes sont essentielles pour faire fonctionner le cron :

  1. identifier la commande correcte à lancer, et
  2. trouver le bon endroit où indiquer cette commande sur votre système.

Comprendre le script cron de Moodle

Moodle a deux façons différentes de déployer le cron, qui utilisent deux scripts différents de l'installation de Moodle.

  1. Le script CLI (command line interpreter = interface en ligne de commande). Ce script se trouve ici :
    /chemin/de/moodle/admin/cli/cron.php
    Si vous ne savez pas que faire, c'est ce script que vous devez utiliser. Il nécessite d'être lancé sur votre serveur par PHP en ligne de commande. La commande à lancer ressemblera donc à quelque chose comme
    /usr/bin/php /chemin/de/moodle/admin/cli/cron.php
    Vous pouvez (et devez) tester cette commande à la main pour voir si elle fonctionne. Attention ! Vérifiez que la version de PHP en ligne de commande est compatible avec votre version de Moodle. Le programme PHP en ligne de commande est différent de celui utilisé par le serveur web et n'est pas toujours à la même version.
  2. Si pour une raison ou une autre vous ne pouvez pas lancer le script CLI, vous pouvez utiliser le script web. Ce script est lancé depuis un navigateur web en chargeant une URL qui ressemble à celle-ci : http://mon.site-moodle.fr/admin/cron.php. On peut utiliser pour cela un navigateur web en ligne de commande (par exemple wget), et la commande à lancer ressemblera donc à quelque chose comme
    /usr/bin/wget http://mon.site-moodle.fr/admin/cron.php
    Cette méthode a l'avantage de pouvoir être lacée *depuis n'importe où*. Si vous n'arrivez pas à configurer le cron sur votre serveur, vous pouvez ainsi le lancer depuis une autre machine.

Trouver l'emplacement où indiquer la commande

Cette étape dépend du serveur que vous utilisez. Il vous faut donc lire la documentation de votre plateforme ou de votre hébergeur. La plupart du temps, mettre en place le cron de Moodle consiste à déterminer la bonne commande à lancer (voir ci-dessus) et à l'ajouter, avec l'horaire adéquat, à un fichier prévu pour cela, soit en le modifiant directement, soit via une interface spécifique.

Si vous utilisez le script CLI, vous devez également vous assurer que le processus cron est lancé avec le bon utilisateur. Il n'est en revanche pas nécessaire de s'en soucier avec la version web.

Exemple : installation du cron sur Linux Ubuntu/Debian. On suppose que l'utilisateur est connecté en tant que root.

Utiliser la commande crontab pour ouvrir la fenêtre de l'éditeur de crontab pour l'utilisateur www-data. Il s'agit de l'utilisateur qui possède le processus Apache (le serveur web) sur les serveurs Debian

$ crontab -u www-data -e

Cette commande ouvre la fenêtre de l'éditeur. Pour configurer le script cron de sorte à le lancer toutes les minutes, ajouter la ligne :

*/1 * * * * /usr/bin/php  /chemin/de/moodle/admin/cli/cron.php >/dev/null

Remarque : la fin de la commande >/dev/null envoie à la poubelle la sortie de la commande et évite que vous receviez un courriel toutes les minutes.

Mettre en place le cron sur votre système

Suivant le type de votre serveur :

Voici des instructions supplémentaires pour des hébergeurs spécifiques (vérifiez qu'elle sont bien à jour) :

Utilisation de services cron tiers

Au lieu d'utiliser votre propre serveur pour lancer le cron, vous pouvez utiliser un service tiers (appelé parfois webcron) :

  • cron-job.org - un service gratuit (le cron toutes les minutes est possible).
  • EasyCron - un fournisseur de cron sur le web qui permet de se passer d'un crontab pour lancer les tâches cron.

Réglages du cron dans Moodle

Certains réglages de Moodle permettent de contrôler divers aspects de l’opération cron :

  • Réglages du cron - Réglages du mot de passe du processus cron et du script cron en ligne de commande.

Nouveauté
Moodle
2.7

Cron depuis Moodle 2.7

Le cron a été modifié de manière majeure dans Moodle 2.7, et permet l'exécution de tâches programmées et ad hoc (voir MDL-25499). Les bénéfices de ces changements sont les suivants :

  • la programmation de chaque tâche peut être configurée par l'administrateur. Voir Tâches programmées ;
  • les tâches peuvent tourner en parallèle ;
  • les processus cron utilisent des verrous pour éviter qu'une tâche soit lancée simultanément par des processus différents.

En conséquence, le cron peut être lancé de manière beaucoup plus fréquente (sans risque de blocage), ce qui permet par exemple d'envoyer les messages des forums plus tôt. Il est recommandé de l'adapter à une fréquence d'une fois par minute.

Cron distant

L'utilisation de la version web du cron permet de lancer le cron depuis une machine différente de votre serveur Moodle. Par exemple, on pourra utiliser le cron d'une machine Unix pour lancer la version web du cron d'un Moodle installé sur un serveur Windows. Il faudra que l'utilisation via le web soit autorisée.

Pour savoir si le cron a bien été lancé récemment, il suffit de vous rendre avec un compte administrateur à l'adresse : http://mon.moodle/admin/index.php, ou en passant par « Administration du site > Notifications ».

cron OK.jpg   cron pas OK.jpg
Le cron a bien été lancé
(Attention : la date indiquée concerne la recherche des mises à jour !)
   Le cron n'a pas été exécuté depuis au moins 24 heures, voire...
n'a jamais été lancé !

Débogage des Tâches programmées

Parfois, une tâches programmées particulière peut ne pas fonctionner correctement. Dans les versions de Moodle antérieures à la 2.7 - toute tâche programmées qui déclenchait des erreurs empêchait le reste du CRON de fonctionner. La seule solution pour vérifier si le CRON arrivait à chaque fois à son terme était d'ajouter un mécanisme de vérification automatique exploitant la sortie du CRON en cours (par exemple, en recherchant la chaîne "Cron terminé à").

Dans Moodle 2.7 et suivants, une seule tâche programmées défaillante n'empêchera plus les tâches restantes de s'achever. Lorsqu'une tâche programmée échoue, elle est marquée comme un échec et programmée pour être réessayée. Si la tâche continue d'échouer, la prochaine tâche programmée sera annulée jusqu'à ce qu'elle soit tentée au maximum une fois toutes les 24 heures. Mais en consultant la page d'administration des Tâches programmées, vous pouvez voir si une tâche est encore en échec (elle aura un délai d'échec non nul ce qui représente le nombre de secondes à attendre avant de réessayer une tâche échouée). Un moyen simple de déboguer une tâche défaillante est de l'exécuter immédiatement en utilisant le gestionnaire de tâches programmées et de surveiller sa sortie.

Journalisation et surveillance

Idéalement, vous devriez également enregistrer la sortie de cron quelque part et la surveiller pour détecter d'éventuels problèmes. Vous pouvez surveiller l'état général de cron pour vous assurer qu'il n'y a pas d'erreurs en visitant :

Administration du site > Rapports > Statut du système (/report/status/index.php)

Vous pouvez également connecter ce rapport d'état à des outils comme Icinga / Nagios à l'aide de l'API de vérification (https://docs.moodle.org/dev/Check_API) ou à l'aide de plugins comme https://github.com/catalyst/moodle-tool_heartbeat.

/admin/cli/checks.php

S'il y a des erreurs, vous pouvez obtenir plus de détails sur les tâches récemment exécutées dans la colonne Journaux de la page Tâche programmées, mais cela n'affichera pas les échecs des tâches ad hoc :

Administration du site > Serveur > Tâches > Tâches programmées (/admin/tool/task/scheduledtasks.php)

Pour voir les échecs de tâches ad hoc, vous devez soit réexécuter la tâche manuellement et voir les erreurs, soit avoir déjà collecté les journaux pour examen. Pour un Moodle exécuté sur un seul serveur, vous pouvez vous connecter à un simple fichier journal, ou pour un cluster, vous pouvez utiliser syslogd ou similaire, par exemple :

 * * * * * /usr/bin/php  /chemin/vers/moodle/admin/cli/cron.php 2>&1 | /usr/bin/logger ...

Lenteurs sur les tâches adhoc

Chaque fois que le CRON est exécuté, les « tâches ad hoc » sont également exécutées une fois que les tâches programmées sont toutes terminées. Alors que les tâches programmées peuvent être exécutées au maximum une fois par minute, les tâches ad hoc peuvent être mises en file d'attente à tout moment, et généralement, vous souhaitez qu'elles soient traitées le plus rapidement possible et ne pas devoir attendre que les tâches programmées soient exécutées en premier. Si vous n'exécutez que la commande principale admin/cli/cron.php, non seulement il se peut que vous deviez attendre que toutes les tâches programmées se terminent en premier, mais même si elles sont terminées, vous devrez peut-être attendre la minute suivante pour que CRON redémarre afin qu'elle soit traitée.

Au lieu de cela, vous pouvez utiliser un ou plusieurs processus de « tâches ad hoc » qui fonctionnent en parallèle avec le processus CRON principal.

Exemple :

 * * * * * /usr/bin/php  /chemin/vers/moodle/admin/cli/adhoc_task.php --execute --keep-alive=59
 * * * * * /usr/bin/php  /chemin/vers/moodle/admin/cli/adhoc_task.php --execute --keep-alive=59
...

À partir de Moodle 3.9, l'option keep-alive ("garder en vie") agit comme un démon. Ainsi, lorsque la file d'attente est vide, plutôt que de se terminer, celui-ci attend que de nouvelles tâches soient mises en file d'attente afin de pouvoir commencer le traitement dès que possible.

Montée en charge de cron avec plusieurs processus

Au fur et à mesure que votre site grandit, de nombreuses tâches programmées prendront plus de temps à s'accomplir, et il y aura également plus de tâches ad hoc en file d'attente qui doivent être traitées. Le système cron est conçu pour fonctionner en parallèle, mais chaque processus individuel ne peut traiter qu'une tâche à la fois, vous devez donc exécuter plusieurs cron cli. Vous pouvez généralement exécuter un nombre assez élevé de processus cron sur une instance cron dédiée avant de devoir exécuter plusieurs instances cron. Pour exécuter plusieurs processus, générez simplement plusieurs processus cron chaque minute :

 * * * * * /usr/bin/php  /chemin/vers/moodle/admin/cli/cron.php
 * * * * * /usr/bin/php  /chemin/vers/moodle/admin/cli/cron.php
 * * * * * /usr/bin/php  /chemin/vers/moodle/admin/cli/cron.php
...
 * * * * * /usr/bin/php  /chemin/vers/moodle/admin/cli/adhoc_task.php --execute --keep-alive=59
 * * * * * /usr/bin/php  /chemin/vers/moodle/admin/cli/adhoc_task.php --execute --keep-alive=59
 * * * * * /usr/bin/php  /chemin/vers/moodle/admin/cli/adhoc_task.php --execute --keep-alive=59
...

Il peut être particulièrement important d'augmenter le nombre de processus adhoc_task.php car certains plugins et systèmes peuvent générer un très grand nombre de tâches ad hoc, ou des tâches qui peuvent prendre beaucoup de temps à traiter. En particulier, les tâches telles que les conversions de documents et les sauvegardes automatiques peuvent s'accumuler plus rapidement qu'elles ne sont traitées si elles sont laissées sur les paramètres par défaut.

Par défaut, seules 3 tâches programmées et 3 tâches ad hoc peuvent être exécutées simultanément, de sorte que lorsque vous ajoutez plus de processus, vous devez augmenter le niveau de simultanéité autorisé :

Administration du site > Serveur > Tâches > Traitement des tâches

Ou dans config.php :

$CFG->task_scheduled_concurrency_limit = 20; // Défaut à 3
$CFG->task_adhoc_concurrency_limit     = 50; // Défaut à 3

Quoi que vous définissiez, assurez-vous que le ou les serveurs qui les hébergent peuvent gérer confortablement ces nombreux processus. Souvent, le goulot d'étranglement sera un service partagé, généralement la base de données.

Vous pouvez constater que certains types de tâches très longues consomment tous les processus de tâches disponibles, ce qui signifie qu'aucune autre tâche ne s'exécutera. Par exemple, si vous avez 5 processus cli, mais que la file d'attente des tâches comporte 20 tâches ad hoc de sauvegarde automatique, dont chacune prendra dix minutes, alors très rapidement les 5 processus seront consommés par les sauvegardes et rien d'autre. D'autres petites tâches très rapides et légères comme une conversion de document ou des courriels de forum ne seront pas exécutées tant que les sauvegardes ne seront pas terminées et qu'un processus ne sera pas libéré. Pour gérer cela, vous pouvez limiter la simultanéité de types spécifiques de tâches ad hoc. Une bonne règle de base est que si toutes les tâches « lourdes » consomment toutes leurs propres limites, vous devriez encore avoir quelques autres processus en attente pour tout ce qui peut être ajouté à la file d’attente.

Les sauvegardes automatiques sont le pire contrevenant connu, donc hypothétiquement si vous exécutez 50 processus de tâches ad hoc simultanément, une restriction raisonnable pourrait être de limiter les sauvegardes pour qu'elles ne consomment pas plus de la moitié de ces processus, c'est-à-dire 25 au maximum :

Dans config.php :

$CFG->task_concurrency_limit = [
    'core\task\course_backup_task'           => 25,
    'core_course\task\course_delete_modules' =>  5,
];

Voir aussi

Discussions sur les forums d'assistance Moodle (en anglais) :