ruby-on-rails - ActiveRecord::QueryCache#call slow on Heroku with pg:backups

Question

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

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

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

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

Answer 1

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

数据库大小 >100GB

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

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

---

虽然我不能对 ActiveRecord::QueryCache 有太多的了解，所以这篇文章的其余部分是猜测，也许是进一步调查的起点。如果更有知识的人可以权衡，很乐意删除/修改 :-)

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

可能还值得一看 this .您的工作人员是否会重复使用连接并接收脏查询缓存？