Celery - запуск разных рабочих на одном сервере

Question

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

Изначально у меня была простая конфигурация с маршрутизацией по умолчанию, ключи маршрутизации не использовались. Этого было недостаточно - иногда все работники были заняты Задачами Типа 2, поэтому Задача1 откладывалась. Я добавил ключи маршрутизации:

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 сельдерея с разными настройками параллелизма?

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

Answer 1

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

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

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's 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"

Answer 2

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

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

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

Answer 3

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

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

Оба контролера контролируют оба приложения, оба с уникальным файлом 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] celery@maz.local.app1 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] celery@maz.local.app2 ready.

Answer 4

Обновление:

В Celery 4.x ниже будет работать правильно:

celery multi start 2 -Q:1 celery -Q:2 starters -A $proj_name

Или, если вы хотите назначить имя экземпляра, вы можете:

celery multi start name1 name2 -Q:name1 celery -Q:name2 queue_name -A $proj_name

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

Я думаю, это также сработало бы, если бы мы запускали эти экземпляры один за другим вручную, присваивая им разные имена узлов, но -A то же самое $proj_name, хотя это немного трата времени.

Кстатисогласно официальному документу , вы можете убить всех работников сельдерея просто:

ps auxww | grep 'celery worker' | awk '{print $2}' | xargs kill -9