两天前，我将我们的 Heroku Postgres 服务器从 Kappa 升级到了 Ronin。我们的数据库高达数 GB，我认为额外的 ram 将有助于缓存。我使用了标准的快速交换技术（创建追随者、允许转移、提升追随者）。我知道缓存可能需要一些时间来预热，但已经有好几天了，而且它一直在减速。
我们较小的数据库运行大约 5 毫秒的响应时间。新数据库在传输（冷缓存）后跳转到大约 10 毫秒。此后它在 10 毫秒和 20 毫秒之间波动。
是否有一些可能不同的配置？我知道每个应用程序都不同，但缓存现在不应该升温吗？Kappa 和 Ronin 之间是否有任何未记录的差异？
谢谢
我以前见过一个客户，他打电话给我寻求紧急帮助。
经过一番摸索，heroku bash我们最终得出结论，新实例位于特别繁忙的底层服务器上。我们通过将追随者提升到另一台机器进行了故障转移，此时性能大大提高 - 尽管由于主服务器的问题，故障转移本身具有挑战性。
据我所知，Heroku 的实例是运行 LXC 容器以隔离每个 Heroku 用户的数据库集群的 Amazon EC2 节点（Xen VM）。与完整的 VM 相比，LXC 提供的隔离要少得多；实例可以竞争 RAM、磁盘 I/O、CPU 等，具体取决于使用 OpenCZ 配置的确切策略、任何控制组策略等。
如果您在其他用户没有做太多事情的实例上，并且如果容器允许您的数据库使用其他用户当前不需要的资源，您很容易看到稳定高于保证的性能。
我怀疑使用较大 heroku 计划的人更有可能实际使用与您共享容器的系统资源。
如果您将升级故障转移到所有用户都在那里的更大实例，因为他们确实需要更大机器提供的资源，那么您实际上可以获得更少的资源，因为每个人实际上都在使用他们的份额。
令人沮丧的是，Heroku 对运行其数据库的系统的可见性如此之低。很难说它们如何/是否在容器主机之间进行负载平衡，系统上的底层负载是什么等。
在评论中，@Forrest 指出 Heroku 在其服务器详细信息上有一个有用的页面，显示只有较低层是多租户的，但较高层不是。这很容易解释这里观察到的性能损失，并且符合我上面的评论，即较低的计划允许 Forrest 从其他用户那里借用未使用的资源。