2017-03-12 3 views
2

最近、私たちのRais 4.2.7.1アプリに毎晩問題が発生しましたが、トラフィックは比較的少なくても、遅いActiveRecord::QueryCache#callコールを見ています夜の真ん中:我々はSidekiqを使用しているためActiveRecord :: QueryCache#pog:backupsを使用してHerokuで遅く

NewRelic Dashboard

私たちは、プーマやアプリを使用してHerokuの上で実行しているが、非常に仕事の重いです。日中は正常に動作しますが、毎晩、ActiveRecord::QueryCache#callに由来すると思われるAPIを使用して、非常に遅い応答時間のこれらのスパイクを取得します。

私たちのアプリから私たちが見つけることができるのは、heroku pg:backupsが有効になっていることだけです。上記の画像の夜は、3:06の時点でバックアップが開始されました。最初にActiveRecord::QueryCache#call新しいグラフのスパイク。しかし、バックアップは1時間後に終了しました(最大のスパイク周り)が、あなたが見ることができるようにスパイクは約5amまで続きました。

これはpg:backupsによって引き起こされる可能性がありますか? (私たちのデータベースは約19GBです)、それとも全く別のものかもしれませんか?このキャッシュコールを避けるか、スピードアップするよい方法はありますか?私はそれが遅いか、または取引リストに全く存在しないのかを完全に理解していません。どんな勧告?

答えて

2

似たような現象が見られたのを覚えておいてください。大規模なデータベースでは、pg:backupsによって明らかにパフォーマンスが低下します。

Load average

DBサイズは> 100ギガバイト

ある

それは驚くことではありませんし、実際Herokuの中で示唆している、この上 documentationを持っています:ときにバックアップキックで、ちょうど午前1時後に大きなスパイクに注意してください20GB未満のデータベースの場合にのみ pg:backupsを使用する必要があります。

大規模なデータベースの場合は、フォロワーを作成し、そこからバックアップをとることが望ましいです。高可用性データベースの場合、スタンバイから読み取ることはできません。


私もActiveRecord::QueryCacheに多くの光を当てることができないので、この記事の残りの部分は憶測、そしてさらなる調査のために多分出発点です。より多くの知識豊富誰かが:-)で重量を量ることができるかどう修正/削除ハッピー

非Postgresはをキャッシュからバックアッププロセスがうまくキャッシュされたデータを追い出しますので、これはそのキャッシュが多くの再増殖あなたの労働者を代表することができると言うのですHerokuののドキュメント回以上。

thisもご覧ください。あなたの従業員は接続を再利用して、汚れたクエリキャッシュを受け取ることができますか?

+0

私は 'pg:backups'とデータベースサイズに関する同じドキュメントを見に行きました。興味深いことに、データベースは約40GBでしたが、これは問題ではないようです。しかし、私は一晩(連続的な保護に頼って)それを無効にして、それが違いを生むかどうかを調べるつもりです。 – goddamnyouryan

関連する問題