如何调试引发“错误 R15（内存配额大大超出）”的 ajax 请求答案

【问题标题】：How to debug an ajax request raising "Error R15 (Memory quota vastly exceeded)"如何调试引发“错误 R15（内存配额大大超出）”的 ajax 请求
【发布时间】：2017-08-04 18:25:26
【问题描述】：

我在 Heroku 上有一个 Rails 应用程序，它与 Error R15 (Memory quota vastly exceeded) 崩溃。

我已将此问题跟踪到包含多个异步请求的页面。这些错误似乎与构建远程datatables 的ajax 请求一致。

问题是，我无法弄清楚为什么会出现这些错误。

我认为也许 ajaxified 数据表背后的数据库查询和控制器操作可能运行缓慢。但是，如果我在开发中使用 miniprofiler 检查这些请求，这些请求会显得非常有效。

然后我想，也许服务器正在同时接收多个请求，这使 heroku dyno 过载。但是我将测功机提高到一个非常高的数字，但仍然看到错误。

什么是开始识别和调试导致此内存错误的原因的明智方法？我以前不必解决这样的问题。

【问题讨论】：

您在生产中是否有一个非常大的数据库？在这种情况下，您可能希望我们使用 pgbackups 来镜像数据库并在开发中针对它运行一些指标。罪魁祸首通常是一对多关系，其中自动加载会将大量记录加载到内存中。
感谢@max。生产数据库比开发数据库大，但不是很大。最大的模型是
这很难回答，因为它完全取决于查询是什么——但是是的，rails 不会加载查询未获取的记录。经常发生的情况是，如果您执行Foo.joins(:bars).limit(10)，则LIMIT 子句应用于foos 而不是bars。
感谢@max（抱歉回复缓慢）。这些查询使用includes 而不是joins，同样的问题适用吗？如果是这样，减少内存开销的最佳方法是什么？之前没遇到过这个问题，能推荐一下吗？

标签： ruby-on-rails heroku puma

【解决方案1】：

内存是在 Heroku 上按 dyno 分配的，因此如果是代码级的，添加更多 dyno 可能不会真正解决问题，因为它会导致每个 dyno 单独超出其内存限制，从而花费你很多钱而不是真正解决问题问题。

最好水平缩放并使用 Performance-L 测功机。这将使每个测功机的内存增加到 14GB。然后，您可以使用指标来查看正在使用的内存量。如果用户内存量用完所有 14GB，那么您的依赖项之一可能存在内存泄漏。

【讨论】：

感谢@Max Woolf。识别是否存在内存泄漏的最佳方法是什么？奇怪的是，这个问题只发生在少数 ajax 请求上，尤其是所有这些请求都在执行分页查询，所以只有 10 条记录应该加载到内存中。如何识别正在消耗内存的内容？