5

HerokuでエラーR14（メモリクォータを超えました）が発生し続けます。

djangoアプリのメモリをローカルでプロファイリングする問題はありません。New Relicをインストールしましたが、奇妙な点を除いて、問題はないようです。

http://screencast.com/t/Uv1W3bjd

メモリ使用量はdynoあたり約15mbですが、何らかの理由で「dynosrunning」はすぐに10+にスケールアップします。現在、Web dynoでのみ実行しているため、それがどのように意味があるのか​​わかりません。

セロリも走っていますが、そこも普通に見えます（約15mb）。これが起動したときにエラーが発生し始めたと思うので疑わしいですが。

一部のリクエストは、echosignへのsoapリクエストを実行するため、時間がかかる場合があります。これには、応答に6〜10秒かかる場合があります。これはどういうわけかブロックされ、新しいダイノがスピンアップする原因になっていますか？

これが私のprocファイルです：

web: python manage.py collectstatic --noinput; python manage.py compress; newrelic-admin run-program python manage.py run_gunicorn -b "0.0.0.0:$PORT" -w 9 -k gevent --max-requests 250
celeryd: newrelic-admin run-program python manage.py celeryd -E -B --loglevel=INFO

ただし、主な問題はメモリエラーです。

4

1 に答える 1

14

私は問題を見つけたかもしれないと信じています。

このような投稿に基づいて、私は9〜10人のgunicornの労働者の領域のどこかにいるべきだと思いました。これは正しくないと思います（または、少なくとも、私のアプリが行っている作業のためです）。

私は9人のgunicornワーカーを実行していましたが、最終的に、それがherokuとlocalの唯一の本当の違いであることに気付きました（構成に関して）。

gunicornの設計ドキュメントによると、労働者へのアドバイスは次のようになります。

ワーカーの数を、予想されるクライアントの数に合わせないでください。Gunicornは、1秒あたり数百または数千のリクエストを処理するために4〜12のワーカープロセスのみを必要とします。

Gunicornは、オペレーティングシステムに依存して、リクエストを処理するときにすべての負荷分散を提供します。通常、開始するワーカーの数として（2 x $ num_cores）+1をお勧めします。過度に科学的ではありませんが、この式は、特定のコアについて、一方のワーカーがソケットから読み取りまたは書き込みを行い、もう一方のワーカーが要求を処理しているという仮定に基づいています。

そして、Heroku DynoのCPU能力に関する情報がありますが、各dynoがコアの約1/4で実行されていることを読みました。それほど強力ではありませんが、十分に強力だと思います。

少なくとも今のところ、私の労働者を3（大まかな公式によればさらに高い）にダイヤルダウンすることで、私の記憶の問題を止めたようです。私がそれについて考えるとき、私が得るであろう記憶警告についての興味深いことは、それが決して上がらないということです。それは約103％に達し、それからそこにとどまりましたが、それが実際にリークであった場合、シャットダウンされるまで上昇し続けるはずでした。したがって、私の理論では、私のワーカーは最終的に512MBを超えるのに十分なメモリを消費していました。

HEROKUはこの情報をどこかに追加する必要があります!! そして、少なくとも、top何が起こっているのかを確認するために、実行中のダイノに入ることができるはずです。私に何時間も何日も節約できただろう。

于 2012-08-23T05:53:09.477 に答える