Development #38159
caler le déclenchement des jobs "jump" sur le déclenchement des jobs "hourly"
0%
Description
Pour les jobs hourly on fait :
if hourly: # set minutes to an arbitrary value based on installation, this # prevents waking up all jobs at the same time on a server farm. self.minutes = [ord(settings.SECRET_KEY[-1]) % 60]
et pour les jobs "jump" :
JUMP_TIMEOUT_INTERVAL = 3 # la plupart du temps ... CronJob(_apply_timeouts, name='evaluate_jumps', hours=range(24), minutes=range(0, 60, JUMP_TIMEOUT_INTERVAL)))
Mais sur une installation un peu chargée, à h0, h20, h40, pour les jumps, le temps passé peut allègrement dépasser la minute, et du coup, si les jobs "hourly" sont à h1, ils passent à la trappe. (et en hourly on a le job d'évaluation des actions globales)
J'aurais du coup comme proposition de caler le apply_timeout pour s'enclencher sur la même minute que le hourly.
Fichiers
Révisions associées
Historique
Mis à jour par Frédéric Péters il y a plus de 4 ans
- Fichier 0001-misc-align-jump-checks-with-the-hourly-cron-jobs-381.patch 0001-misc-align-jump-checks-with-the-hourly-cron-jobs-381.patch ajouté
- Statut changé de Nouveau à Solution proposée
- Patch proposed changé de Non à Oui
En bonus l'alignement de l'envoi des messages d'aggrégation (qu'on n'utilise jamais, mais qui déclenchés exclusivement à 06:00 auraient désormais pu passer à la trappe vu que les sauts ne sont plus à h00.
Mis à jour par Thomas Noël il y a plus de 4 ans
Mais ne faut-il pas alors aligner tous les cron_jobs avec un minutes= fixe ?
Genre ici :
wcs/formdef.py: get_publisher_class().register_cronjob(CronJob(clean_drafts, wcs/formdef.py- name='clean_drafts', wcs/formdef.py- days=[2], hours=[0], minutes=[0])) wcs/formdef.py- # once a day, look for unused files wcs/formdef.py: get_publisher_class().register_cronjob(CronJob(clean_unused_files, wcs/formdef.py- name='clean_unused_files', wcs/formdef.py- hours=[2], minutes=[0]))
On ajouterait donc ici un hourly=True, comme pour les messages d'aggregation.
Et sur les sessions et les nonces, passer en mode "ord(settings.SECRET_KEY[-1]) % 60") ici :
wcs/qommon/publisher.py: cls.register_cronjob(CronJob(cls.clean_sessions, minutes=range(0, 60, 5))) wcs/qommon/publisher.py: cls.register_cronjob(CronJob(cls.clean_nonces, minutes=range(0, 60, 5)))
Sans oublier, même si ça ne compte pas en Publik (saml) :
wcs/qommon/ident/password.py: CronJob(handle_unused_accounts, minutes=[0], hours=[6])) wcs/qommon/ident/password.py: CronJob(handle_expired_tokens, minutes=[10], hours=[6]))
Mis à jour par Frédéric Péters il y a plus de 4 ans
- Fichier 0001-misc-align-jump-checks-with-the-hourly-cron-jobs-381.patch 0001-misc-align-jump-checks-with-the-hourly-cron-jobs-381.patch ajouté
On ajouterait donc ici un hourly=True, comme pour les messages d'aggregation.
Ceux-là, oui.
Et sur les sessions et les nonces, passer en mode "ord(settings.SECRET_KEY[-1]) % 60") ici :
Ici je dirais que c'est inutile, c'est appelé suffisamment souvent, pas besoin de se caler pile.
Sans oublier, même si ça ne compte pas en Publik (saml) :
Ici pareil un hourly, mais oui inutile.
~~
Patch revu et j'ai décidé de garder minutes=[0] même quand j'ai ajouté hourly, en prenant ainsi, malgré son nom, hourly comme un paramètre altérant les minutes, plutôt qu'un vrai truc qui dirait toutes les heures.
Mis à jour par Thomas Noël il y a plus de 4 ans
- Statut changé de Solution proposée à Solution validée
Impec.
Et j'avais oublié de dire : good catch.
(À un moment il faudra quand même je me replonge dans une gestion des cron plus intelligente, notamment avec copain systemd)
Mis à jour par Frédéric Péters il y a plus de 4 ans
- Statut changé de Solution validée à Résolu (à déployer)
commit 6a549fb0533add08efdcfac3b22a50786e678476 Author: Frédéric Péters <fpeters@entrouvert.com> Date: Tue Dec 3 13:36:27 2019 +0100 misc: align jump checks with the "hourly" cron jobs (#38159)
Mis à jour par Frédéric Péters il y a plus de 4 ans
- Statut changé de Résolu (à déployer) à Solution déployée
misc: align jump checks with the "hourly" cron jobs (#38159)