#delayed_job

[suisui-tech]

Sharetribe Version: 6.1.0 Environment: Ubuntu 14.04 The Problem After running bundle exec rake jobs:work This delay job would slowly take up all the memory the server have, and cause server down. I...

[suisui-tech]

I am using delayed_job and moved to a new beefier server. So now I would like to run parallel jobs, as now I have the POWER!, but am confused on whether delayed_job can run multiple parallel queue...

[suisui-tech]

delayed_job_active_record - ActiveRecord backend integration for DelayedJob 3.0+

PostgreSQL 8.4 だと UPDATE のサブクエリが使えないのでノーマルな方法(ただし遅い)でジョブのロックをします。

Problems locking jobs

You can try using the legacy locking code. It is usually slower but works better for certain people.

Delayed::Backend::ActiveRecord.configuration.reserve_sql_strategy = :default_sql

[suisui-tech]

Although #32 fixed issues with PostgreSQL it still does not work with PostgreSQL 8.4, which for example ships with RHEL 6. Error: $ rake jobs:work --trace [Worker(host:foo.localdomain pid:8232)] ...

brauliobo added a commit to CIRANDAS/noosfero-ecosol that referenced this issue on 1 Dec 2014 Downgrade delayed_job_active_record to version 0.3.3 to fix issue 33 … collectiveidea/delayed_job_active_record#33

[aritylabs]

Détourner DelayedJobs pour exécuter des tâches répétitives

À mesure que votre application se complexifie, le besoin d'exécuter des tâches répétitives finit toujours par se faire sentir. C'est généralement des besoins fonctionnels qui exigent ce genre de tâches (envoi de rapports périodiques, de rappels d'expiration prochaine, etc.) mais c'est souvent des soucis de performances qui mènent à effectuer des calculs et des traitements par lots périodiques.

En Ruby, DelayedJob est l'outil le plus populaire pour exécuter des tâches de fond. Nous verrons dans cet article comment l'exploiter au mieux pour programmer l'exécution de tâches répétitives.

Quelles alternatives ?

Rails ne propose aucun mécanisme pour exécuter du code à un instant t. Il est vrai que le code de l'application est chargé en mémoire, mais ce code demeure dormant jusqu'à ce que l'instance de votre application soit invoquée ou forkée par l'arrivée d'une requête HTTP.

Le plus simple moyen d'exécuter du code de façon périodique est de créer une tâche rake et programmer l'exécution de celle-là via le crontab du système, mais cette approche a plusieurs inconvénients :

Prévilèges système : devoir avoir accès à l'édition de crontab, qui passe par une session ssh, voir des droits root selon la configuration de votre intégration Rails avec le serveur Web.

Lenteur : l'exécution d'une rake task requiert généralement le rechargement quasi complet du code de votre application et de ses dépendances (gems). Si votre application contient beaucoup de code, ce temps de chargement peut atteindre des dizaines de secondes. Compromettant si votre application doit s'exécuter à des intervalles rapprochés.

Régidité : le timing d'exécution des tâches est écrit en dur dans le fichier crontab et ne peut donc pas être changé dynamiquement sur votre application. 

Dispersion de l'information : le timing d'exécution de votre code est une information qui sort de votre application. Elle n'est pas versionnée et peut se perdre.

Pourquoi DelayedJob ?

Delayed Job fonctionne en faisant tourner des workers qui vérifient continuellement dans la table delayed_jobs l'existence de tâches en attente et dont la date d'exécution est arrivée.

C'est cette mécanique bien huilée que nous exploiterons.

Réalisation

Le modèle central de delayed_job est Delayed::Job. Créons à notre tour Delayed::Cron dont hériteront tous les jobs qui devront être exécutés périodiquement. De cette manière : 

CODE 1

CODE 2

Rien de vraiment spécial, si ce n'est que FunnyJob utilise comme méthode macro la méthode de classe every qu'elle hérite de Delayed::Cron.

Maintenant, enregistrons ces paramètres dans une classe dédiée et élaborons la logique qui permet de calculer le prochain délai d'exécution de la tâche : 

CODE 3

params_list.rb

next_term.rb

La classe ParamsList enregistre le paramétrage du cron et le complète avec des paramètres par défaut (ligne 23). NextTerm calcule quant à elle le prochain délai d'exécution en devinant la date la plus proche et en s'assurant via la méthode futur! (ligne 17) que cette date n'est pas passée.

Planifions tout cela !

L'idée est de s'assurer que chaque cron planifie la prochaine exécution, même en cas d'échec (voir le ensure lignes 7 et 8)

cron.rb

Delayed Jobs exécute la méthode perform des jobs passés à Delayed::Job.enqueue. Le code qui utilise les crons doit concentrer sa logique dans la méthode perform_cron qui sera à son tour appelée par perform.

À la planification, nous nous assurons qu'aucune tâche planifiée n'a été dédoublée. Si c'est le cas, clean_up se charge de supprimer les improbables doublons.

Renforcer la sécurité en chargeant les crons au démarrage

S'il arrive un pépin au moment de l'exécution du bloc ensure ou si l'échec de l'exécution du job fait crasher tout le worker, la chaine est brisée et une intervention manuelle sera nécessaire pour la rétablir. C'est pourquoi nous exécuterons la méthode schedule de tous les jobs au chargement de l'environnement de l'application, qui survient également au démarrage des workers et autres consoles ou rake tasks.

cron.rb

Nous avons ajouté deux méthodes de classe à Delayed::Cron. Nous pouvons passer à load une liste de classes à surveiller au démarrage de l'environnement.

Ou appeler load_all qui charge toutes les classes présentes dans le dossier app/crons. Ce dossier peut être personnalisé dans l'unique paramètre que prend cette méthode. Load_all ajoute ce dossier aux chemins d'autoload de l'application (ligne 46).

Notons à la ligne 40 l'utilisation de logger.silence qui empêche l'application de journaliser tout cela. Le démarrage de l'application en mode console (rails c) ne sera donc pas pollué.

Ces appels se font idéalement dans un initializer (exemple : config/initializers/delayed_crons.rb

delayed_crons.rb

Conserver les crons qui échouent sans les rééxécuter

Delayed Jobs permet de conserver les jobs qui fail mais ne donne pas la possibilité de choisir lesquels. Ils sont soit tous retenus soit tous supprimés suivant le paramètre global Delayed::Worker.destroy_failed_jobs = true|false.

Nous devons donc ruser pour conserver, pour des raisons de débogage, les crons qui échouent, mais nous ne pouvons pas leur permettre de s'exécuter d'autres fois. Leurs échéances auront passé et ils risquent de perturber ou dédoubler les prochaines exécutions.

config.rb

config.rb

Nous permettons (en théorie) au cron de s'exécuter deux fois, sauf que la deuxième exécution n'aura pas lieu de sitôt ! Si quelqu'un trouve une idée plus propre qu'il nous en fait part.

Et pourquoi pas la syntaxe `cron` ?

Nous ne pouvons évidemment parler de crons sans leur célèbre syntaxe étoilée (!) : mm hh jj MMM JJJ (minutes, heures, jour du mois, mois et jour de semaine). Essayons de rendre possible une telle utilisation :

config.rb

Dans cette implémentation, la classe CronFormat parse la fameuse chaine étoilée et devine la fréquence adéquate et les paramètres nécessaires. :

cron_format.rb

params_list.rb

Worker dédié

Si vous en avez la possibilité, reservez au moins un worker DelayedJob à la queue `delayed_crons`.

Le worker dédié pourra être lancé de cette manière, à partir de vos tâches Capistrano, vos pillules bluepill ou autre !

delayed_job -i 1 --queue=delayed_crons start

Conclusion

Dans cet article, nous avons étudié l'approche globale de l'exploitation de DelayedJobs pour effectuer des tâches répétitives. Nous planifions la prochaine exécution d'une tâche à chaque exécution et — en backup — à chaque lancement de l'environnement.

L'implémentation est toutefois très optimiste quant aux paramètres passés à every. Charge à vous de la peaufiner en ajoutant les validations nécessaires ! ;)

[bdarfler]

Background tasks are hard

[aawaara]

Break it down!

Wiser people have said - if you have a problem, break it down! If the problem is bigger, break it down further. This is true both philosophically and technologically.

I'll describe a technological incident here in the hope that it could help someone else as well (when they land in this tricky situation, and are looking for a quick resolution). We use delayed_job gem in our web apps for asynchronous processing. It has performed pretty well for us all this while, but one fine day it caved in. We had a barrage of jobs into the dealyed_job table, and the job processing daemons were just unbearably slow. The reason being that there were 600K jobs in the queue, and the rate at which dealyed_job daemons fire the mysql queries every 5 seconds was too much I/O for the database server. Soon the slow query logs were flooded with update queries. I tried building a few indexes to speed up some of those queries, but the improvements weren't significant enough. What now? I filed a bug on the github repo in hope of greater good for future users, but that wasn't sufficient enough. Those jobs in the queue were time sensitive in nature, and at the current speed would take days, if not weeks to clear out. We needed a quick fix now, and a long term fix (better solution as compared to delayed_job) later.

Solution (quick fix): I went back in time and realized that delayed_job had performed well for a few thousand jobs in the table. That's it - we needed to pause, and break it down a bit - in this case, the mysql table. So we copied all the data from delayed_jobs table to a new table (backlog_jobs) and cleared the original table (the delayed_job table from where the jobs are picked). Then we copied the first 5000 jobs from backlog_jobs to delayed_jobs and deleted them from backlog_jobs. They were processed pretty quickly in a matter of minutes. Wallah! This was it. Then we wrote a small cron than runs every 1 minute and checks the count of delayed_jobs table. If there are less than 100 rows, it repeats the process, i.e. copies the next batch of 5000 jobs, and deletes it from backup_jobs. This way I got back to the older performance levels. Below are some handy queries that you will find useful:

# To create a copy of table CREATE table backlog_jobs like delayed_jobs; INSERT into backlog_jobs (SELECT * from delayed_jobs); DELETE from delayed_jobs;

# To copy jobs in batches INSERT into delayed_jobs (SELECT * from backlog_jobs order by id asc limit 5000); DELETE from backlog_jobs order by id asc limit 5000;

So the next time you face database related issues, break it down a bit. That's what database partitioning is all about, and that is what everything finally comes down to ;)

Would like to hear what I may have done wrong to start with, and what I could have done better. Don't hesitate to teach me a lesson (pun intended)... :P Philosophically speaking, life is an eternal learning process ;)

[kares]

Delayed Job the Java Way

On the Rails side, we all know Delayed::Job the (probably most popular) background job eater. We've learned how to run it rake jobs:work, live with it RAILS_ENV=production script/delayed_job start and sometimes even kill -S KILL it. The beauty of Delayed::Job comes from it's simplicity, the only nuisance being the need to manage a separate process that handles the jobs, besides just booting your application. So, let's suppose you've decided to go with JRuby on production. Sooner or later you'll discover that it's not going to be a simple interpreter switch, especially with workers such as Delayed::Job, as gems such as daemons do not play well on the Java side. You may even review all of the precious code, to make sure JRuby benefits from threadsafe! just to find out that you need to stick with the "old" Ruby to spawn a delayed daemon. Well, good news, it doesn't have to necessary be that way, after all:

"JRuby is like the Matrix, only there's no spoon or fork()."

Funny but actually true, the JVM was designed to abstract away (sometimes too much) from the OS. If you ask a Java developer to built an asynchronously worker that polls and executes new tasks as they arrive, he'll immediately write a sort of new Thread() { ... }.start() code (or he starts configuring JMS :)). The point is that Java is a notoriously Thread oriented platform. And while using JRuby on Rails you might take advantage of it while running (asynchronous) job workers. First thing you should understand is that there's a Servlet API that is the base of every Java web server you'll find (very similar to what Rack is for all Ruby servers these days). On top of it there's an adapter, most servlet containers use, when serving Rack based applications called jruby-rack. And at last, knowing all the pieces, there's jruby-rack-worker that takes some worker code and runs it in a separate thread along side your application serving requests. The only downside is that one needs to make sure the worker loop plays by the rules in a multi-thread environment. Luckily, this is fairly easy and already handled for Delayed::Job. Thus the one thing left is how to set it up, well it depends on your web server choice. You'll need to configure a listener to start the background thread when your application gets deployed, these things are usually configured in a deployment descriptor web.xml. Warbler might spill out one for you even if you do not assemble into an "universal" (.war) package. Then just add the following XML snippet to the bottom : embedGist('1056100.js'); You'll find out more in the project's README. Happy Delaying ... P.S. Just to prove a point, I've adapted Navvy as well.