Rails exécution de plusieurs delayed_job - tables de verrouillage

Question

Hey. J'utilise delayed_job pour le traitement de fond. J'ai 8 serveur CPU, MySQL et je commence à 7 processus de delayed_job

RAILS_ENV=production script/delayed_job -n 7 start 

Q1: Je me demande est-il possible que 2 ou plusieurs processus de delayed_job commencer à traiter le même processus (le même enregistrement ligne dans la base de données delayed_jobs). J'ai vérifié le code du plugin delayed_job mais ne trouve pas la directive de verrouillage dans un sens, il doit être (pas de table de verrouillage ou SELECT ... FOR UPDATE).

Je pense que chaque processus doit verrouiller la table de base de données avant d'exécuter une instruction UPDATE sur la colonne de lock_by. Ils bloquent le dossier simplement en mettant à jour le champ locked_by (UPDATE delayed_jobs SET locked_by ...). Est-ce vraiment suffisant? Aucun verrouillage nécessaire? Pourquoi? Je sais que UPDATE a la priorité sur SELECT mais je pense que cela n'a pas l'effet dans ce cas.

Ma compréhension de la situation multy-thread est:

Process1: Get waiting job X. [OK]
Process2: Get waiting jobs X. [OK]
Process1: Update locked_by field. [OK]
Process2: Update locked_by field. [OK]
Process1: Get waiting job X. [Already processed]
Process2: Get waiting jobs X. [Already processed]

Je pense que dans certains cas, plus d'emplois peuvent obtenir les mêmes informations et peuvent commencer à traiter le même processus.

Q2: Est-7 delayed_jobs un bon nombre pour le serveur 8CPU? Pourquoi oui / non.

Thx 10x!

Answer 1

Je pense que la réponse à votre question est dans la ligne 168 de 'lib / delayed_job / job.rb':

self.class.update_all(["locked_at = ?, locked_by = ?", now, worker], ["id = ? and (locked_at is null or locked_at < ?)", id, (now - max_run_time.to_i)])

Voici la mise à jour de la ligne est effectuée uniquement, si aucun autre travailleur a déjà verrouillé le travail et cette option est cochée si la table est mise à jour. Un verrou de table ou similaire (qui, par la voie réduirait massivement les performances de votre application) ne sont pas nécessaires, puisque votre SGBD assure que l'exécution d'une seule requête est isolée des effets hors d'autres requêtes. Dans votre exemple Process2 ne peut pas obtenir le verrou pour l'emploi X, car il met à jour la table de l'emploi si et seulement si elle n'a pas été verrouillé avant.

Pour votre deuxième question: Cela dépend. Sur un serveur CPU 8. qui est dédié à ce travail, 8 travailleurs sont un bon point de départ, car les travailleurs sont simples, vous devez exécuter enfilée un pour chaque noyau. En fonction de votre configuration des travailleurs plus ou moins sont mieux. Cela dépend fortement de vos travaux. Prenez votre emploi avantage des noyaux de mutiple? Ou bien votre travail attend la plupart du temps des ressources externes? Vous avez l'expérience avec des paramètres différents et ont un regard sur toutes les ressources concernées.