我有一种感觉，这是 Rails 中的疑病症的等价物……但我看了看 tail -f logs/development.log，然后被输出催眠了:
Delayed::Backend::ActiveRecord::Job Load (0.8ms) UPDATE "delayed_jobs" SET locked_at = '2016-08-26 12:49:09.594888', locked_by = 'host:ghost pid:4564' WHERE id IN (SELECT "delayed_jobs"."id" FROM "delayed_jobs" WHERE ((run_at <= '2016-08-26 12:49:09.594275' AND (locked_at IS NULL OR locked_at < '2016-08-26 08:49:09.594332') OR locked_by = 'host:ghost pid:4564') AND failed_at IS NULL) ORDER BY priority ASC, run_at ASC LIMIT 1 FOR UPDATE) RETURNING *
Delayed::Backend::ActiveRecord::Job Load (0.5ms) UPDATE "delayed_jobs" SET locked_at = '2016-08-26 12:49:14.651262', locked_by = 'host:ghost pid:4564' WHERE id IN (SELECT "delayed_jobs"."id" FROM "delayed_jobs" WHERE ((run_at <= '2016-08-26 12:49:14.650707' AND (locked_at IS NULL OR locked_at < '2016-08-26 08:49:14.650765') OR locked_by = 'host:ghost pid:4564') AND failed_at IS NULL) ORDER BY priority ASC, run_at ASC LIMIT 1 FOR UPDATE) RETURNING *
Delayed::Backend::ActiveRecord::Job Load (0.5ms) UPDATE "delayed_jobs" SET locked_at = '2016-08-26 12:49:19.716179', locked_by = 'host:ghost pid:4564' WHERE id IN (SELECT "delayed_jobs"."id" FROM "delayed_jobs" WHERE ((run_at <= '2016-08-26 12:49:19.715433' AND (locked_at IS NULL OR locked_at < '2016-08-26 08:49:19.715494') OR locked_by = 'host:ghost pid:4564') AND failed_at IS NULL) ORDER BY priority ASC, run_at ASC LIMIT 1 FOR UPDATE) RETURNING *
这运行...每五秒。所以……呃，那是……正常吗？
我突然想到这是延迟工作必须工作的方式，通过根据时间戳检查工作，所以这只是它在做它的事情，但我没有找到像样的书面证据。
如果是这样......我的第二个问题是这不会在我的 Heroku 实例上烧钱吗？我安装了 workless gem 以试图降低成本 - 但我没有看到任何代码进来关闭它......
错误或功能，我如何不让自己破产？
最佳答案
我会尽力比其他人更完整地回答你的问题。
是的，这是正常行为。当您启动延迟作业进程时，它会以可配置的时间间隔检查您的数据库中是否有未处理的作业。 (默认为每 5 秒一次，您可以使用 Delayed::Worker.sleep_delay 设置将其配置为不同的间隔。)
您是对的，在其中一次定期检查期间，延迟作业会检查下一个需要完成的可用作业，然后运行它。
为了有效地运行延迟作业，您通常会始终使用一个工作器dyno 来不断检查要运行的新作业。
但是，您在问题中链接到的无效 gem 可以帮助您解决这个问题。无需让工作人员 24/7 全天候检查新工作，workless 仅在队列中有工作要运行时才启动工作人员 dyno。工作完成后，workless 会关闭工作器 dyno。
您可以在 workless 的 README 中阅读 description of this behavior:
然而，总有一个权衡。 Heroku 需要时间来启动一个 worker dyno，所以新工作的处理不会那么即时。例如，如果有一个持续运行的工作器 dyno，您的工作通常会在 5 秒内运行。如果您改用 workless，则可能需要大约 30 秒的时间来启动 dyno 并让 Delayed Job 开始工作。显然，什么是可接受的取决于您的应用程序，所以这完全是您的决定。