嗨，我在带有 Postgres 的生产应用程序中使用延迟作业活动记录 gem，许多后台作业正在处理延迟作业
我在生产数据库中的 pg：outliers 输出中注意到的一件事，此查询的prop_exec_time为 4.5%，45 小时内发生了近 180 万次调用。
查询：
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 *
根据延迟的作业，轮询默认每 5 秒发生一次，但即使没有要执行的作业也会发生这种情况。目前，我们的应用程序中没有额外的配置。
我想我可以覆盖delayed_job的默认时间，这会有什么影响吗？减少通话的任何建议
此查询的prop_exec_time为 4.5%，45 小时内发生了近 180 万次调用。
4.5%似乎并不离谱。 这里真的有需要解决的问题吗？
在这 45 小时内有多少作业通过队列？ 队列在整个过程中完全空无一人吗？ 每个工作人员每 5 秒进行一次轮询，因此在 45 小时内在空队列上接听 180 万个呼叫将需要 50 个工作人员。 你有那么多吗？
我想我可以覆盖delayed_job的默认时间，这会有什么影响吗？
是的，但它也会延迟对员工检测新工作的响应。