1

Heroku のバックグラウンド プロセスで発生するメモリ リークや問題を追跡する方法について誰かアドバイスをいただけないでしょうか。

私は、delayed_job キューで実行されている 1 つの dyno ワーカーを持っており、あらゆる種類の異なるプロセスを処理しています。ときどき、メモリの消費量が急激に増加します。後続のジョブはメモリ制限を超えて失敗し、すべての地獄が解き放たれます。

奇妙なことは、メモリのジャンプが特定のジョブに関連していることがわからないことです。これが私が見るログの種類です：

Aug 15 07:13:25 vemmleads heroku/worker.1:  source=heroku.10054113.worker.1.4589e3f4-8208-483a-a927-67c4c1cbee46 measure=load_avg_1m val=0.00 
Aug 15 07:13:25 vemmleads heroku/worker.1:  source=heroku.10054113.worker.1.4589e3f4-8208-483a-a927-67c4c1cbee46 measure=load_avg_5m val=0.01 
Aug 15 07:13:25 vemmleads heroku/worker.1:  source=heroku.10054113.worker.1.4589e3f4-8208-483a-a927-67c4c1cbee46 measure=load_avg_15m val=0.01 
Aug 15 07:13:25 vemmleads heroku/worker.1:  source=heroku.10054113.worker.1.4589e3f4-8208-483a-a927-67c4c1cbee46 measure=memory_total val=133.12 units=MB 
Aug 15 07:13:25 vemmleads heroku/worker.1:  source=heroku.10054113.worker.1.4589e3f4-8208-483a-a927-67c4c1cbee46 measure=memory_rss val=132.23 units=MB 
Aug 15 07:13:25 vemmleads heroku/worker.1:  source=heroku.10054113.worker.1.4589e3f4-8208-483a-a927-67c4c1cbee46 measure=memory_cache val=0.88 units=MB 
Aug 15 07:13:25 vemmleads heroku/worker.1:  source=heroku.10054113.worker.1.4589e3f4-8208-483a-a927-67c4c1cbee46 measure=memory_swap val=0.01 units=MB 
Aug 15 07:13:25 vemmleads heroku/worker.1:  source=heroku.10054113.worker.1.4589e3f4-8208-483a-a927-67c4c1cbee46 measure=memory_pgpgin val=0 units=pages 
Aug 15 07:13:25 vemmleads heroku/worker.1:  source=heroku.10054113.worker.1.4589e3f4-8208-483a-a927-67c4c1cbee46 measure=memory_pgpgout val=45325 units=pages 
Aug 15 07:13:25 vemmleads heroku/worker.1:  source=heroku.10054113.worker.1.4589e3f4-8208-483a-a927-67c4c1cbee46 measure=diskmbytes val=0 units=MB 
Aug 15 07:13:31 vemmleads heroku/web.1:  source=heroku.10054113.web.1.bf5d3fae-2b1b-4e1d-a974-01d9fa4644db measure=load_avg_1m val=0.15 
Aug 15 07:13:31 vemmleads heroku/web.1:  source=heroku.10054113.web.1.bf5d3fae-2b1b-4e1d-a974-01d9fa4644db measure=load_avg_5m val=0.07 
Aug 15 07:13:31 vemmleads heroku/web.1:  source=heroku.10054113.web.1.bf5d3fae-2b1b-4e1d-a974-01d9fa4644db measure=load_avg_15m val=0.17 
Aug 15 07:13:31 vemmleads heroku/web.1:  source=heroku.10054113.web.1.bf5d3fae-2b1b-4e1d-a974-01d9fa4644db measure=memory_total val=110.88 units=MB 
Aug 15 07:13:31 vemmleads heroku/web.1:  source=heroku.10054113.web.1.bf5d3fae-2b1b-4e1d-a974-01d9fa4644db measure=memory_rss val=108.92 units=MB 
Aug 15 07:13:31 vemmleads heroku/web.1:  source=heroku.10054113.web.1.bf5d3fae-2b1b-4e1d-a974-01d9fa4644db measure=memory_cache val=1.94 units=MB 
Aug 15 07:13:31 vemmleads heroku/web.1:  source=heroku.10054113.web.1.bf5d3fae-2b1b-4e1d-a974-01d9fa4644db measure=memory_swap val=0.01 units=MB 
Aug 15 07:13:31 vemmleads heroku/web.1:  source=heroku.10054113.web.1.bf5d3fae-2b1b-4e1d-a974-01d9fa4644db measure=memory_pgpgin val=2908160 units=pages 
Aug 15 07:13:31 vemmleads heroku/web.1:  source=heroku.10054113.web.1.bf5d3fae-2b1b-4e1d-a974-01d9fa4644db measure=memory_pgpgout val=42227 units=pages 
Aug 15 07:13:31 vemmleads heroku/web.1:  source=heroku.10054113.web.1.bf5d3fae-2b1b-4e1d-a974-01d9fa4644db measure=diskmbytes val=0 units=MB 
Aug 15 07:13:35 vemmleads app/heroku-postgres:  source=HEROKU_POSTGRESQL_CHARCOAL measure.current_transaction=1008211 measure.db_size=482260088bytes measure.tables=39 measure.active-connections=6 measure.waiting-connections=0 measure.index-cache-hit-rate=0.99996 measure.table-cache-hit-rate=1 
Aug 15 07:13:45 vemmleads heroku/run.2472:  source=heroku.10054113.run.2472.e811164e-4413-4dcf-8560-1f998f2c2b4e measure=load_avg_1m val=0.00 
Aug 15 07:13:45 vemmleads heroku/run.2472:  source=heroku.10054113.run.2472.e811164e-4413-4dcf-8560-1f998f2c2b4e measure=load_avg_5m val=0.00 
Aug 15 07:13:45 vemmleads heroku/run.2472:  source=heroku.10054113.run.2472.e811164e-4413-4dcf-8560-1f998f2c2b4e measure=load_avg_15m val=0.14 
Aug 15 07:13:45 vemmleads heroku/run.2472:  source=heroku.10054113.run.2472.e811164e-4413-4dcf-8560-1f998f2c2b4e measure=memory_total val=108.00 units=MB 
Aug 15 07:13:45 vemmleads heroku/run.2472:  source=heroku.10054113.run.2472.e811164e-4413-4dcf-8560-1f998f2c2b4e measure=memory_rss val=107.85 units=MB 
Aug 15 07:13:45 vemmleads heroku/run.2472:  source=heroku.10054113.run.2472.e811164e-4413-4dcf-8560-1f998f2c2b4e measure=memory_cache val=0.15 units=MB 
Aug 15 07:13:45 vemmleads heroku/run.2472:  source=heroku.10054113.run.2472.e811164e-4413-4dcf-8560-1f998f2c2b4e measure=memory_swap val=0.01 units=MB 
Aug 15 07:13:45 vemmleads heroku/run.2472:  source=heroku.10054113.run.2472.e811164e-4413-4dcf-8560-1f998f2c2b4e measure=memory_pgpgin val=0 units=pages 
Aug 15 07:13:45 vemmleads heroku/run.2472:  source=heroku.10054113.run.2472.e811164e-4413-4dcf-8560-1f998f2c2b4e measure=memory_pgpgout val=33609 units=pages 
Aug 15 07:13:45 vemmleads heroku/run.2472:  source=heroku.10054113.run.2472.e811164e-4413-4dcf-8560-1f998f2c2b4e measure=diskmbytes val=0 units=MB 
Aug 15 07:13:46 vemmleads heroku/worker.1:  source=heroku.10054113.worker.1.4589e3f4-8208-483a-a927-67c4c1cbee46 measure=load_avg_1m val=0.30 
Aug 15 07:13:46 vemmleads heroku/worker.1:  source=heroku.10054113.worker.1.4589e3f4-8208-483a-a927-67c4c1cbee46 measure=load_avg_5m val=0.07 
Aug 15 07:13:46 vemmleads heroku/worker.1:  source=heroku.10054113.worker.1.4589e3f4-8208-483a-a927-67c4c1cbee46 measure=load_avg_15m val=0.04 
Aug 15 07:13:46 vemmleads heroku/worker.1:  source=heroku.10054113.worker.1.4589e3f4-8208-483a-a927-67c4c1cbee46 measure=memory_total val=511.80 units=MB 
Aug 15 07:13:46 vemmleads heroku/worker.1:  source=heroku.10054113.worker.1.4589e3f4-8208-483a-a927-67c4c1cbee46 measure=memory_rss val=511.78 units=MB 
Aug 15 07:13:46 vemmleads heroku/worker.1:  source=heroku.10054113.worker.1.4589e3f4-8208-483a-a927-67c4c1cbee46 measure=memory_cache val=0.00 units=MB 
Aug 15 07:13:46 vemmleads heroku/worker.1:  source=heroku.10054113.worker.1.4589e3f4-8208-483a-a927-67c4c1cbee46 measure=memory_swap val=0.02 units=MB 
Aug 15 07:13:46 vemmleads heroku/worker.1:  source=heroku.10054113.worker.1.4589e3f4-8208-483a-a927-67c4c1cbee46 measure=memory_pgpgin val=27303936 units=pages 
Aug 15 07:13:46 vemmleads heroku/worker.1:  source=heroku.10054113.worker.1.4589e3f4-8208-483a-a927-67c4c1cbee46 measure=memory_pgpgout val=154826 units=pages 
Aug 15 07:13:46 vemmleads heroku/worker.1:  source=heroku.10054113.worker.1.4589e3f4-8208-483a-a927-67c4c1cbee46 measure=diskmbytes val=0 units=MB

worker.1 のメモリ使用量は、明確な理由もなく 108.00 から 551.80 に跳ね上がります。その間、どのジョブも処理されていないように見えるため、その膨大な量のメモリがどこから来たのかを理解するのは困難です。ログの後半で、worker1 がメモリ制限に達し、失敗します。

NewRelic Pro を実行しています。これはまったく役に立ちません。実際、繰り返されるメモリ エラーのアラートも作成されません。上記の Heroku ログでは、これ以上の情報は得られません。

次に何を調査するかについてのアイデアや指針をいただければ幸いです。

ありがとう

サイモン

4

1 に答える 1

1

何が起こっているのかを特定するには、ここには十分な情報がありません。

Rails アプリケーション (特に非同期バックグラウンド ジョブ) でメモリ リークが発生する最も一般的な原因は、大規模なデータベース コレクションをインクリメンタルに反復処理できないことです。たとえば、次のようなステートメントですべての User レコードをロードします。User.all

たとえばUser、データベース内のすべてのレコードを処理するバックグラウンド ジョブがある場合、これらのレコードをチャンクで処理するには、User.find_each()またはUser.find_in_batches()を使用する必要があります (ActiveRecord のデフォルトは 1000 です)。

これにより、すべてのレコードを処理しながら、メモリにロードされるオブジェクトのワーキング セットが制限されます。

膨大な数のオブジェクトをロードしている可能性がある無制限のデータベース ルックアップを探す必要があります。

于 2013-08-15T15:29:22.657 に答える