問題タブ [oink]

私のRailsアプリケーションでは、リクエストごとにオブジェクトの総数が増えています。GCの実行後、オブジェクトは解放されません。Rails3.2.3とruby1.9.3を使用しています。

誰かが私を正しい方向に向けることができますか？どこから始めれば？

利用可能なツールは何ですか？

私が試したツール。ObjectSpaceは、これらのオブジェクトが作成された行を参照していません。Memprofはruby1.9.3では動作しません。Oinkは、これらのオブジェクトが作成された行を参照していません。

メモリ リークが発生しており、それを追跡しようとしているため、Heroku サーバーで oink を使用しようとしています。Heroku はログ アーカイブを提供しないため、Papertrail アドオンを使用して Amazon S3 にエクスポートします。

これには成功しましたが、oink を使用するには、ログ ファイルが「Hodel 3000 準拠のロガー」と呼ばれる特別な形式である必要があります。開発中はなんとかできましたが、本番環境 (*heroku) でそのようなログ ファイルを作成する方法がわかりません。どんな助けでも大歓迎です。

前もって感謝します、

フアン・ラグランジェ

Heroku のアプリで oink gem を実行すると問題が発生します。gemfile と gemfile.lock に含めてアップロードし、インストールします。さらに、oink.log を作成します (残念ながら、これを表示する方法はありません)。私が走るとき

heroku run bundle exec oink --threshold=0 log/* --app my_app

私は得る

実行中 bundle exec oink --threshold=0
log/delayed_job.log log/development.log log/oink.log log/production.log log/test.log 端末に添付... up, run.3
/app/.bundle /gems/ruby/1.8/gems/oink-0.9.3/bin/../lib/oink/cli.rb:88:in get_file_listing': /app から
"log/delayed_job.log" (RuntimeError) が見つかりませんでした
/.bundle/gems/ruby/1.8/gems/oink-0.9.3/bin/../lib/oink/cli.rb:86:ineach'
from /app/.bundle/gems/ruby/1.8/gems/ /app/.bundle/gems/ruby/1.8/gems/oink-0.9.3/bin/../ から oink-0.9.3/bin/../lib/oink/cli.rb:86:in get_file_listing
でlib/oink/cli.rb:59:inprocess'
from /app/.bundle/gems/ruby/1.8/gems/oink-0.9.3/bin/oink:4
from /app/.bundle/gems/ruby/1.8 /bin/oink:19:in 'load'
/app/.bundle/gems/ruby/1.8/bin/oink:19 より

個々のファイルもそれぞれ実行してみましたが、同じ結果が得られました。このコマンドは、ローカル マシンで正常に実行されます。

私の production.rb ファイルには、

config.logger = Hodel3000CompliantLogger.new(config.paths.log.first)
config.middleware.use( Oink::Middleware )

構成として。

ここで私が間違っていることを教えてもらえますか? heroku logs私の理解では、ログは読み取り専用ですが、それがコマンドを介してのみアクセスできることを意味するかどうかはわかりません. oink.log ファイルも確認できる方法がある場合は、その方法を知っているか、heroku logs.

更新: 上記の oink の構成により、ローカルホストでコマンドを正常に実行できます。

ありがとう！

-アンドリュー

oink gem を使用してアプリのメモリ使用量をプロファイリングしていますが、理解できない奇妙な出力が得られます。

私のホームページはいくつかのアパートをロードしますApartment.where(visible: true)

コンソールでこのクエリを実行すると、Apartment.where(visible: true).count8 が返されます。

しかし、同じ8つのアパートをロードするはずのホームページをロードすると、私のOinkログには次のように表示されます。

これらの余分なアパートがどこから来ているのか分かりますか??

ありがとう、うり

以前の質問で、Oink はこの設定 ( arches.io に関するこの記事の設定を反映したもの) で Heroku の標準出力に正常にログインできたようです。

Gemfile:

アプリケーション.rb:

以前の質問の時点から判断すると、Rails 3 を使用していた可能性があります。Rails 4.1.4 を使用していますが、現在、Heroku で標準出力にログインできません。Rails 4 を使用している場合、Heroku の開発者はrails_stdout_logging、ログが確実に標準出力に送信されるように gem を使用することを提案しています。私たちは現在このgemを使用しているので、上記のセットアップでOinkが標準出力にログインするのを止めているのでしょうか?

ローカルで Oink は問題なくログを記録しています。

PS LOG_LEVEL を info に設定しようとしましたが成功しませんでした

R14最近、Heroku で多くのエラーが発生していることに、やや懸念を抱いています。

これがユニコーンの使用と関係があるかどうかはわかりません。または、最近 New Relic または Logentries をインストールした。私は本当にそれを解決することはできません。

私は Oink を「インストール」し、次の分析を受け取ったばかりですが、それが何を伝えようとしているのかを完全に理解する方法がわかりません。

素人として、私message#getmessagecountはたくさんのメモリを食べているのではないかと心配しています。上記の意味でしょうか？

もしそうなら...ルーチンは単純です：

そして、これがどのようにしてメモリを「リーク」するのかわかりません。

過去 1 日の Heroku のメモリ使用量のグラフは次のようになります。

私は使用してRuby 2.1.4おりRails 4.1.7、それが助けになる場合。2 つの Web dyno と 1 つの Worker を使用しています。

ああ...そして私のメッセージ削除ルーチンは次のとおりです。

デフ削除メッセージ

終わり

これは私のパフォーマンスを3時間ごとに殺しています（それが正しいことを言うのであれば）. これが 10 分ごとに増加している理由がわかりません (これは、グラフを読んで推測できます)。getmessagecount1 つのテスト アプリで 10 分ごとにルーチンをポーリングする iPhone アプリがあるので、10 分は重要かもしれません。アプリの 10 個のコピー (または 1,000 個のコピー) がサーバーにアクセスし始めたらどうなるのだろうか?

どんな助けでも非常に深く感謝します。

Heroku で Rails 4.2 アプリケーションを実行しています。Ruby のバージョンは 2.2.4 です。

Heroku の log-runtime-metrics を使用してアプリケーションを再起動すると、アプリは次のログを記録します。

アプリのランディングで別のページをクリックするだけで、次の詳細が報告されます。

Oink レポート: メモリ使用量: 435416

アプリに入ると、ページネーションのあるデータテーブルがいくつかあります。ページを移動すると、メモリが増え続けます。

現時点での報告: メモリ使用量: 602352

Heroku がレポートするアプリのよりシンプルなページに移動すると、次のようになります。

Oink レポート メモリ使用量: 604744

Heroku を 5 分移動した後、メモリの合計が 360 から 400+ MB と報告されました。メモリ クォータ エラーにはなりませんが、新しい Web ワーカーが解雇される場合は、そうなるに違いありません。

また、ObjectSpace からいくつかのデータを取得しました。サイト内を (今回はローカルで) ナビゲートします。最初は最も単純なページを使用し、次にページネーションを使用してパーツに入り、より多くのデータをフェッチし、外に出ます。以下は、ObjectSpace.count_objects からのログの一部です。

{:TOTAL=>556379、:FREE=>1142、:T_OBJECT=>27740、:T_CLASS=>7356、:T_MODULE=>1563、:T_FLOAT=>9、:T_STRING=>241807、:T_REGEXP=>2481、: T_ARRAY=>92685、:T_HASH=>16081、:T_STRUCT=>1118、:T_BIGNUM=>13、:T_FILE=>117、:T_DATA=>81408、:T_MATCH=>6132、:T_COMPLEX=>1、:T_RATIONAL= >909、:T_SYMBOL=>1691、:T_NODE=>62347、:T_ICLASS=>11779}

{:TOTAL=>556379、:FREE=>1211、:T_OBJECT=>27540、:T_CLASS=>7354、:T_MODULE=>1565、:T_FLOAT=>9、:T_STRING=>241100、:T_REGEXP=>2478、: T_ARRAY=>93344, :T_HASH=>16763, :T_STRUCT=>1078, :T_BIGNUM=>13, :T_FILE=>122, :T_DATA=>81422, :T_MATCH=>6031, :T_COMPLEX=>1, :T_RATIONAL= >911、:T_SYMBOL=>1690、:T_NODE=>61968、:T_ICLASS=>11779}

{:TOTAL=>556379、:FREE=>946、:T_OBJECT=>24257、:T_CLASS=>7523、:T_MODULE=>1565、:T_FLOAT=>9、:T_STRING=>251448、:T_REGEXP=>2362、: T_ARRAY=>83078, :T_HASH=>15272, :T_STRUCT=>1175, :T_BIGNUM=>63, :T_FILE=>128, :T_DATA=>89152, :T_MATCH=>5952, :T_COMPLEX=>1, :T_RATIONAL= >963、:T_SYMBOL=>2028、:T_NODE=>58656、:T_ICLASS=>11801}

ページネーションを使用したデータ テーブルの入力、ページあたり 25 レコード、取得されたデータには一意の文字列 (実際のアドレス) が含まれます。

{:TOTAL=>556379、:FREE=>906、:T_OBJECT=>26280、:T_CLASS=>7363、:T_MODULE=>1563、:T_FLOAT=>9、:T_STRING=>252024、:T_REGEXP=>2474、: T_ARRAY=>87445, :T_HASH=>15347, :T_STRUCT=>1144, :T_BIGNUM=>16, :T_FILE=>133, :T_DATA=>80601, :T_MATCH=>6686, :T_COMPLEX=>1, :T_RATIONAL= >985、:T_SYMBOL=>1690、:T_NODE=>59906、:T_ICLASS=>11806}

{:TOTAL=>556379、:FREE=>146、:T_OBJECT=>18752、:T_CLASS=>7359、:T_MODULE=>1563、:T_FLOAT=>9、:T_STRING=>295002、:T_REGEXP=>2304、: T_ARRAY=>81885、:T_HASH=>13791、:T_STRUCT=>867、:T_BIGNUM=>15、:T_FILE=>11、:T_DATA=>77634、:T_MATCH=>847、:T_COMPLEX=>1、:T_RATIONAL= >1251、:T_SYMBOL=>1679、:T_NODE=>41463、:T_ICLASS=>11800}

{:TOTAL=>571870、:FREE=>433、:T_OBJECT=>19352、:T_CLASS=>7369、:T_MODULE=>1565、:T_FLOAT=>9、:T_STRING=>294098、:T_REGEXP=>2358、: T_ARRAY=>91079、:T_HASH=>14983、:T_STRUCT=>879、:T_BIGNUM=>15、:T_FILE=>16、:T_DATA=>77945、:T_MATCH=>1128、:T_COMPLEX=>1、:T_RATIONAL= >1591、:T_SYMBOL=>2028、:T_NODE=>45197、:T_ICLASS=>11824}

{:TOTAL=>628109、:FREE=>343、:T_OBJECT=>20647、:T_CLASS=>7360、:T_MODULE=>1563、:T_FLOAT=>9、:T_STRING=>318169、:T_REGEXP=>2346、: T_ARRAY=>115854、:T_HASH=>17767、:T_STRUCT=>949、:T_BIGNUM=>15、:T_FILE=>10、:T_DATA=>79152、:T_MATCH=>1243、:T_COMPLEX=>1、:T_RATIONAL= >1789、:T_SYMBOL=>1685、:T_NODE=>47405、:T_ICLASS=>11802}

{:TOTAL=>727564、:FREE=>470、:T_OBJECT=>22820、:T_CLASS=>7361、:T_MODULE=>1563、:T_FLOAT=>9、:T_STRING=>362350、:T_REGEXP=>2390、: T_ARRAY=>152959、:T_HASH=>22342、:T_STRUCT=>1035、:T_BIGNUM=>33、:T_FILE=>11、:T_DATA=>81286、:T_MATCH=>2167、:T_COMPLEX=>1、:T_RATIONAL= >2497、:T_SYMBOL=>1686、:T_NODE=>54779、:T_ICLASS=>11805}

{:TOTAL=>811122、:FREE=>392、:T_OBJECT=>24361、:T_CLASS=>7362、:T_MODULE=>1563、:T_FLOAT=>9、:T_STRING=>409740、:T_REGEXP=>2434、: T_ARRAY=>176571、:T_HASH=>25118、:T_STRUCT=>1076、:T_BIGNUM=>51、:T_FILE=>13、:T_DATA=>82701、:T_MATCH=>2858、:T_COMPLEX=>1、:T_RATIONAL= >3093、:T_SYMBOL=>1686、:T_NODE=>60285、:T_ICLASS=>11808}

今すぐデータテーブルとページネーションを残して、アプリのよりシンプルなページに

{:TOTAL=>819681、:FREE=>494、:T_OBJECT=>24601、:T_CLASS=>7374、:T_MODULE=>1563、:T_FLOAT=>9、:T_STRING=>413540、:T_REGEXP=>2437、: T_ARRAY=>178899、:T_HASH=>25953、:T_STRUCT=>1118、:T_BIGNUM=>93、:T_FILE=>14、:T_DATA=>83043、:T_MATCH=>2924、:T_COMPLEX=>1、:T_RATIONAL= >3121、:T_SYMBOL=>1688、:T_NODE=>60999、:T_ICLASS=>11810}

gc プロファイラー データも取得できます。しかし、私が心配しているのは、報告されたデータと割り当てられたもののほとんどが必要であり、とにかく必要な宝石からのものであるということです。

そう...

メモリリーク、またはメモリフットプリントが非常に高い理由を検出し、できる限り削減しようとしています。ここから先に進むためのアドバイスは大歓迎です。

最初のクリック後 (再起動後)、Heroku によって報告されたメモリが 2 倍になる理由を理解しておくとよいでしょう。

しかし、Oink が報告するものと Heroku が報告するものとの違いは非常に大きいので、Oink はバイト単位で報告していると思います。繰り返しになりますが、彼らはさまざまなことを報告していると思います。少なくとも、Heroku はもっと多くのことを報告しています。

このすべてのデータを解釈するための良いヒントはありますか? Heroku アプリにとって 300 ～ 400 MB のメモリ使用量は大きすぎませんか?

ありがとう。