Проблемы с Celery & Redis Backend

Question

У меня есть система, созданная в настоящее время с использованием сельдерея с backis для redis , чтобы выполнить кучу асинхронных задач, таких как отправка писем, , вытягивание социальных данных, сканирование и т. Д. Все работает отлично, но я с группой, выясняющей, как контролировать систему (ака число сообщений в очереди). Я начал искать через источник сельдерея, но я полагал, что я отправлю свои вопросы здесь: Во-первых, здесь мои конфигурации:

BROKER_BACKEND     = "redis" 
BROKER_HOST      = "localhost" 
BROKER_PORT      = 6379 
BROKER_VHOST     = "1" 
REDIS_CONNECT_RETRY  = True 
REDIS_HOST        = "localhost" 
REDIS_PORT        = 6379 
REDIS_DB        = "0" 
CELERY_SEND_EVENTS      = True 
CELERYD_LOG_LEVEL    = 'INFO' 
CELERY_RESULT_BACKEND   = "redis" 
CELERY_TASK_RESULT_EXPIRES  = 25 
CELERYD_CONCURRENCY    = 8 
CELERYD_MAX_TASKS_PER_CHILD = 10 
CELERY_ALWAYS_EAGER      =True 

---

Первое, что я пытаюсь сделать, это контролировать, сколько сообщения находятся в моей очереди. Я предполагаю, что за кулисами, redis backend - это всего лишь нажатие/высказывание из списка, хотя я не могу найти, что в код. Поэтому я макет моделирования, где я начинаю около 100 задач и пытается найти их в redis: My celeryd работает следующим образом: python manage.py celeryd -c 4 --loglevel = DEBUG -n XXXXX --logfile = logs/ celery.log Итак, у меня должно быть только 4 одновременных работника ..... Две вещи, которые я не понимаю: Проблема 1: После того, как я поставил в очередь 100 задач и искал их на redis я только увидеть следующее:

$ redis-cli 
redis 127.0.0.1:6379> keys * 
1) "_kombu.binding.celery" 
redis 127.0.0.1:6379> select 1 
OK 
redis 127.0.0.1:6379[1]> keys * 
1) "_kombu.binding.celery" 
2) "_kombu.binding.celeryd.pidbox" 
redis 127.0.0.1:6379[1]> 

Я не могу найти задачи, чтобы получить число, сколько стоят в очереди (т echnically, 96 должно быть, так как я только поддерживать 4 параллельных задач)

Задача 2

$ ps aux | grep celeryd | cut -c 13-120 
41258 0.2 0.2 2526232 9440 s004 S+ 2:27PM 0:07.35 python 
manage.py celeryd -c 4 --loglevel=DEBU 
41261 0.0 0.1 2458320 2468 s004 S+ 2:27PM 0:00.09 python 
manage.py celeryd -c 4 --loglevel=DEBU 
38457 0.0 0.8 2559848 34672 s004 T 12:34PM 0:18.59 python 
manage.py celeryd -c 4 --loglevel=INFO 
38449 0.0 0.9 2517244 36752 s004 T 12:34PM 0:35.72 python 
manage.py celeryd -c 4 --loglevel=INFO 
38443 0.0 0.2 2524136 6456 s004 T 12:34PM 0:10.15 python 
manage.py celeryd -c 4 --loglevel=INFO 
84542 0.0 0.0 2460112  4 s000 T 27Jan12 0:00.74 python 
manage.py celeryd -c 4 --loglevel=INFO 
84536 0.0 0.0 2506728  4 s000 T 27Jan12 0:00.51 python 
manage.py celeryd -c 4 --loglevel=INFO 
41485 0.0 0.0 2435120 564 s000 S+ 2:54PM 0:00.00 grep 
celeryd 
41264 0.0 0.1 2458320 2480 s004 S+ 2:27PM 0:00.09 python 
manage.py celeryd -c 4 --loglevel=DEBU 
41263 0.0 0.1 2458320 2480 s004 S+ 2:27PM 0:00.09 python 
manage.py celeryd -c 4 --loglevel=DEBU 
41262 0.0 0.1 2458320 2480 s004 S+ 2:27PM 0:00.09 python 
manage.py celeryd -c 4 --loglevel=DEBU 

Если кто-нибудь может объяснить это для меня, это было бы здорово.

Answer 1

Ваша конфигурация имеет CELERY_ALWAYS_EAGER = True. Это означает, что задачи выполняются локально, и, следовательно, вы не увидите их в Redis. Из документов: http://celery.readthedocs.org/en/latest/configuration.html#celery-always-eager

CELERY_ALWAYS_EAGER

Если это верно, все задачи будут выполнены локально блокирование до возвращения задачи. apply_async() и Task.delay() вернет экземпляр EagerResult, который эмулирует API и поведение AsyncResult, за исключением того, что результат уже оценивается .

То есть задачи будут выполняться локально, а не отправляться в очередь .

Answer 2

Никогда не использовался сельдерей, но если вы хотите понять, что он делает, один из способов сделать это - подключиться к экземпляру Redis с помощью redis-cli, а затем запустить команду monitor. Это приведет к удалению всех команд, выполняемых в базе данных Redis. Вы сможете точно увидеть, что происходит.