升级后Heroku Postgres DB较慢

本文介绍了升级后Heroku Postgres DB较慢的处理方法，对大家解决问题具有一定的参考价值，需要的朋友们下面随着小编来一起学习吧！ 问题描述

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

我们较小的数据库运行大约5毫秒的响应时间。转移后新的数据库跳到了大约10ms（冷藏）。它已经在10ms和20ms之间波动。

• 新的数据库运行完全相同的版本（9.2.4）。
• 我注意到有更多的日志记录发生（检查点）。
• 旧数据库的数据库高速缓存命中/未命中为〜0.91，因此为更新。新的数据库已经达到了类似的命中/未命中，所以我认为缓存的温度不再是问题。

有一些配置可能会有所不同吗？我知道每个应用程序都是不同的，但缓存现在不应该升温吗？ Kappa&公司之间是否有任何无证的差异？ Ronin？

谢谢

解决方案

一位客户打电话给我一些紧急求助。

在与 heroku bash 打成一片之后，我们最终得出结论：新实例在特别繁忙的底层服务器上。我们通过追随者升级到另一台机器进行故障转移，此时性能大大提高 - 尽管故障转移由于主机问题而具有挑战性。

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

如果你是对于其他用户执行得并不多的实例，如果容器允许您的数据库使用其他用户当前不需要的资源，则您可以轻松看到稳定高于保证的性能。

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

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

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

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

2 days ago, I upgraded our Heroku Postgres server from Kappa to Ronin. Our DB was up to several GB and I figured the extra ram would help with the cache. I used the standard fast swapping technique (create follower, allow transfer, promote follower). I know that the cache can take time to warm up, but it's been several days and it's been SLOWING down.

Our smaller DB was running around 5ms response times. The new DB jumped to about 10ms after the transfer (cold cache). It has since fluctuated between 10ms and 20ms.

• The new DB is running the exact same version (9.2.4).
• I have noticed there is more logging occurring (checkpoints).
• The db cache hit/miss from the old DB was ~0.91, hence the update. The new DB is already up to a similar hit/miss so I would expect that the warmness of the cache is no longer the issue.

Is there some config which could be different? I know that every app is different, but shouldn't the cache have warmed by now? Is there any undocumented differences between Kappa & Ronin?

Thanks

解决方案

I've seen this before with a client who called me for some emergency help.

After doing some poking around with heroku bash we eventually concluded that the new instance was on particularly busy underlying server. We did a failover via follower promotion to another machine, at which point performance greatly improved - though the failover its self was challenging due to the problems with the master.

As far as I know Heroku's instances are Amazon EC2 nodes (Xen VMs) that run an LXC container to isolate each Heroku user's database clusters. LXC offers rather less isolation than a full VM does; instances can contend for RAM, disk I/O, CPU, etc, depending on the exact policy configured with OpenCZ, any control group policies, etc.

If you're on an instance where the other users aren't doing much and if the container permits your DB to use resources that aren't currently required by other users, you could easily see steadily higher than guaranteed performance.

I suspect that people on larger heroku plans are more likely to actually be using the resources of the system you're sharing a container with.

If you do a promotion failover to a bigger instance where all the users are there because they really need the resources offered by the bigger machine you could actually get less resources overall, because everyone's actually using their shares.

It's frustrating that Heroku offer so little visibility into the systems that run their DBs. It's hard to tell how/if they load balance between container hosts, what the underlying load on the system is, etc.

In a comment, @Forrest pointed out that Heroku have a useful page on their server details, showing that only the lower tiers are multi-tenant, but higher tiers are not. This would easily explain the performance loss observed here, and would fit in with my comments above that the lower plan was allowing Forrest to borrow unused resources from other users.