La query di aggiornamento delayed_job è in esecuzione infinita

Sto utilizzando delayed_job e delayed_job_active_record per l'esecuzione di lavori back ground nella mia applicazione rails. Stiamo usando delayed_job basato sulla coda. Per iniziare il ritardo sto usando il seguente comando.La query di aggiornamento delayed_job è in esecuzione infinita

RAILS_ENV=staging script/delayed_job -i=1 --queue=queue_name start

Il problema è al di sotto dell'interrogazione che sta sparando all'infinito.

SQL (0.4ms) UPDATE `delayed_jobs` SET `locked_at` = '2013-04-16 09:27:23', `locked_by` = 'delayed_job.=2 host:ip-10-204-210-77 pid:2168' WHERE `delayed_jobs`.`queue` IN ('queue_name') AND ((run_at <= '2013-04-16 09:27:23' AND (locked_at IS NULL OR locked_at < '2013-04-16 05:27:23') OR locked_by = 'delayed_job.=2 host:ip-10-204-210-77 pid:2168') AND failed_at IS NULL) ORDER BY priority ASC, run_at ASC LIMIT 1

E il conteggio delayed_job è zero. Per questo motivo l'applicazione è molto lenta e le pagine non si caricano in molti posti.

Qualcuno può suggerire una soluzione.

Grazie Cordiali saluti.

fonte

2013-04-16 apr

Fare attenzione a delayed_job_active_ record_threaded e vedere questo aiuta? Mi piacerebbe sentire il tuo feedback =) https://github.com/zxiest/delayed_job_active_record_threaded – Abdo

La stessa cosa qui.È ingannevole perché non ci sono lavori e sta provando a fare anche un 'AGGIORNAMENTO'. Genera solo un sacco di rumore inutile nei registri. –

@Menon sei riuscito ad arrivare a una soluzione? – scanales

Questa è una query specificatamente progettata per Postgres. Si prega di fare riferimento a https://github.com/collectiveidea/delayed_job_active_record/blob/master/lib/delayed/backend/active_record.rb#L57 per il motivo per cui deve essere così.

L'idea di un lavoro ritardato è infatti che interroga periodicamente il db, quindi è previsto che la query nella domanda venga attivata finché l'operatore è in esecuzione. Questo dovrebbe accadere ogni secondo e non riesco a immaginare che ciò abbia un'influenza significativa sulle prestazioni della tua app.

Sei in esecuzione su hardware molto limitato come una macchina virtuale molto piccola?

fonte

2013-04-17 09:19:59 moritz

Non è una macchina virtuale. piccola istanza in amazzonia. E sto usando Mysql non postgres. – apr

Vedo, forse è lento perché si sta scambiando sul disco? Hai controllato l'impronta di memoria dei processi di rubino? – moritz

Penso che quello che volevi dire è che delayed_jobsondaggi troppo spesso (che tra l'altro è ogni 5 secondi per impostazione predefinita) - So che riempie il registro, e sembra "infinito" .. :)

Se questo è ciò che intendevi, allora ti suggerisco di eseguire lo workless gem. Avvierà solo delayed_job in base alle necessità. Molte persone lo usano per mantenere i loro dynos di lavoro Heroku da inattivo, ma funziona altrettanto bene nella modalità development.

Si noti che se si utilizza delayed_job_active_record, è inoltre necessario aggiungere gem 'daemons' al numero (daemons). Vedi lo Running Jobs section of delayed_job.

Così, il vostro Gemfile conterrebbe:

gem 'delayed_job_active_record' 
gem 'daemons' 
gem 'workless'

Se avete bisogno di maggiori indicazioni, fatemelo sapere nei commenti qui sotto.

fonte

2013-05-30 18:08:30 user664833

ho dovuto usare il metodo di AR silence, basta cambiare nel file [path/to/delayed_job_active_record/gem]/delayed_job_active_record-[any.latest.version]/lib/delayed/backend/active_record.rb attorno alla riga 68:

count = ready_scope.limit(1).update_all(:locked_at => now, :locked_by => worker.name)

count = silence {ready_scope.limit(1).update_all(:locked_at => now, :locked_by => worker.name)}

soluzione sporca, lo so, ma funziona ... benvenuti a proporre un wrapper migliore, ma per me il metodo Job.reserve è abbastanza grande da eliminare qualsiasi idea per sovrascriverlo in config/initializers

fonte

2014-01-01 18:11:38 okliv

La query di aggiornamento delayed_job è in esecuzione infinita

risposta

Problemi correlati