Rails 3.2升级至4.2后Heroku内存泄漏问题排查求助

因Heroku-18栈于5月1日弃用，将旧版Rails应用升级至要求的最低版本4.2并成功运行。近期将部署基于Rails 6的新版本，但当前需运行该旧应用。发现内存占用近乎翻倍（原3.2版本平均占用512MB内存的90%-120%），临时方案是将dynos升级为2x 1GB内存，但希望定位问题。

日志信息如下：

2023-05-01T17:46:12.209506+00:00 heroku[web.1]: Process running mem=990M(188.0%)
2023-05-01T17:46:12.211046+00:00 heroku[web.1]: Error R14 (Memory quota exceeded)
2023-05-01T17:46:33.107262+00:00 heroku[web.1]: Process running mem=990M(188.0%)
2023-05-01T17:46:33.111875+00:00 heroku[web.1]: Error R14 (Memory quota exceeded)
2023-05-01T17:46:54.224029+00:00 heroku[web.1]: Process running mem=990M(188.0%)
2023-05-01T17:46:54.227886+00:00 heroku[web.1]: Error R14 (Memory quota exceeded)
2023-05-01T17:47:15.327098+00:00 heroku[web.1]: Process running mem=990M(188.0%)
2023-05-01T17:47:15.328612+00:00 heroku[web.1]: Error R14 (Memory quota exceeded)
2023-05-01T17:47:36.150757+00:00 heroku[web.1]: Process running mem=990M(188.0%)
2023-05-01T17:47:36.152131+00:00 heroku[web.1]: Error R14 (Memory quota exceeded)
2023-05-01T17:47:57.287322+00:00 heroku[web.1]: Process running mem=990M(188.0%)
2023-05-01T17:47:57.289241+00:00 heroku[web.1]: Error R14 (Memory quota exceeded)

原应用使用memcached，升级后改为内存缓存，这可能是问题原因之一。请问能否切换为文件缓存？是否应考虑Redis缓存或其他方案？此外，该应用当前使用Unicorn，而新应用用Puma，是否值得切换？

一、缓存方案调整 #

• 文件缓存：完全可以切换，Rails 4.2原生支持文件缓存。修改config/environments/production.rb中的缓存配置：

  config.cache_store = :file_store, Rails.root.join('tmp', 'cache')
  

  注意Heroku的文件系统是临时的，dyno重启后缓存会丢失，但如果你的缓存数据不是长期依赖的，这是低成本的临时过渡方案。不过文件缓存性能比内存缓存差，适合低流量场景。
• Redis缓存：更推荐的替代方案，Heroku有官方Redis插件，配置简单且性能稳定。Rails 4.2支持Redis缓存，添加redis-rails gem到Gemfile，然后修改缓存配置：

  config.cache_store = :redis_store, ENV['REDIS_URL'], { expires_in: 90.minutes }
  

  Redis独立于应用进程，不会占用dyno内存，能直接解决当前内存过高问题，且缓存数据可跨dyno共享，比文件缓存更可靠。
• Memcached复用：其实可以继续使用，Heroku有memcachier插件，升级到Rails 4.2后重新配置dalli gem即可恢复使用，和原有逻辑一致，同样能避免内存缓存占用应用内存的问题。

二、Unicorn vs Puma选择 #

如果只是临时过渡到Rails 6版本，不建议切换到Puma：

• 切换服务器需要调整worker数量、线程数等配置，还要做兼容性测试，可能引入新问题，增加临时维护成本。
• Unicorn在Rails 4.2上是成熟稳定的选择，当前内存问题核心来自缓存而非服务器本身。
  若后续计划长期维护旧应用或优化内存，可考虑切换，但现阶段优先解决缓存问题更高效。

三、内存排查补充建议 #

除缓存外，还可从以下方向定位问题：

• 执行heroku run bundle exec rails console启动控制台，用ObjectSpace.memsize_of_all查看内存分布，或引入memory_profiler gem分析内存占用热点。
• 检查Unicorn的worker数量配置：Rails 4.2+本身内存占用比3.2高，若worker数量过多，会导致总内存飙升。1GB dyno建议设置2个worker，避免进程内存叠加。
• 排查Gemfile新增依赖：升级Rails时可能引入更多gem，部分gem内存占用较高，尝试移除不必要的依赖。

内容的提问来源于stack exchange，提问作者mekdigital