我在我的Ruby on Rails应用程序（v2.3.8）上使用collectiveidea's delayed_job，并在8GB RAM Slicehost机器（Ubuntu 10.04 LTS，Apache 2）上运行大约40个后台作业。
假设我在没有工作人员运行的情况下进入我的服务器。当我做free -m时，我发现我通常使用大约1GB的RAM中的8个。然后在启动工作人员并等待大约一分钟让他们被代码使用后，我就是大约4GB。如果我在一两个小时后回来，我会在8GB并进入交换内存，我的网站将产生502错误。
到目前为止，我刚刚杀了工人并重新启动它们，但我宁愿解决问题的根源。有什么想法吗？这是内存泄漏吗？或者，正如朋友建议的那样，我是否需要找到一种运行垃圾收集的方法？
答案 0 :(得分：6)
实际上，如果您的模型具有序列化属性，则Delayed :: Job 3.0会泄漏Ruby 1.9.2中的内存。 （我正在研究解决方案。）
这是一个似乎解决了它的人，http://spacevatican.org/2012/1/26/memory-leak-in-yaml-on-ruby-1-9-2
这是来自Delayed :: Job https://github.com/collectiveidea/delayed_job/issues/336
的问题答案 1 :(得分：-2)
几乎每次有人问起这个问题时，问题都在于他们的代码。尝试使用其中一个可用的性能分析工具来查找作业泄漏的位置。 （https://github.com/wycats/ruby-prof或类似的。）
在每个作业结束时触发GC将降低最大内存使用量，但会降低吞吐量。但是，它不会阻止Ruby膨胀到任何单个作业所需的最大大小，因为Ruby无法将内存释放回操作系统。我不建议采用这种方法。