使用pg:backups

时间:2017-03-12 18:50:18

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

最近我们每晚都在使用我们的Rais 4.2.7.1应用程序时出现问题,即使我们的流量在半夜相对较低,我们也会看到一堆非常慢的ActiveRecord::QueryCache#call电话:

NewRelic Dashboard

我们使用Puma在Heroku上运行,应用程序非常繁重,我们使用Sidekiq。在白天它工作正常,但每天晚上我们通过似乎源自ActiveRecord::QueryCache#call的API获得极慢的响应时间峰值。

我可以从我们的应用程序中找到可能导致此问题的唯一一件事是我们启用了heroku pg:backups,并且上面图像的夜晚备份开始在3:06运行,这是您第一次看到的确切时间新图表中出现ActiveRecord::QueryCache#call峰值。一小时后,备份结束了(在最大的峰值附近),但是你可以看到峰值一直持续到凌晨5点左右。

这可能是由pg:backups引起的吗? (我们的数据库大约是19GB),还是完全可能是其他东西?有没有一种好方法可以避免这种缓存调用或加快速度?我不完全明白为什么在交易清单中它会如此缓慢或存在。有什么建议吗?

1 个答案:

答案 0 :(得分:2)

有趣的是,我们在看到类似的行为之后,最近一直在调查这个问题。 pg:backups对大型数据库造成了明显的性能损失。注意凌晨1点之后的大峰值,当备份开始时:

Load average

数据库大小> 100GB

这并不奇怪,事实上Heroku确实有documentation,这表明你应该只对{20}以下的数据库使用pg:backups

对于较大的数据库,创建关注者并从中获取备份是可取的。令人讨厌的是高可用性数据库,您似乎无法从备用数据库中读取数据。

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

Heroku的文档确实说备份进程会从非Postgres缓存中驱逐缓存数据,因此这可能代表您的工作人员多次重新填充该缓存。

看看this也许值得。您的工作人员可以重用连接并接收脏查询缓存吗?