herokuでレールアプリケーションを実行して、過去1ヶ月間、メモリの割り当て量を超過しています（R14）問題はありません。根本原因を見つけることはほとんどありませんが、正確な理由はありませんでしたか？それはweb_concurrencyのためですか？ 3.2.22Herokuのレール
ルビー：1.9.3
サーバー：また、我々はnew_relic
Railsの使用しているユニコーンを、WEB_CONCURRENCYは、私たちが使用している20 dynosの合計として5
あり、および管理しますプロセススケジューラ
であなたの全体のRoRのスタックはかなり古くなっているとHerokuのは、今とプーマを支持しますはるかに少ないメモリを食べるのが好ましく、サーバー、（あなたがhttp://puma.io/での彼らのベンチマークを確認することができます） puma benchmark
問題は、どこからともなく開始した場合にもかかわらず、私はむしろどちらかのように発生している宝石やコードの断片を探しますメモリ消費量（activeadmin、rmagickなど）また、高速ではあるが高価なソリューションはあなたのdyno（Performance-LまたはPerformance-M）を増やしているでしょう WEB_CONCURRENCYがそれを下げてR14問題を解決するかどうかを確認してください
はい、プーマでありますが、私たちのコードはスレッドセーフであることを確認していますか？ – django
Rails 3.2.22を使用するので、ベースフレームワークは少なくともスレッドセーフです。それは、あなたがレガシー・レール・アプリを「ちょうど仕事」にしようとしていることを私に縫う。 問題を解決するには、hwを追加するか、swを改善します。ソフトウェアの1つ（ルビーバージョン、レールフレームワークをアップグレードし、unicornの代わりにpumaを使用するとUrlの問題の多くが緩和されます）。時間がなければ、あなたのベストショットがあなたのdynoのパフォーマンスを向上させます。メモリリークの問題は、時々あなたはR14の事に悩まされるでしょう。唯一の違いは、より良いdynos – Codextremist
おそらく、新しい遺物を使用しているので、ログを参照してメモリ使用量のチャートを確認してください。 dynosを再起動してから長時間（おそらく2,3時間または1日後）でもグラフがまだメモリの増加を示している（飽和していない）場合は、メモリがリークしています。そうだとすれば、誰かが完全なソースコードなしであなたを助けることができるかどうかはわかりません。私はこれらを狩るのに苦労しました。可能であれば、最初にRuby 2.xにアップグレードすることを提案します。それは1.9.xを超えるガベージコレクションの大きな改善を持っています – Sajan