1
votes

Hi I am using delayed job active record gem in my production application with Postgres, a lot of background jobs are working through the delayed job

One thing I have noticed in the output of pg:outliers in our production database, the prop_exec_time is 4.5% for this query and almost 1.8 million calls happened in 45 hours.

Query:

UPDATE "delayed_jobs" SET locked_at = $1, locked_by = $2 WHERE id IN (SELECT id FROM "delayed_jobs" WHERE ((run_at <= $3 AND (locked_at IS NULL OR locked_at < $4) OR locked_by = $5) AND failed_at IS NULL) ORDER BY priority ASC, run_at ASC LIMIT $6 FOR UPDATE) RETURNING *

As per the delayed job, the polls happen every 5 seconds by default, but this happens even if there is no job to perform. Currently, there is no extra configuration in our app.

I guess I can override the default time of delayed_job, will this make any impact? Any kind of suggestion to reduce the calls

1
Yes I am using that gem @jjanes, I have updated there - Developer

1 Answers

0
votes

the prop_exec_time is 4.5% for this query and almost 1.8 million calls happened in 45 hours.

4.5% does not seem outrageous. Is there really a problem here which needs to be solved?

How many jobs went through the queue during that 45 hours? Was the queue completely empty for that whole time? The poll is every 5 seconds per worker, so getting 1.8 million calls on an empty queue in 45 hours would take 50 workers. Do you have that many?

I guess I can override the default time of delayed_job, will this make any impact?

Yes, but it will also delay the responsiveness to your workers detecting new work to do.