升级后 Heroku Postgres DB 变慢

Question

两天前，我将我们的 Heroku Postgres 服务器从 Kappa 升级到 Ronin。我们的数据库高达几 GB，我认为额外的内存将有助于缓存。我使用了标准的快速交换技术（创建关注者、允许转移、提升关注者）。我知道缓存可能需要一些时间来预热，但已经有好几天了，而且速度一直在变慢。

我们较小的数据库的响应时间约为 5 毫秒。传输后新的 DB 跳到大约 10ms（冷缓存）。此后，它在 10 毫秒和 20 毫秒之间波动。

是否有一些可能不同的配置？我知道每个应用程序都不同，但现在缓存不应该已经升温了吗？Kappa 和 Ronin 之间是否有任何未记录的差异？

谢谢

Answer 1

我之前在一位客户那里见过这种情况，他打电话给我寻求紧急帮助。

经过一番摸索，heroku bash我们最终得出结论，新实例位于特别繁忙的底层服务器上。我们通过从机升级到另一台机器进行了故障转移，此时性能大大提高 - 尽管由于主站的问题，故障转移本身具有挑战性。

据我所知，Heroku 的实例是运行 LXC 容器以隔离每个 Heroku 用户的数据库集群的 Amazon EC2 节点（Xen VM）。LXC 提供的隔离比完整的 VM 少得多；实例可以争用 RAM、磁盘 I/O、CPU 等，具体取决于使用 OpenCZ 配置的确切策略、任何控制组策略等。

如果您在一个其他用户没有做太多事情的实例上，并且如果容器允许您的数据库使用其他用户当前不需要的资源，您很容易看到稳定高于保证的性能。

我怀疑较大的 heroku 计划的人更有可能实际使用与您共享容器的系统资源。

如果您将升级故障转移到一个更大的实例，其中所有用户都在那里，因为他们确实需要更大机器提供的资源，您实际上可以获得更少的资源，因为每个人实际上都在使用他们的份额。

令人沮丧的是，Heroku 对运行其数据库的系统提供的可见性如此之少。很难说它们如何/是否在容器主机之间进行负载平衡，系统上的底层负载是什么等等。

在评论中，@Forrest 指出 Heroku 在他们的服务器详细信息上有一个有用的页面，表明只有较低层是多租户的，但较高层不是。这很容易解释这里观察到的性能损失，并且符合我上面的评论，即较低的计划允许 Forrest 从其他用户借用未使用的资源。