2

現在、Python Heroku アプリの一部のリクエストに 30 秒以上かかる理由を理解しようとしています。まったく何もしない単純な要求でさえ。

私が行ったことの 1 つは、dyno の負荷平均を調べることです。私は3つのことをしました：

1) Heroku のログを確認します。時々、負荷が出力されます。以下に例を示します。

Mar 16 11:44:50 d.0b1adf0a-0597-4f5c-8901-dfe7cda9bce0 heroku[web.2] Dyno load average (1m): 11.900

Mar 16 11:45:11 d.0b1adf0a-0597-4f5c-8901-dfe7cda9bce0 heroku[web.2] Dyno load average (1m): 8.386

Mar 16 11:45:32 d.0b1adf0a-0597-4f5c-8901-dfe7cda9bce0 heroku[web.2] Dyno load average (1m): 6.798

Mar 16 11:45:53 d.0b1adf0a-0597-4f5c-8901-dfe7cda9bce0 heroku[web.2] Dyno load average (1m): 8.031

2) "heroku run uptime" を数回実行し、そのたびに別のマシンにアクセスします ("hostname" を実行して確認)。以下は、たった今の出力例です。

13:22:09 up 3 days, 13:57, 0 users, load average: 15.33, 20.55, 22.51

3) psutil を使用してメトリクスをグラファイトに送信することにより、dyno が存在するマシンの負荷平均を測定します。グラフは、5 から 20 の間の数字を確認します。

これが単純なリクエストに非常に時間がかかることを説明しているのかどうかはわかりませんが、Heroku の負荷平均値が非常に高い理由を誰か教えていただけますか?

4

2 に答える 2

1

Heroku は、LXC を介して使用しているゲスト 'Dyno' にホストをサブ仮想化します。「稼働時間」を実行すると、コンテナーではなくホスト全体の稼働時間が表示されます。@ jon-mountjoy が指摘したように、これを実行すると、実行中の Dyno の 1 つではなく、新しい LXC コンテナーが取得されます。

Heroku の dyno 負荷計算も、従来の UNIX/LINUX 負荷計算とは異なります。

Heroku 負荷平均は、準備完了キュー (つまり、処理待ち) にある CPU タスクの数を反映しています。dyno マネージャーは、各 dyno の実行可能なタスクの数を約 20 秒ごとに取得します。指数関数的に減衰された移動平均は、期間が 1 分、5 分、または 15 分 (秒単位) の場合、直前の 30 分間の実行可能なタスクの数で計算されます。count_of_runnable_tasks は、キュー内のタスク数のエントリです。 avg は、最後の反復から計算された前回の指数負荷平均です。

Heroku の負荷平均と Linux の違いは、Linux には割り込み不可能なスリープ状態 (通常はディスク アクティビティを待機中) のプロセスも含まれていることです。これは、I/O のビジー状態または停止により多くのプロセスが I/O でブロックされたままになると、著しく異なる結果につながる可能性があります。 O系。

CPU バウンドの Dyno では、これは大きな違いにはならないと思います。IO バウンドの Dyno では、Heroku によって報告される負荷平均は、LXC コンテナーで真のアップタイムを得ることができた場合に得られるものよりもはるかに低くなります。

log-runtime-metrics を有効にすることで、実行中の dyno の定期的な負荷メッセージの送信を有効にすることもできます

于 2015-08-12T17:33:17.887 に答える
0

おそらくダイノアイドリングが予想されますか？

PS。実行しても意味がないと思いますheroku run uptime-毎回新しい1回限りのdynoで実行されます。

于 2013-03-17T15:25:14.370 に答える