10

我有一个部署到 Heroku 的 Django 应用程序，其中一个工作进程运行 celery（+ celerycam 用于监控）。我使用 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. 命令）。

我们不能只使用 keys 命令，因为它是 O(N)，其中 N 是 DB 中的键总数。不过，在 redis < 2.1 上，TTL 可能会很棘手。

过期celeryev。而不是del celeryev。可以用来让临时离线的celeryev消费者复活，但我不知道是否值得。

作者

于 2012-02-13T04:09:20.587 回答