fix(celery): enable memory-based worker recycling#4639
Conversation
Switch workers to prefork with lower concurrency and prefetch so memory-heavy children can be recycled before triggering OOM.
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 1ee23cf453
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
| [program:celery-backup] | ||
| environment = CELERY_WORKER_RUNNING=1,CELERY_APP=weblate.utils | ||
| command = /app/venv/bin/celery worker --hostname 'backup@%%h' --loglevel info --pool=threads --concurrency=1 --queues=backup --prefetch-multiplier=2 %(ENV_CELERY_BACKUP_OPTIONS)s | ||
| command = /app/venv/bin/celery worker --hostname 'backup@%%h' --loglevel info --pool=prefork --queues=backup --prefetch-multiplier=1 %(ENV_CELERY_BACKUP_OPTIONS)s |
There was a problem hiding this comment.
Keep backup concurrency pinned when options are customized
When an installation sets CELERY_BACKUP_OPTIONS only to append an unrelated worker flag, this line no longer supplies any fixed --concurrency; start only injects --concurrency 1 when the variable is unset. Celery's worker docs state that omitted --concurrency defaults to the number of CPUs, so those customized backup workers can now fork multiple backup children instead of the previously hard-pinned single backup worker, increasing concurrent backup load and memory use.
Useful? React with 👍 / 👎.
| @@ -1,3 +1 @@ | |||
| # Alernative Celery pool implementation | |||
| gevent==26.5.0 | |||
| supervisor==4.3.0 | |||
There was a problem hiding this comment.
Keep gevent installed while pool override is documented
With this requirements hunk now omitting gevent, deployments that use the documented CELERY_*_OPTIONS escape hatch for a different pool such as --pool=gevent lose the pool implementation at runtime. Celery's own gevent pool docs show enabling it with celery worker --pool=gevent and its examples say to install gevent first, so this breaks an existing documented Docker configuration rather than just changing the default pool.
Useful? React with 👍 / 👎.
Switch workers to prefork with lower concurrency and prefetch so memory-heavy children can be recycled before triggering OOM.