Ruby、DelayedJobが遅すぎると処理が遅くなる

Question

テーブルdelayed_jobsが数百の上に成長し始めると、作業者のパフォーマンスが指数関数的に低下し始めます。

Answer 1

私はこの問題に何度も苦労していますので、私はこの悪夢に将来の新人のための私の発見を公開します。問題は、クエリDelayedJobである

• https://github.com/collectiveidea/delayed_job/issues/581
• https://github.com/collectiveidea/delayed_job/issues/650

エイブリィワーカーの実行に使用しています：

は、この問題に係るDelayedJobsプロジェクトに開かれたいくつかの問題があります

UPDATE `delayed_jobs` SET `locked_at` = '2014-04-17 22:32:20', `locked_by` = 'host:b38f770a-f3f3-4b2a-8c66-7c8eebdb7fea pid:2' WHERE ((run_at <= '2014-04-17 22:32:20' AND (locked_at IS NULL OR locked_at < '2014-04-17 18:32:20') OR locked_by = 'host:b38f770a-f3f3-4b2a-8c66-7c8eebdb7fea pid:2') AND failed_at IS NULL) ORDER BY priority ASC, run_at ASC LIMIT 1 

ca私の場合、1000ジョブ未満で約1秒かかる。また、より多くのジョブが保留になると指数関数的に増加する。

私が見つけた唯一の解決策は、1は一言で言えば、this blogで公開されている：問題は、最初のクエリのための適切な指標の欠如であるとして、ソリューションはバッチでテーブルを分割することです：

-- stop workers 
select max(id) from delayed_jobs; -- -> 10010 
create table delayed_jobs_backup like delayed_jobs; 
insert into delayed_jobs_backup select * from delayed_jobs where id < 10010; 
delete from delayed_jobs where id < 10010; 
-- start workers 
-- while jobs in delayed_jobs_backup do 
    -- wait until the batch have been processed 
    insert into delayed_jobs select * from delayed_jobs_backup limit 1000; 
    delete from delayed_jobs_backup limit 1000; 
-- end 

Answer 2

遅延ジョブは非常に多数のジョブに対して最適化されていません。長期的な解決策はsidekiq（https://github.com/mperham/sidekiq）のようなものに移動することですが、短期のために、あなたのdelayed_jobキュークリアするには、以下の戦略を使用することができます。

http://aawaara.com/post/61798959791/break-it-down