大约两周前，我将我的应用程序（Flask + SQLAlchemy在Postgres之上）部署了一些更改到Heroku。我的dynos的响应时间很快就会上升，响应的时间也开始了。在这些问题开始之前，当前应用程序的版本已经运行了大约2-3个月。
当然，我怀疑我在应用程序中的更改并通过它们，但没有与此相关（前端的更改，用HTML替换纯文本电子邮件，应用程序使用的静态数据的微小更改） ）。
我有一个应用程序的副本用于测试目的，所以我克隆了生产数据库的最新备份并开始调查（克隆是一些45GiB，相比原始的56GiB，但这似乎是正常的结果＆＃34;腹胀＆＃34;。）
事实证明，即使是微不足道的请求也会花费大量的时间进行制作，而他们则按照自己应有的方式进行测试。例如，select * from A where some_id in (three, int, values)在测试时花费不到0.5秒，在prod上花费12-15秒（A具有3M记录，some_id是更小表的外键。即使select count(*) from A也需要相同的时间，因此它不会编制索引或类似的内容。
这与特定查询甚至表格无关，因此消除了我对我的代码的疑虑，因为大部分代码在几个月内保持不变，并且在这些问题开始之前一直运行良好。
进一步研究，我发现日志包含数据库服务器的平均负载，我的生产者显示load-avg 22（我在Papertrail中搜索了postgres load-avg），它似乎几乎不变（在很长一段时间内缓慢上升）。
我将生产数据库从Postgres 9.6 / Standard 2计划（尽管我的连接数约为105/400，缓存命中率为100％）升级到Postgres 10 / Standard 3计划，但这并没有做一点改进。此升级还意味着大约30-60分钟的停机时间。将应用程序重新启动后不久，数据库服务器的负载很高（遗憾的是，在停机期间我没有检查）。此外，数据库服务器的负载似乎没有反映应用程序使用情况的峰值（该应用程序主要用于美国和欧盟，以及通常的应用程序的负载反映了这一点。
此时，我没有想法（除了联系Heroku的支持，我的同事会这样做）并且会感谢任何有关接下来要做什么的建议。
答案 0 :(得分：1)
我最终从standard-2升级到standard-7，我的数据库负载下降到0.3-0.4左右。我没有解释为什么它突然开始。