ActiveRecord::QueryCache#call slow on Heroku with pg:backups答案

【问题标题】：ActiveRecord::QueryCache#call slow on Heroku with pg:backupsActiveRecord::QueryCache#call slow on Heroku with pg:backups
【发布时间】：2017-08-02 18:15:57
【问题描述】：

最近我们的 Rais 4.2.7.1 应用程序每晚都遇到问题，我们开始看到一堆非常慢的 ActiveRecord::QueryCache#call 呼叫，即使我们在半夜的流量相对较低：

我们使用 Puma 在 Heroku 上运行，该应用程序的工作量很大，为此我们使用 Sidekiq。白天它运行良好，但每天晚上我们都会通过似乎源自 ActiveRecord::QueryCache#call 的 API 获得响应时间极慢的峰值。

我可以从我们的应用程序中找到可能导致此问题的唯一原因是我们启用了 heroku pg:backups，并且在上图的当晚，备份在 3:06 开始运行，这是您第一次看到的确切时间ActiveRecord::QueryCache#call newrelic 图中的峰值。然而，备份在一小时后完成（大约在最大峰值附近），但正如您所见，峰值一直持续到凌晨 5 点左右。

这可能是由 pg:backups 引起的吗？（我们的数据库大约 19GB），或者它可能完全是别的东西？有没有避免这种缓存调用或加快它的好方法？我不完全理解为什么它会这么慢或根本不存在于交易列表中。有什么建议吗？

【问题讨论】：

标签： ruby-on-rails ruby postgresql heroku activerecord

【解决方案1】：

有趣的是，我们最近在看到类似行为后一直在对此进行调查。 pg:backups 对大型数据库造成了一定的性能影响。请注意凌晨 1 点之后的大峰值，此时备份开始：

数据库大小>100GB

这并不奇怪，事实上 Heroku 确实有documentation，这表明您应该只对 20GB 以下的数据库使用pg:backups。

对于较大的数据库，最好创建一个追随者并从中获取备份。令人烦恼的是，对于高可用性数据库，您似乎无法从备用数据库中读取数据。

不过，我无法对ActiveRecord::QueryCache 有太多了解，所以这篇文章的其余部分只是猜测，也许是进一步调查的起点。如果更有知识的人可以参与进来，很高兴删除/修改:-)

Heroku 的文档确实说备份过程将从非 Postgres 缓存中清除缓存良好的数据，因此这可能表示您的工作人员多次重新填充该缓存。

this 也值得一看。您的工作人员是否会重用连接并接收脏查询缓存？

【讨论】：

我刚刚遇到了关于pg:backups 和数据库大小的相同文档。有趣的是，我们的数据库过去大约是 40GB，当时这似乎不是问题。但我会尝试禁用它一晚（依靠持续保护），看看是否有什么不同。