我們已經通過延遲的工作與12名工人運行了大約6000萬個工作,從未有過這方面的報告。什麼是你的延遲工作的工作人員正在運行的SQL?您是否正在使用改變postgres鎖定行爲的gem?
這裏是DJ SQL的樣子對我來說:
UPDATE "delayed_jobs" SET locked_at = '2014-05-02 21:16:35.419748', locked_by =
'host:whatever.local pid:4729' WHERE id IN (SELECT id FROM "delayed_jobs"
WHERE ((run_at <= '2014-05-02 21:16:35.415923'
AND (locked_at IS NULL OR locked_at < '2014-05-02 17:16:35.415947')
OR locked_by = 'host:whatever.local pid:4729') AND failed_at IS NULL)
ORDER BY priority ASC, run_at ASC LIMIT 1 FOR UPDATE) RETURNING *
你已經鎖定問題與任何其他代碼?你能嘗試運行兩個軌道控制檯會話和這樣做:
控制檯會話1:
User.find(1).with_lock do sleep(10); puts "worker 1 done" end
控制檯會話2:
User.find(1).with_lock do sleep(1); puts "worker 2 done" end
啓動這兩個在同一時間,如果前2月底1,你的鎖定問題更普遍,推遲了工作。
我看到類似的東西。無法完全追蹤它,但似乎在檢查鎖定和鎖定之間,多名工作人員正在抓取並執行工作。 – 2013-03-25 18:23:08
我應該說我發現在初始化器中設置'''Delayed :: Worker.read_ahead = 1''似乎可以緩解這個問題。 – 2013-03-25 18:52:37
有Resque相同的問題,沒有找到解決方案 – 2013-03-25 18:57:33