Question

我想知道是否有人可以告诉我如何在Heroku的后台进程中追踪内存泄漏/问题。

我有一个dyno worker使用delayed_job队列运行，处理各种不同的进程。我不时会突然消耗内存。随后的作业会超过内存限制而失败，所有地狱都会松动。

奇怪的是我无法看到内存中的跳转与任何特定的工作相关联。这是我看到的那种日志：

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日志不再给我提供信息。

关于接下来要调查什么的任何想法或指示都将不胜感激。

由于

西蒙

Answer 1

此处没有足够的信息来查明正在发生的事情。

Rails应用程序（特别是异步后台作业）中内存泄漏的最常见原因是无法逐步遍历大型数据库集合。例如，使用User.all

等语句加载所有用户记录

例如，如果您的后台作业通过数据库中的每个User记录，则应使用User.find_each()或User.find_in_batches()以块的形式处理这些记录（默认为1000 for ActiveRecord）。

这会限制加载到内存中的对象的工作集，同时仍然处理所有记录。

你应该寻找可以加载大量对象的无限数据库查找。

Heroku后台进程中的内存泄漏

1 个答案: