2

私は Rails を初めて使用し、最初のアプリを Heroku (無料利用枠) にデプロイしました。New Relic の無料トライアルを設定し、可用性の監視を /register/ URL に 1 分ごとに ping するように設定しました。Rails 3.2.13 と Ruby 1.9.3 を実行しています。

私のアプリには基本的にユーザーもリクエストもありません (1 分あたり 2 つのリクエストで、ほとんどが NewRelic からのものです)。バックグラウンド サービスや外部依存関係はありません。データ モデルはシンプルで、100 ミリ秒以上かかるクエリはありません。

数時間ごとに正確に 15 分間完全に停止しています。

ここに画像の説明を入力

Heroku は 1500 行のログしか保持しないため、各インシデントのデータはありませんが、2 番目のブリップのログを次に示します (私のグラフは -0400、Heroku は UTC です)。

完全なログ: https://gist.github.com/jbinto/5495226/raw/ba61ec16d9655287466cfbb9328f59c0171b2df7/heroku.log

概要

  • 00:56:21 から 01:00:21:通常どおり、1 分間に 1 つのリクエストを送信します。
  • 01:01:55: 受信した最後のリクエストは処理されていないようです。
  • 01:02:21 から 01:17:21: 54 H12 (要求タイムアウト) エラー。
  • 01:17:25: PG::Error (SSL SYSCALL エラー: EOF が検出されました) (余談: Heroku のログ ステートメントの順序が間違っていることに気付きました。奇妙なことです。)

この PG::Error は私の問題の原因ですか、それとも単なる症状ですか? 一部のグーグルは、スターター層での Postgres タイムアウトに関する議論と、プロダクション層を使用しないいくつかの警告を示しています: https://groups.google.com/forum/?fromgroups=#!topic/heroku/a6iviwAFgdY

詳細 StackOverflow: Postgres + Heroku SSL SYSCALL エラー

自動再接続に関する Rails チケット: https://github.com/rails/rails/issues/9421

これは良い手がかりのように見えますが、誰もこれを解決していないようです. Heroku の Postgres に不安定性があるようで、Rails<4 はこれからうまく回復しません。

  • 01:17:26 から 01:17:27: 58 の GET リクエストが「処理されました」(これらはキューに入れられたリクエストだと思いますか? 30 秒のタイムアウトのために、クライアントは長い間消えています。なぜこれらのリクエストがまだ処理されているのですか?)
  • 01:17:51:すべて正常に戻りました。

何か案は？Heroku のサポート チケットを開くつもりですが、無料のユーザーとしてどこにでも行けるかどうかはわかりません。

4

1 に答える 1

3

答えはここにあります：

T01:02:21.144033+00:00 heroku[router]: at=error code=H12 desc="Request timeout" method=HEAD path=/register host=www.puckpicks.ca fwd="50.18.57.7" dyno=web.1 connect=1ms service=30000ms status=503 bytes=0

通常、このパターンは、1 つの実行時間の長いアクションがそれ以降のすべてのリクエストのキューを占有し始める場合に見られます。

Heroku ルーターは 30 秒後に実行時間の長いリクエストを破棄しますが、その背後にある dyno は完了するまでリクエストの処理を続けます。ただし、ルーターはそれを認識していないため、新しいリクエストをビジー状態の dyno にディスパッチします。この影響はさらに大きくなる傾向があり、New Relic でキューイングが発生し、最終的には静的アセットなどの無関係な URL に対しても H12 エラーが発生します。

長時間実行されるリクエストが dyno レベルでもドロップされるようにする、rack-timeout のようなものをインストールすることをお勧めします。具体的には、rack-timeout は、それが発生したときに TimeoutError を発生させます。https://github.com/kch/rack-timeout

これにより、複合効果が発生する可能性は低くなりますが、長時間実行されるアクションにはまだ対処する必要があります. New Relic は、長時間実行されているアクションを特定するためにアプリを可視化する優れたツールです。次に、それらを最適化し、妥当な時間内に終了できることを確認します。すべてのリクエストを 500 ミリ秒未満に保つことをお勧めします。彼らが本質的に長いタスクを実行している場合は、それらをバックグラウンド ワーカーにオフロードするようにしてください。

トラフィックの多い運用アプリケーションを使用している場合は、アプリが同時リクエストを処理できるように、Unicornをまだ使用していない場合は使用することをお勧めします。これにより、同時実行性が向上し、キュー時間が短縮され、各 dyno の全体的なパフォーマンスが向上します。

于 2013-05-01T14:27:48.760 に答える