У Сельдерея и Редиса все время не хватает памяти

Question

У меня есть приложение Django, развернутое в Heroku, с рабочим процессом, использующим сельдерей (+ celerycam для мониторинга). Я использую RedisToGo в базе данных 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 

Вот вывод ключей '*':

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"} 

Любая идея что я могу сделать, чтобы периодически чистить эти сообщения?

Answer 1

Это решение?

1. в дополнение к _kombu.bindings.celeryev набор будет, например, celeryev.i-ам-жив. ключи с набором TTL (например, 30 сек);
2. Процесс ceralev добавляет себя к связям и периодически (например, каждые 5 секунд) обновляет ceralev.i-am-alive. ключ для сброса TTL;
3. перед отправкой проверки рабочего процесса мероприятия не только замечает на _kombu.bindings.celeryev, но и отдельный celeryev.i-am-alive. и если ключ не найден (истек), то он удаляется из _kombu.bindings.celeryev (и, возможно, выполняются команды del ceralev или expired ceralev.).

Мы не можем просто использовать команду keys, потому что это O (N), где N - общее количество ключей в БД. TTL могут быть сложными на redis < 2.1.

expired cumberev. а не del ceralev. могут быть использованы для того, чтобы позволить временному пользователю celeryevev оживать, но я не знаю, стоит ли это.

author