或者更确切地说，为什么没有更好的工具来分析ruby中的内存，特别是rails应用程序？
最近我们的rails应用程序（在heroku上托管）已经开始在工作人员dynos中看到很多R14错误。这意味着我们的内存不足。将dynos压缩到2x（512mb - > 1GB）只能暂时缓解这个问题，让我相信某处存在内存泄漏。当然，我的下一步是找到一个很好的剖析宝石，可以帮助我发现泄漏的来源。
也许我只是不知道可用的工具，或者我只是不知道如何使用我拥有的工具。我的愿望是我可以安装gem然后运行内存使用情况统计报告。点击一个端点来获取报告并不是真的可行，因为我的内存问题被隔离到工作人员dynos运行延迟的工作。
我看过memprof，但它只有1.8。
我看过ruby-prof（太棒了），但是内存分析需要一个修补的ruby解释器。
我看过GC::Profiler，但我不明白如何用它找到内存泄漏。
那么，在ruby中找到内存泄漏是否很难？或者我不知何故错过了这一点？
答案 0 :(得分：4)
根据您的“泄漏类型”，您可以对ruby运行valgrind。可能需要重新编译。一般来说，这很难，因为默认情况下，ruby会在不触发任何事件的情况下进行方法分配，因此跟踪是很棘手的。另请参阅perftools.rb project，这有点适用于此限制。
答案 1 :(得分：1)
最近，我使用Skylight成功地分析了网络和后台工作者方法，然后寻找优化机会。你发布这个问题可能不在身边。缺点是它只能真正帮助您调试分段或生产，而不是开发环境，因此dev循环可能非常慢。
如果您使用的是Sidekiq，请确保同时安装skylight-ruby和sidekiq-skylight以便对您的网络服务器和后台工作人员进行分析。
祝你好运！答案 2 :(得分：0)
如果您的应用程序在具有dtrace或类似SystemTap之类的操作系统上运行，则是一种不错的方法。在我的情况下，我们使用具有后者的RHEL / CentOS：
https://lukas.zapletalovi.com/2016/08/probing-ruby-20-apps-with-systemtap-in-rhel7.html
您可以轻松连接到生产应用程序并暂时“插入”配置文件代码并跟踪调用，内存，CPU时间或I / O，然后随时“断开连接”。这非常有效，因此您不会注意到任何急剧的减速（除非您弄乱了脚本）。
答案 3 :(得分：-5)
我不同意Ruby中的内存分析很难。 JVM拥有一些世界上最好的内存分析工具，您可以在JVM上运行Ruby程序。不要重新发明轮子。