сельдерей celerybeat не тикает

У меня есть следующая установка:

celery-with-redis - 3.0        - active 
celery          - 3.0.12       - active 
django-celery   - 3.0.11       - active
django-kombu    - 0.9.4        - active
kombu           - 2.5.8        - active
redis           - 2.4.10

мои настройки сельдерея следующие:

BROKER_URL = "redis://:password@localhost:6379/0"
REDIS_DB = 0
REDIS_CONNECT_RETRY = True
CELERY_SEND_EVENTS=True
CELERY_RESULT_BACKEND="redis://:password@localhost:6379/0"
CELERY_TASK_RESULT_EXPIRES =  10
CELERYBEAT_SCHEDULER="djcelery.schedulers.DatabaseScheduler"

Проверяя мой файл журнала celerybeat, он имеет следующее

<ModelEntry: celery.backend_cleanup celery.backend_cleanup(*[], **{}) {<crontab: * 4 * * * (m/h/d/dM/MY)>}>
<ModelEntry: testing  spider.tasks.downloadCEA(*[], **{}) {<crontab: 4 9 * * * (m/h/d/dM/MY)>}>
[2013-04-02 09:16:15,364: DEBUG/MainProcess] Celerybeat: Ticking with max interval->5.00 seconds

Но он не просыпается и не спит, как ожидалось в файле журнала, а также изменения задач, измененные через интерфейс администратора, также не отражались в файле журнала. Однако, когда я перезапустил Redis, соответствующее поведение вернулось.

Кто-нибудь может посоветовать по этому поводу?

Обновление: я быстро top проверил свой процесс Redis - он использовал 100% загрузку процессора! кто угодно?


person goh    schedule 02.04.2013    source источник
comment
По предоставленной информации не могу сказать, что не так...   -  person Ngenator    schedule 02.04.2013
comment
@Ngenator, мой Redis потреблял 100% циклов процессора.   -  person goh    schedule 02.04.2013
comment
Redis работает как демон? Проверьте журналы. Я предполагаю, что у него проблемы с сохранением данных на диск. Он имеет тенденцию повторять попытки.   -  person Ngenator    schedule 02.04.2013


Ответы (1)


Извините, я отвечу на мой вопрос здесь.

Оказывается, я использовал более старую версию комбу, и многие соединения с Redis были созданы из рабочих. Обновление до более поздней версии решило проблему.

эта проблема была описана здесь пользователем @asksol.

person goh    schedule 02.04.2013