Rails mehrere delayed_job laufen - Lock-Tabellen

Question

Hey. Ich benutze delayed_job für die Hintergrundverarbeitung. Ich habe 8-CPU-Server, MySQL und I 7 delayed_job Prozesse starten

RAILS_ENV=production script/delayed_job -n 7 start 

Q1: Ich frage mich, ist es möglich, dass zwei oder mehr delayed_job Prozesse der Verarbeitung des gleichen Prozesses (der gleiche Datensatz-Zeile in der Datenbank delayed_jobs) starten. Ich habe den Code der delayed_job Plugin kann aber nicht die Sperre Richtlinie in einer Art und Weise finden (keine Sperrtabelle oder SELECT ... FOR UPDATE) sein sollte.

ich denke, jeder Prozess sollte die Datenbanktabelle sperren, bevor eine UPDATE auf lock_by Spalte ausführt. Sie sperren den Datensatz, indem einfach das locked_by Feld aktualisieren (UPDATE delayed_jobs SET locked_by ...). Ist das wirklich genug? Keine Sperren benötigt? Warum? Ich weiß, dass UPDATE höhere Priorität als SELECT hat, aber ich denke, das ist nicht die Wirkung in diesem Fall hat.

Mein Verständnis der multy-Threaded-Situation ist:

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]

Ich denke, in einigen Fällen mehr Arbeitsplätze die gleichen Informationen erhalten und kann die Verarbeitung des gleichen Prozess starten.

Q2: Ist 7 delayed_jobs eine gute Zahl für 8CPU Server? Warum ja / nicht.

Thx 10x!

Answer 1

Ich denke, die Antwort auf Ihre Frage in Zeile 168 von '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)])

Hier ist das Update der Zeile wird nur dann durchgeführt, wenn kein anderer Arbeiter bereits den Auftrag gesperrt hat und diese Option aktiviert ist, wenn die Tabelle aktualisiert wird. Eine Tabellensperre oder ähnlich (die übrigens massiv die Leistung Ihrer App verringern würden) ist nicht erforderlich, da Ihr DBMS gewährleistet, dass die Ausführung einer einzelnen Abfrage von Effekten aus anderen Abfragen isoliert. In Ihrem Beispiel Process2 kann nicht die Sperre für Job X bekommen, da es die Arbeitsplätze Tabelle aktualisiert, wenn und nur wenn es vorher nicht gesperrt wurde.

Um Ihre zweite Frage: Es hängt davon ab. Auf einem 8-CPU-Server. die für diese Aufgabe gewidmet, 8 Arbeiter sind ein guter Ausgangspunkt, da Arbeiter Single sind Gewinde sollten Sie eine für jeden Kern laufen. Je nach Konfiguration sind besser mehr oder weniger Arbeiter. Es hängt stark von Ihren Aufträgen. Nehmen Sie Ihre Jobs Vorteil mutiple Kerne? Oder ist Ihre Aufgabe, die meiste Zeit für externe Ressourcen warten? Sie haben experimentieren mit verschiedenen Einstellungen und haben einen Blick auf alle beteiligten Ressourcen.