使用“rails runner”进行cron作业非常耗费CPU - 替代方案?

时间:2011-09-16 14:11:20

标签: ruby-on-rails ruby-on-rails-3.1

我目前正在使用cron和“rails runner”来执行后台作业。在大多数情况下,这些工作都是简单的民意调查“查找将收到提醒电子邮件的记录。发送该电子邮件。”

我一直在关注我的Amazon EC2 Small实例,并注意到每次启动其中一个cron作业时,CPU都会达到~99%。我当前工作中的小小查询肯定是负责。我认为尖峰仅仅是因为通过“rails runner”加载整个rails环境的努力。

是否有更高效的CPU处理定期批处理作业的方法?

P.S。我知道,在将来X时间发送提醒电子邮件的特定示例中,我可以延迟工作,并且将来只安排工作。并非所有可能的任务都很适合delayed_jobs框架,所以我正在寻找更传统的“cron job”类型解决方案。像“rails runner”,但没有疯狂的CPU后果。

2 个答案:

答案 0 :(得分:2)

你可以使用不加载rails env的工人。或者只加载一次(如resque

答案 1 :(得分:0)

我认为没有解决方案,因为您需要加载Rails环境来处理您正在处理的任何内容。因此,在“cron”模型上,您将启动一个处理程序,这反过来会在您的实例上创建一些负载。我不知道云服务是如何适应这种情况的,但我认为在你的情况下,最佳模型将是一个运行守护进程用于作业处理和分叉与REE一起执行作业(这有助于防止内存泄漏尽可能发生在执行循环结束时死亡的子进程中。)

守护程序可以配置为接受信号(也可以通过作业队列),这些信号会分离执行特定事务的作业。

相关问题