10

Heroku にデプロイされた Django アプリがあり、ワーカー プロセスがセロリを実行しています (+ 監視用のセロリカム)。RedisToGo の Redis データベースをブローカーとして使用しています。Redis のメモリが不足していることに気付きました。

これは私のprocfileがどのように見えるかです：

web: python app/manage.py run_gunicorn -b "0.0.0.0:$PORT" -w 3
worker: python lipo/manage.py celerycam & python app/manage.py celeryd -E -B --loglevel=INFO

KEYS '*' の出力は次のとおりです。

  1. "_kombu.binding.celeryd.pidbox"
  2. 「celeryev.643a99be-74e8-44e1-8c67-fdd9891a5326」
  3. "celeryev.f7a1d511-448b-42ad-9e51-52baee60e977"
  4. "_kombu.binding.celeryev"
  5. "celeryev.d4bd2c8d-57ea-4058-8597-e48f874698ca"
  6. `_kombu.binding.celery"

celeryev.643a99be-74e8-44e1-8c67-fdd9891a5326次のメッセージでいっぱいになっています。

{"sw_sys": "Linux", "clock": 1, "timestamp": 1325914922.206671, "hostname": "064d9ffe-94a3-4a4e-b0c2-be9a85880c74", "type": "worker-online", "sw_ident": "celeryd", "sw_ver": "2.4.5"}

これらのメッセージを定期的にパージするために何ができるか考えていますか?

4

1 に答える 1

1

それは解決策ですか？

  1. _kombu.bindings.celeryev セットに加えて、例えば celeryev.i-am-alive があります。TTL が設定されたキー (例: 30 秒)。
  2. celeryev プロセスはバインディングに自身を追加し、定期的に (たとえば 5 秒ごとに) celeryev.i-am-alive を更新します。TTL をリセットするキー。
  3. イベント ワーカー プロセスを送信する前に、_kombu.bindings.celeryev のメンバーだけでなく、個々の celeryev.i-am-alive もチェックします。キーが見つからない (期限切れ) 場合は、_kombu.bindings.celeryev から削除されます (そして、おそらく del celeryev. または expire celeryev. コマンドが実行されます)。

N は DB 内のキーの総数である O(N) であるため、keys コマンドだけを使用することはできません。ただし、2.1 未満の redis では TTL は扱いにくい場合があります。

celeryevを期限切れにします。デル・セレリエフの代わりに。一時的にオフラインの celeryev コンシューマを復活させるために使用できますが、それが価値があるかどうかはわかりません。

著者

于 2012-02-13T04:09:20.587 に答える