緊急の助けを求めて私に電話をかけてきたクライアントと一緒にこれを見たことがあります。
heroku bashをいじくり回した後 最終的に、新しいインスタンスは特にビジーな基盤サーバー上にあると結論付けました。別のマシンへのフォロワープロモーションを介してフェイルオーバーを実行しました。その時点でパフォーマンスが大幅に向上しましたが、マスターの問題のためにフェイルオーバー自体は困難でした。
私の知る限り、Herokuのインスタンスは、LXCコンテナーを実行して各Herokuユーザーのデータベースクラスターを分離するAmazon EC2ノード（Xen VM）です。 LXCは、完全なVMよりも分離が少なくなります。インスタンスは、OpenCZで構成された正確なポリシー、任意のコントロールグループポリシーなどに応じて、RAM、ディスクI / O、CPUなどをめぐって競合する可能性があります。
他のユーザーがあまり行っていないインスタンスを使用していて、コンテナーがDBに他のユーザーが現在必要としないリソースの使用を許可している場合、保証されたパフォーマンスよりも着実に高いパフォーマンスを簡単に確認できます。
大規模なherokuプランを使用している人は、コンテナを共有しているシステムのリソースを実際に使用している可能性が高いと思います。
より大きなマシンによって提供されるリソースが本当に必要なため、すべてのユーザーがそこにいるより大きなインスタンスにプロモーションフェイルオーバーを行うと、実際には少なくなる可能性があります。 誰もが実際に自分の共有を使用しているため、全体的なリソース。
HerokuがDBを実行するシステムの可視性をほとんど提供していないのはイライラします。コンテナホスト間の負荷分散の方法/かどうか、システムの基本的な負荷などを判断するのは困難です。
コメントの中で、 @Forrestは、Herokuには便利な機能があると指摘しました。サーバーの詳細のページ 、下位層のみがマルチテナントであり、上位層はそうではないことを示しています。これは、ここで観察されたパフォーマンスの低下を簡単に説明し、より低い計画ではForrestが他のユーザーから未使用のリソースを借りることを許可していたという上記の私のコメントと一致します。