I've been noticing my delayed_job workers going incredibly slowly (1 job per second), and looked at the logs to see what might be up. It seems like about 90%+ of the time per job is spent doing delayed_job bookkeeping, which seems like something must be amiss.
Here's the line in question:
SQL (811.3ms) 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
Am I somehow missing a db index or something? I'm guessing that this command isn't supposed to take 800ms!
I have encountered the same issue.
Have you resolved it?
In our specific case, each query like the below takes several seconds.
UPDATE `delayed_jobs` SET `locked_at` = '2014-07-31 02:14:49', `locked_by` = 'delayed_job.2 host:<OUR_HOST_HERE> pid:989' WHERE ((run_at <= '2014-07-31 02:14:49' AND (locked_at IS NULL OR locked_at < '2014-07-30 22:14:49') OR locked_by = 'delayed_job.2 host:<OUR_HOST_HERE> pid:989') AND failed_at IS NULL) ORDER BY priority ASC, run_at ASC LIMIT 1
Duplicated here: #581
Still not solved :/
@mumoshu Unfortunately, two years later I have not resolved this issue.
@fguillen My best guess is just that it’s a complicated query, using constraints on run_at, locked_at, locked_by, and failed_at, and then sorting by priority and run_at. That’s a lot! Perhaps some kind of composite index would do the job here.
SO thread: http://stackoverflow.com/q/40360455/316700