feat(workers): jeden workerserver (obie kolejki) — zgodne ze spec single-worker#6
Merged
mpasternak merged 1 commit intoJun 2, 2026
Conversation
ab5779a to
25c9a73
Compare
Scal workerserver-general + workerserver-denorm w jeden `workerserver`
konsumujący obie kolejki. Oszczędza jedną pełną kopię Django i połowę
procesów-dzieci prefork vs poprzednie 2× workery (~2×1.16 GiB → ~1×).
Zachowanie zgodne ze specyfikacją single-worker po stronie obrazu BPP
(~/Programowanie/bpp-single-worker, docs/.../2026-06-02-single-worker-design.md):
- **Bez ścisłego priorytetu** — kombu round-robin po `-Q celery,denorm`
(świadoma decyzja: zadania denorm/flush_single są krótkie).
- Concurrency (domyślnie 75% rdzeni) + recykling dzieci konfiguruje obraz w
`app.conf` (`celery_tasks.py`) przez `CELERY_WORKER_*` (CONCURRENCY, _PERCENT,
_MAX_MEMORY_PER_CHILD, _MAX_TASKS_PER_CHILD, _POOL, _PREFETCH_MULTIPLIER) —
czytane dopiero przez obraz z czerwca 2026+.
- `CELERY_QUEUE: "celery,denorm"` ustawione JAWNIE (nie polegamy na nowym
domyślnym entrypoincie), żeby konsolidacja działała płynnie także na OBECNYM
obrazie — inaczej kolejka denorm zostałaby bez konsumenta do czasu wydania
obrazu. CELERY_WORKER_MAX_MEMORY_PER_CHILD=300000 (deploy-default 300 MB).
Rename serwisu workerserver-general -> workerserver oraz zmiennych
WORKER_GENERAL_* -> WORKER_* z obowiązkową dwuwarstwową ochroną wsteczną:
fallback w compose ${WORKER_MEM_LIMIT:-${WORKER_GENERAL_MEM_LIMIT:-1536m}} +
migracja w init-configs (zachowuje wartość) + sprzątanie w configure-resources.
WORKER_DENORM_* usunięte. depends_on denorm-queue/workerserver-status przepięte;
jeden nocny restart (05:05). Model zasobów: jeden VARIABLE worker (floor 1.5g,
waga 35% = 20+15; CPU waga 30, total 95).
Zaktualizowane mk/*, restore.sh, upgrade-postgres.sh, testy (+ test konsolidacji,
140 passed) i docs (uslugi, zadania-ofelia, healthchecks-autoheal, limity-zasobow
#concurrency-celery, CLAUDE.md). mkdocs build --strict OK; docker compose config OK.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
25c9a73 to
a5724ac
Compare
workerserver (obie kolejki) — zgodne ze spec single-worker
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Cel
Konsolidacja dwóch workerów Celery (
workerserver-general+workerserver-denorm)w jeden
workerserverobsługujący obie kolejki. Każdy z dwóch workerów forkowałnprocdzieci prefork (każde = pełna kopia Django ~250 MB) → ~2×1.16 GiB.Jeden worker = jedna baza Django + mniej dzieci.
Zgodność ze specyfikacją obrazu BPP
Realizuje sekcję „Następstwa w bpp-deploy" ze spec single-worker
(
~/Programowanie/bpp-single-worker/docs/superpowers/specs/2026-06-02-single-worker-design.md).Zachowanie przejęte ze spec:
denorm/flush_singlekrótkie, nie blokują interaktywnych na długo).app.conf), nie 100%.Knoby:
CELERY_WORKER_CONCURRENCY/_CONCURRENCY_PERCENT/_MAX_MEMORY_PER_CHILD/
_MAX_TASKS_PER_CHILD/_POOL/_PREFETCH_MULTIPLIER.Zmiany w tym repo (bpp-deploy)
docker-compose.workers.yml— usuniętyworkerserver-denorm; jedyny workerto
workerserverzCELERY_QUEUE: "celery,denorm"ustawionym jawnie(transition-safe, niżej) +
CELERY_WORKER_MAX_MEMORY_PER_CHILD=300000(300 MB).denorm-queue/workerserver-statusdepends_on→workerserver. Jeden nocnyrestart (05:05).
workerserver-general→workerserveri zmiennychWORKER_GENERAL_*→
WORKER_*, z obowiązkową dwuwarstwową ochroną wsteczną (kontrakt CLAUDE.md):fallback w compose
${WORKER_MEM_LIMIT:-${WORKER_GENERAL_MEM_LIMIT:-1536m}}+migracja w
init-configs.sh(zachowuje wartość) + sprzątanie wconfigure-resources.sh.WORKER_DENORM_*usunięte.git pull && make upnastarym
.envdziała bez ręcznej edycji.30,
CPU_TOTAL_WEIGHT95).mk/*,restore.sh,upgrade-postgres.sh— usunięty drugi worker, nowa nazwa.uslugi.md,zadania-ofelia.md,healthchecks-autoheal.md,limity-zasobow.md(#concurrency-celeryz tabeląCELERY_WORKER_*),CLAUDE.md.Dlaczego
CELERY_QUEUEjawnie (drobne odstępstwo od spec)Spec sugeruje „bez
CELERY_QUEUE". Ustawiam je jawnie nacelery,denorm, byrollout był odporny na kolejność: działa na obecnym opublikowanym obrazie (stary
entrypoint honoruje
CELERY_QUEUE) i na nowym — więc kolejkadenormnigdy niezostaje bez konsumenta w oknie wdrażania obrazu. Na starym obrazie
CELERY_WORKER_*są ignorowane (concurrency = rdzenie); po
make pulldochodzi 75% i recykling.Jeśli wolisz literalne trzymanie się spec — usunę tę linię.
Weryfikacja
bash tests/test_makefile.sh→ 140 passed, 0 faileddocker compose config→ jedyny workerworkerserver;denorm-queue→workerserver;WORKER_MEM_LIMITinterpoluje się, fallback doWORKER_GENERAL_MEM_LIMIT(1700m) OK.mkdocs build --strict→ OK ·bash -nna skryptach → OK.🤖 Generated with Claude Code