Ruby on Rails アプリ (v2.3.8) でcollectiveidea のdelayed_jobを使用しており、8GB RAM の Slicehost マシン (Ubuntu 10.04 LTS、Apache 2) で約 40 のバックグラウンド ジョブを実行しています。
ワーカーが実行されていない状態でサーバーに ssh したとします。実行するとfree -m、一般的に 8 GB のうち約 1 GB の RAM を使用していることがわかります。次に、ワーカーを開始し、コードがそれらを使用するのを約 1 分待った後、最大で約 4 GB になりました。1 時間か 2 時間後に戻ってくると、8 GB になっていてスワップ メモリが使用されており、Web サイトで 502 エラーが発生しています。
これまでのところ、ワーカーを殺して再起動するだけでしたが、問題の根本を修正したいと思います。何かご意見は？これはメモリリークですか？または、友人が提案したように、ガベージ コレクションを実行する方法を理解する必要がありますか?
実際、モデルにシリアライズされた属性がある場合、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からの問題は次のとおりです。
誰かがこれについて尋ねるたびに、問題は彼らのコードにあります。利用可能なプロファイリング ツールのいずれかを使用して、ジョブがリークしている場所を見つけてみてください。( https://github.com/wycats/ruby-profなど)
各ジョブの最後に GC をトリガーすると、スループットが大幅に低下しますが、最大メモリ使用量が削減されます。ただし、Ruby はメモリを解放して OS に戻すことができないため、Ruby が個々のジョブに必要な最大サイズまで肥大化するのを止めることはできません。この方法を取ることはお勧めしません。