delay_job 进程静默退出答案

【问题标题】：delayed_job process silently quitsdelay_job 进程静默退出
【发布时间】：2014-11-07 11:34:43
【问题描述】：

我希望我能在这里提供更多信息，但我只是在撒网，希望有人对我可以尝试什么或看什么方向有一些想法。基本上我有一个使用延迟作业的 Rails 应用程序。它将大约需要 10 或 15 分钟的进程卸载到后台任务。直到昨天它工作正常。现在每次登录服务器时，我发现没有延迟的作业进程在运行。我已经重新启动，停止和启动等十几次，但无处可去。第二次它尝试处理队列中的第一项，该进程被终止，并且没有任何内容记录到日志文件中。

我试过这样运行它：

RAILS_ENV=production script/delayed_job run

代替普通的守护进程：

RAILS_ENV=production script/delayed_job start

这并没有给我更多的信息。这是输出：

delayed_job: process with pid 4880 started.
Killed

它可能会运行 10 秒，然后才会杀死。我不知道从哪里开始。我已经尝试了很多事情，比如将守护进程 gem 降级到 1.0.10，就像其他帖子中建议的那样。

任何想法都会令人惊叹。

【问题讨论】：

您检查过log/production.log 和log/delayed_job.log 是否有错误？也许只是尝试在“正常”模式下启动它，看看终端中是否显示错误RAILS_ENV=production bundle exec rake jobs:work - 我通常也使用 bundle 启动脚本，即RAILS_ENV=production bundle exec script/delayed_job start
服务器是否有足够的马力来运行您的工作？您是否也在使用这台机器来提供网络请求？
嘿，我相信你的第二条评论已经把它钉在了头上。我最近将盒子的大小从 2gb 缩小到了 1gb。我在更小（1gb）的节点之间进行负载平衡。我相信这个进程会吞噬所有的内存并且操作系统会杀死它。我将盒子的大小重新调整为 2gb，现在它可以工作了！看起来我必须找到一种方法来提高脚本的效率。它提取了大约 300 万条记录并对其进行了一些运算。不过，它可能只需要每周执行一次，因此很难证明拥有如此大的足迹箱是合理的。哦，好的，问题暂时解决了！谢谢！

标签： ruby-on-rails ruby process delayed-job

【解决方案1】：

如果其他人遇到此问题，解决方案是它只是内存不足而操作系统正在杀死它。

我运行了几次作业，并在等待时看着顶部。我看到该 pid 的内存使用量缓慢攀升，直到进程被终止并释放所有内存。

希望对某人有所帮助。

【讨论】：

是的，我同意工人正在占用更多内存并被操作系统杀死。但是有没有办法解决这个问题，因为我们无法继续监控工人是死是活？
我的解决方案是增加服务器上的内存。您的选择是增加服务器上的内存，或者重构代码以使用更少的内存。寻找创建大型内存数组的东西，例如 Model.all 或 Collection.each。这些可以更改为 find_each 例如，以限制一次内存中的记录数。