Question

我经历了Celery工作进程之间的奇怪交互，我认为这是独立的。你能说明一个可能的原因吗？

我有一个有多个工人流程的芹菜工人：

 PPID  PID
 5892  5919   \_ /bin/bash -c sleep 10 && python manage.py makemigrations --noinput; python manage.py migrate --noinput; python manage.py initservice; celery -B -A workflows --workdir=/srv/workflows -l info --autoscale=2,30 -n UNIVERSE_NODE -Q workflows worker
 5919  6168        \_ /usr/bin/python /usr/local/bin/celery -B -A workflows --workdir=/srv/workflows -l info --autoscale=2,30 -n UNIVERSE_NODE -Q workflows worker
 6168  6180           \_ /usr/bin/python /usr/local/bin/celery -B -A workflows --workdir=/srv/workflows -l info --autoscale=2,30 -n UNIVERSE_NODE -Q workflows worker
 6168  6185           \_ /usr/bin/python /usr/local/bin/celery -B -A workflows --workdir=/srv/workflows -l info --autoscale=2,30 -n UNIVERSE_NODE -Q workflows worker
 6168  6186           \_ /usr/bin/python /usr/local/bin/celery -B -A workflows --workdir=/srv/workflows -l info --autoscale=2,30 -n UNIVERSE_NODE -Q workflows worker
 6168  6187           \_ /usr/bin/python /usr/local/bin/celery -B -A workflows --workdir=/srv/workflows -l info --autoscale=2,30 -n UNIVERSE_NODE -Q workflows worker
 6168  6188           \_ /usr/bin/python /usr/local/bin/celery -B -A workflows --workdir=/srv/workflows -l info --autoscale=2,30 -n UNIVERSE_NODE -Q workflows worker
 ...   ...

有时，其中一个工作进程被卡住了......不知怎的，它会阻止所有其他工作进程。当此过程停止时，其他工作进程将恢复执行。

按照设计，除了worker（具有PID 6168的父级）和消息队列+结果后端之外，工作进程之间不应该存在共享状态。但不知何故，有一些。

你能说出造成这种僵局的可能原因吗？

我使用最新的Celery 3.1，RabbitMQ作为消息队列，MongoDB作为结果后端，默认早期ack（显然，多处理并发模式）。

Answer 1

找到此行为的原因：http://docs.celeryproject.org/en/latest/whatsnew-3.1.html#caveats。对于长时间运行的进程，预取策略可能会使一个进程阻塞其他进程。

要防止这种情况，请使用-Ofair标记：

$ celery -A proj worker -l info -Ofair

Celery：一个工作进程阻止其他工作进程的执行？分享什么？

1 个答案: