Сельдерей - запуск разных рабочих на одном сервере

У меня есть 2 вида задач: Type1 - несколько небольших задач с высоким приоритетом. Type2 - много тяжелых задач с более низким приоритетом.

Первоначально у меня была простая конфигурация с маршрутизацией по умолчанию, не использовались ключи маршрутизации. Этого было недостаточно - иногда все рабочие были заняты задачами Type2, поэтому Task1 была отложена. Я добавил ключи маршрутизации:

CELERY_DEFAULT_QUEUE = "default"
CELERY_QUEUES = {
    "default": {
        "binding_key": "task.#",
    },
    "highs": {
        "binding_key": "starter.#",
    },
}
CELERY_DEFAULT_EXCHANGE = "tasks"
CELERY_DEFAULT_EXCHANGE_TYPE = "topic"
CELERY_DEFAULT_ROUTING_KEY = "task.default"

CELERY_ROUTES = {
        "search.starter.start": {
            "queue": "highs",
            "routing_key": "starter.starter",
        },
}

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

Проблема - как запустить 2 celeryd с различными настройками concurrency?

Раньше сельдерей использовался в режиме демона (в соответствии с к этому), поэтому требуется только начало /etc/init.d/celeryd start, но теперь мне нужно запустить 2 разных сельдерея с разными очередями и concurrency. Как я могу это сделать?

Ответы

Ответ 1

Кажется, ответ - celery-multi - в настоящее время плохо документирован.

То, что мне нужно, может быть выполнено с помощью следующей команды:

celeryd-multi start 2 -Q:1 default -Q:2 starters -c:1 5 -c:2 3 --loglevel=INFO --pidfile=/var/run/celery/${USER}%n.pid --logfile=/var/log/celeryd.${USER}%n.log

В результате мы начинаем 2 рабочих, которые слушают разные очереди (-Q: 1 по умолчанию, Q: 2 - стартеры) с разными совпадениями -c: 1 5 -c: 2 3

Ответ 2

Основываясь на приведенном выше ответе, я сформулировал следующий файл /etc/default/celeryd (первоначально на основе конфигурации, описанной в документах здесь: http://ask.github.com/celery/cookbook/daemonizing.html), который работает для работы двух работников сельдерея на одной машине, причем каждый рабочий обслуживает другую очередь (в этом случае имена очередей являются "по умолчанию" и "важны" ).

В основном, этот ответ является лишь продолжением предыдущего ответа, поскольку он просто показывает, как делать то же самое, но для сельдерея в режиме демона. Обратите внимание, что мы используем django-celery здесь:

CELERYD_NODES="w1 w2"

# Where to chdir at start.
CELERYD_CHDIR="/home/peedee/projects/myproject/myproject"

# Python interpreter from environment.
#ENV_PYTHON="$CELERYD_CHDIR/env/bin/python"
ENV_PYTHON="/home/peedee/projects/myproject/myproject-env/bin/python"

# How to call "manage.py celeryd_multi"
CELERYD_MULTI="$ENV_PYTHON $CELERYD_CHDIR/manage.py celeryd_multi"

# How to call "manage.py celeryctl"
CELERYCTL="$ENV_PYTHON $CELERYD_CHDIR/manage.py celeryctl"

# Extra arguments to celeryd
# Longest task: 10 hrs (as of writing this, the UpdateQuanitites task takes 5.5 hrs)
CELERYD_OPTS="-Q:w1 default -c:w1 2 -Q:w2 important -c:w2 2 --time-limit=36000 -E"

# Name of the celery config module.
CELERY_CONFIG_MODULE="celeryconfig"

# %n will be replaced with the nodename.
CELERYD_LOG_FILE="/var/log/celery/celeryd.log"
CELERYD_PID_FILE="/var/run/celery/%n.pid"

# Name of the projects settings module.
export DJANGO_SETTINGS_MODULE="settings"

# celerycam configuration
CELERYEV_CAM="djcelery.snapshot.Camera"
CELERYEV="$ENV_PYTHON $CELERYD_CHDIR/manage.py celerycam"
CELERYEV_LOG_FILE="/var/log/celery/celerycam.log"

# Where to chdir at start.
CELERYBEAT_CHDIR="/home/peedee/projects/cottonon/cottonon"

# Path to celerybeat
CELERYBEAT="$ENV_PYTHON $CELERYBEAT_CHDIR/manage.py celerybeat"

# Extra arguments to celerybeat.  This is a file that will get
# created for scheduled tasks.  It generated automatically
# when Celerybeat starts.
CELERYBEAT_OPTS="--schedule=/var/run/celerybeat-schedule"

# Log level. Can be one of DEBUG, INFO, WARNING, ERROR or CRITICAL.
CELERYBEAT_LOG_LEVEL="INFO"

# Log file locations
CELERYBEAT_LOGFILE="/var/log/celerybeat.log"
CELERYBEAT_PIDFILE="/var/run/celerybeat.pid"

Ответ 3

Другой альтернативой является предоставление рабочему процессу уникального имени - с использованием аргумента -n.

У меня есть два приложения Pyramid, работающих на одном физическом оборудовании, каждый со своим экземпляром celery (в пределах своих собственных virtualenvs).

Оба они имеют Supervisor, который контролирует оба из них, как с уникальным файлом supervisord.conf.

app1:

[program:celery]                                            
autorestart=true                                            
command=%(here)s/../bin/celery worker -n ${HOST}.app1--app=app1.queue -l debug
directory=%(here)s     

[2013-12-27 10:36:24,084: WARNING/MainProcess] [email protected] ready.

app2:

[program:celery]                                 
autorestart=true                                 
command=%(here)s/../bin/celery worker -n ${HOST}.app2 --app=app2.queue -l debug
directory=%(here)s                               

[2013-12-27 10:35:20,037: WARNING/MainProcess] [email protected] ready.