delayed_job Aktualisierungsabfrage wird unendlich ausgeführt

Ich verwende "delayed_job" und "delayed_job_active_record" für die Ausführung von Back-Ground-Jobs in meiner Rails-Anwendung. Wir verwenden den Warteschlangen-basierten delayed_job. Zum Starten der Verzögerung verwende ich den folgenden Befehl.delayed_job Aktualisierungsabfrage wird unendlich ausgeführt

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

Das Problem ist unter Abfrage unendlich feuert.

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

Und der Wert für delayed_job ist Null. Aus diesem Grund ist die Anwendung sehr langsam und die Seiten werden an vielen Stellen nicht geladen.

Kann jemand eine Lösung vorschlagen.

Danke Grüße.

Quelle

2013-04-16 apr

zu überschreiben Sorge zu versuchen, delayed_job_active_ record_threaded und sehen das hilft? Ich würde gerne Ihre Rückmeldung hören =) https://github.com/zxiest/delayed_job_active_record_threaded – Abdo

Das gleiche hier.Es täuscht, weil es keine Jobs gibt und es versucht auch ein 'UPDATE' zu machen. Es erzeugt nur eine Menge unnötigen Lärm in den Protokollen. –

@Menon hast du es geschafft, zu einer Lösung zu kommen? – scanales

Das ist also eine Abfrage speziell für Postgres entwickelt. Bitte beachten Sie https://github.com/collectiveidea/delayed_job_active_record/blob/master/lib/delayed/backend/active_record.rb#L57 warum das so sein muss.

Die Idee des verzögerten Jobs ist in der Tat, dass es die Datenbank in regelmäßigen Abständen abfragt, so dass erwartet wird, dass die Abfrage in Ihrer Frage ausgelöst wird, solange der Worker ausgeführt wird. Dies sollte jede Sekunde passieren und ich kann mir nicht vorstellen, dass dies einen signifikanten Einfluss auf die Leistung Ihrer App hat.

Arbeiten Sie auf sehr eingeschränkter Hardware wie einer sehr kleinen virtuellen Maschine?

Quelle

2013-04-17 09:19:59 moritz

Keine virtuelle Maschine. kleine Instanz in Amazon. Und ich benutze Mysql nicht postgres. – apr

Ich sehe, vielleicht ist es langsam, weil es auf die Festplatte wechselt? Hast du den Speicherbedarf der Ruby-Prozesse überprüft? – moritz

Ich denke, was Sie gemeint ist, dass delayed_jobUmfragen zu häufig (die übrigens alle 5 Sekunden Standardeinstellung) - Ich weiß, dass Ihre Log-auffüllt und scheint „unendlich“ .. :)

Wenn das ist, was Sie meinten, dann schlage ich vor, Sie laufen die workless gem. Es startet nur delayed_job auf einer pro Bedarfsbasis. Viele Leute benutzen es, um ihre Heroku Arbeiter-Dynas aus dem Leerlauf zu halten, aber es funktioniert genauso gut in development Modus.

Wenn Sie delayed_job_active_record verwenden, müssen Sie auch gem 'daemons' zu Ihrem Gemfile (daemons) hinzufügen. Siehe Running Jobs section of delayed_job.

So Ihre Gemfile würde enthalten:

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

Wenn Sie mehr Unterstützung benötigen, lassen Sie mich unten in den Kommentaren wissen.

Quelle

2013-05-30 18:08:30 user664833

ich hatte ARs silence Methode zu verwenden, nur in der Datei [path/to/delayed_job_active_record/gem]/delayed_job_active_record-[any.latest.version]/lib/delayed/backend/active_record.rb rund 68 Zeile:

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)}

schmutzige Lösung, ich weiß, aber es funktioniert ... willkommen in schlagen Sie einen besseren Wrapper vor, aber für mich Job.reserve Methode gibt es groß genug, um irgendwelche Gedanken zu töten, um es in config/initializers

Quelle

2014-01-01 18:11:38 okliv

delayed_job Aktualisierungsabfrage wird unendlich ausgeführt

Antwort

Verwandte Themen