Rotaie esecuzione delayed_job multipla - tabelle di blocco

Question

Ciao. Io uso delayed_job per l'elaborazione in background. Ho 8 CPU del server, MySQL e comincio 7 processi delayed_job

RAILS_ENV=production script/delayed_job -n 7 start 

Q1: Mi chiedo è possibile che 2 o più processi delayed_job avviare l'elaborazione dello stesso processo (lo stesso record fila nel delayed_jobs database). Ho controllato il codice del plugin delayed_job ma non riesco a trovare la direttiva di blocco in un modo che dovrebbe essere (nessuna tabella serratura o SELECT ... FOR UPDATE).

Credo che ogni processo deve bloccare la tabella del database prima di eseguire un aggiornamento sulla colonna di lock_by. Si bloccano il record semplicemente aggiornando il campo locked_by (UPDATE delayed_jobs SET locked_by ...). È davvero sufficiente? No bloccaggio necessaria? Perché? So che UPDATE ha priorità maggiore rispetto SELEZIONA ma penso che questo non ha l'effetto in questo caso.

La mia comprensione della situazione multy-threaded è:

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]

Credo che in alcuni casi, più posti di lavoro possono ottenere le stesse informazioni e possono avviare l'elaborazione lo stesso processo.

Q2: È 7 delayed_jobs un numero buono per il server 8CPU? Perché sì / no.

Thx 10x!

Answer 1

Penso che la risposta alla tua domanda è in linea 168 di '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)])

Ecco l'aggiornamento della riga viene eseguita solo, se nessun altro lavoratore ha già bloccato il lavoro e questo è controllato se la tabella viene aggiornata. Un blocco di tabella o simile (che tra l'altro avrebbe massicciamente ridurre le prestazioni dell'app) non è necessaria, poiché DBMS garantisce che l'esecuzione di una singola query è isolato da effetti off altre query. Nel tuo esempio Process2 non può ottenere il blocco per lavoro X, dal momento che aggiorna la tabella di posti di lavoro se e solo se non è stato bloccato prima.

Per la tua seconda domanda: Dipende. Su un server di 8 CPU. che è dedicato per questo lavoro, 8 lavoratori sono un buon punto di partenza, dal momento che i lavoratori sono a thread singolo è consigliabile eseguire uno per ogni nucleo. A seconda della configurazione più o meno lavoratori sono meglio. Essa dipende in larga misura i lavori. Prendete il vostro vantaggio posti di lavoro di core mutiple? Oppure il vostro lavoro aspetta la maggior parte del tempo per risorse esterne? Hai sperimentare con diverse impostazioni e dare un'occhiata a tutte le risorse coinvolte.