Когда я запускаю Celery с Upstart, через некоторое время дочерние или основные процессы умирают без каких-либо следов.
Я использую сценарий Upstart (/etc/init/celery):
description "celery"
start on runlevel [2345]
stop on runlevel [!2345]
kill timeout 20
# console log
setuid ***
setgid ***
script
chdir /opt/***/project/
exec /opt/***/virtualenvs/***/bin/python manage.py celery worker --settings=settings.staging -B -c 4 -l DEBUG
end script
respawn
При запуске той же команды без выскочки (запуск вручную exec часть) все работает нормально.
С respawn строфа, главный процесс умрет и возродится, пока потерянные дочерние процессы все еще существуют, что приведет к переполнению памяти. Без него процессы просто исчезнут, пока не останутся рабочие.
Celery порождает главный процесс и рабочие процессы (в данном случае 4 из них). Я также пробовал запускать его с eventlet вместо многопроцессорности (1 мастер, 1 дочерний процесс), но результаты аналогичны.
Кто-нибудь сталкивался с таким поведением раньше?
Обновить:
-c N начинается с N + 2 процессы, N из которых рабочие (какие 2?).expect строфа, но не уверен, какое значение должно быть. С участием eventlet expect fork имеет смысл. Но как насчет многопроцессорности?Обновление2:
С помощью except fork казалось, что обработка перестала умирать, но при попытке остановить или перезапустить задание просто зависает.
Решением было не запускать Celery beat вместе с рабочим (удаление -B часть из команды exec).
По-видимому, это был «лишний» процесс, который как-то все испортил.
Вот последний сценарий, который у меня получился:
description "celery"
start on started postgresql
stop on runlevel [!2345]
kill timeout 20
setuid ***
setgid ***
respawn
chdir /opt/***/project/
exec /opt/***/virtualenvs/***/bin/python manage.py celery worker --settings=settings.staging -c 4 -l DEBUG
И бег celery beat по отдельности:
description "celerybeat"
start on started celery
stop on stopped celery
setuid ***
setgid ***
respawn
chdir /opt/***/project/
exec /opt/***/virtualenvs/***/bin/python manage.py celery beat --settings=settings.staging -l DEBUG
С помощью chdir внутри script предложение совершенно неверно, и это означает, что вы не можете понять самую основную идею выскочки (это не оскорбление). (В качестве примечания, exec ключевое слово просто бесполезно, но не вредит).
Это очень важная идея для понимания того, как работает выскочка. Upstart пытается определить, какой процесс из процессов, порожденных script stanza - это фактический демон этой службы. Затем он использует этот процесс, чтобы определить, выполняется ли это задание, остановлено, завершилось неудачно или что-то еще. По этой причине крайне важно убедиться, что процесс идет правильно.
Алгоритм определения процесса очень простой, это зависит от expect строфа. expect fork означает "возьми вторую вилку в script строфа ", expect daemon - то же самое, но третий.
Теперь, используя chdir внутри script означает, что он вызывает фактическое /bin/chdir двоичный, и это считается отдельной вилкой. Что вам нужно сделать, так это переместить его за пределы script строфа и чем играть с expect строфы, пока вы не поймете это правильно. Вы можете проверить, правильно ли вы поняли, сравнив вывод initctl status celery против ps. PID должны совпадать.