或者更确切地说,为什么没有更好的工具来分析ruby中的内存,特别是rails应用程序？
最近我们的rails应用程序(在heroku上托管)已经开始在工作人员dynos中看到很多R14错误.这意味着我们的内存不足.将dynos压缩到2x(512mb - > 1GB)只是暂时缓解了这个问题,让我相信某处存在内存泄漏.当然,我的下一步是找到一个很好的分析宝石,可以帮助我发现泄漏的来源.
也许我只是不知道可用的工具,或者我只是不知道如何使用我拥有的工具.我的愿望是我可以安装gem然后运行内存使用情况统计报告.点击一个端点来获取报告并不是真的可行,因为我的内存问题被隔离到工作dynos运行延迟的工作.
我看过memprof,但它只有1.8.
我看过ruby-prof(真棒),但是内存分析需要一个修补的ruby解释器.
我看过GC :: Profiler,但我不明白如何用它找到内存泄漏.
那么,在ruby中找到内存泄漏是否很难？或者我不知何故错过了这一点？
因此，根据 Amazon 的 DynamoDB错误处理文档，您有时可能会收到 500 个错误，这是预期的行为（它们没有指定发生这种情况的原因或频率）。在这种情况下，您应该使用指数退避来实现重试，从大约 50 毫秒开始。
就我而言，我正在并行处理和批量写入大量数据（30 个节点，每个节点运行大约 5 个并发线程）。我预计这需要很长时间。
我的哈希键相当平衡（user_id），并且我的吞吐量设置为 20000 个写入容量单位。
当我开始运转时，一切都开始得很好。我达到了吞吐量并开始后退，有一段时间我在最大容量周围很好地振荡。然而，很快我就开始收到大量 500 条响应，其中以 InternalServerError 为例外。当然，没有提供其他信息。我不断地后退，直到我在重试之间等待大约 1 分钟，一切都停止了，我根本不再得到 200 秒。
我觉得我的查询肯定有问题，或者可能是具体的查询有问题，但我没有办法调查。除了“内部”和“错误”部分之外，根本没有关于从服务器返回的错误的信息。
哈尔普？