feat: model limitów RAM (stały cap + pula zmienna) + minimum 12 GB#5
Merged
Merged
Conversation
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Zastepuje plaski podzial wagowy modelem FIXED (staly cap, odejmowany od budzetu) + VARIABLE (floor + waga nadwyzki: db 40 / app 25 / wg 20 / wd 15). Skrypt zapisuje teraz MEM_LIMIT dla wszystkich 17 uslug (.env = jedno zrodlo prawdy) + REDIS_MAXMEMORY; CPU bez zmian (te same 7 uslug). Prog ostrzezenia malego hosta podniesiony do 12 GB (minimum BPP). Bash 3.2-safe (macOS). Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Capy docieraja do instalacji bez configure-resources przez ${VAR:-default}:
redis 256m->1g, netdata 256m->320m, alloy 384m->192m, loki 256m->192m,
flower 768m->128m, worker-general/denorm 1g->1536m, appserver 1g->2g.
Flower dostaje FLOWER_MAX_TASKS=10000 zeby cap 128m byl bezpieczny.
Podniesienie sufitu jest bezpieczne (wiecej zapasu); obnizone (alloy/loki/
flower) to jedyne ryzyko OOM dla istniejacych instalacji - flower chroniony
przez --max-tasks, alloy/loki podniesione do 192m wzgledem pierwotnych 128m.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
README + docs/instalacja (para synchroniczna) zyskuja sekcje wymagan sprzetowych: min 12 GB RAM, zalecane 16 GB+. docs/konfiguracja/limity-zasobow przepisane na model FIXED (staly cap) + VARIABLE (floor + waga nadwyzki), z nowa tabela capow, uwaga o netdata cap vs retencja i trzema uslugami bez limitu (backup-runner, certbot, workerserver-status). mkdocs build --strict: OK. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
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
1 participant
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.
Co i dlaczego
Przeprojektowanie
make configure-resourcesoraz domyślnych limitów RAM. Dotychczas skrypt sizingował tylko 7 usług płaskim podziałem wagowym, a ~10 pozostałych korzystało z często przewymiarowanych defaultów compose (flower 768m, alloy 384m), którychconfigure-resourcesnigdy nie ruszał.Nowy model odzwierciedla realne zużycie RAM stacka:
dbserver/appserver/workery dzielą pozostałą pulę:floor + nadwyżka × waga(db 40% / app 25% / wg 20% / wd 15%).Minimum 12 GB RAM
Σ(fixed 3,3 GB) + Σ(floory 6,5 GB) + rezerwa OS (2 GB) ≈ 12 GB— to próg, w którym wszystkie minima się mieszczą (dbserver na floorze, zerowa nadwyżka). Zalecane 16 GB+. Poniżej 12 GB skrypt przypisuje floory i ostrzega o ryzyku OOM. Wymaganie udokumentowane w README +docs/instalacja(para synchroniczna) orazdocs/konfiguracja/limity-zasobow.md.Capy
Po review podniesiono
alloy/lokize 128m → 192m (spike przy logach).flowerzostaje 128m, ale dostajeFLOWER_MAX_TASKS=10000, żeby ograniczyć historię w RAM i uczynić cap bezpiecznym.Audyt pokrycia
Trzy kontenery celowo bez limitu (udokumentowane):
backup-runner(batch),certbot(krótkie zadanie SSL),workerserver-status(celery status, profilmanual).Backwards-compat
Podniesienie sufitu jest bezpieczne (więcej zapasu, nie więcej OOM). Jedyne ryzyko to obniżone sufity (alloy/loki/flower) na istniejących instalacjach przy
git pull && make up— flower chroniony przez--max-tasks, alloy/loki podniesione do 192m. Brak ręcznego kroku w.env(defaulty compose działają automatycznie).REDIS_MAXMEMORYdomyślnie 200mb w compose, podnoszony tylko przy ponownymconfigure-resources, więc bump sufitu redisa jest bezpieczny.Zmiany
scripts/configure-resources.sh— model FIXED+VARIABLE, zapis MEM dla wszystkich 17 usług (.env = jedno źródło prawdy) +REDIS_MAXMEMORY; CPU bez zmian (te same 7 usług); próg ostrzeżenia 6→12 GB; bash 3.2-safe (macOS — bezdeclare -A).--max-tasks.tests/test_makefile.sh— nowytest_configure_resources(13 asercji, deterministyczne capy). 132 passed, 0 failed.mkdocs build --strict: OK.Follow-up (osobny PR)
Per-service WEB_CONCURRENCY (gunicorn: appserver/authserver) + celery concurrency (workery), liczone memory-aware z
MEM_LIMITi liczby CPU. Blocker: wymaga weryfikacji, czy obrazyiplweb/bpp_*honorują te zmienne (entrypoint może mieć zaszyte--workers/--concurrency).🤖 Generated with Claude Code