大约两周前，我将我的应用程序(Flask + SQLAlchemy 在 Postgres 之上)的一些更改部署到 Heroku。我的测功机的响应时间很快就上升了，响应超时也开始了。在出现这些问题之前，当前应用程序的版本已经完美运行了大约 2-3 个月。
自然地，我怀疑我在应用程序中进行了更改并仔细检查了它们，但是与此无关(前端的更改，将纯文本电子邮件替换为 HTML 电子邮件，应用程序使用的静态数据的微小更改).
我有一个用于测试目的的应用程序副本，所以我克隆了生产数据库的最新备份并开始调查(克隆的是大约 45GiB，而原始的是 56GiB，但这似乎是“腹胀”)。
事实证明，即使是微不足道的请求也会在生产中花费大量时间，而他们却在按应有的方式处理测试请求。例如，select * from A where some_id in (three, int, values) 测试用时不到 0.5 秒，生产用时约 12-15 秒(A 有 3M记录和 some_id 是一个小得多的表的外键)。甚至 select count(*) from A 也将花费相同的时间，因此它不是索引或类似的东西。
这与特定查询甚至表无关，因此消除了我对我的代码的疑虑，因为大部分代码在几个月内没有变化并且在这些问题出现之前运行良好。
进一步研究，我发现日志包含数据库服务器的平均负载，而我的生产日志显示 load-avg 22(我搜索了 postgres load-avg 在 Papertrail 中)，并且它似乎几乎是恒定的(在很长一段时间内缓慢上升)。
我将生产数据库从 Postgres 9.6/Standard 2 计划(尽管我的连接数约为 105/400，缓存命中率为 100%)升级到 Postgres 10/Standard 3 计划，但这并没有使丝毫改善。此升级还意味着大约 30-60 分钟的停机时间。在恢复应用程序后不久，数据库服务器的负载很高(遗憾的是，我在停机期间没有检查)。此外，数据库服务器的负载似乎没有反射(reflect)应用使用情况的峰值(该应用主要在美国和欧盟使用，通常应用的负载反射(reflect)了这一点)。
在这一点上，我没有任何想法(除了联系 Heroku 的支持，这是我的一位同事会做的)，如果有任何建议，我将不胜感激。
最佳答案
我最终从 standard-2 升级到 standard-7，我的数据库负载下降到 0.3-0.4 左右。我无法解释为什么它突然开始。
关于postgresql - Heroku Postgres 上的高平均负载，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/50198734/