admin/.tasks/NEXT_SESSION.md

_last_updated_, session_id

_last_updated_	session_id
2026-07-05T11:45:00Z	2026-07-05-snolla-tirazh-mem-limits

Next session handoff

Итог сессии: метрики тиража snolla + mem_limit 512m всем 5 стекам

Начали со съёма health-метрик тиража (user: «не распухает ли память, не жрут ли ЦПУ»). Вывод: все snolla-сайты здоровы — CPU ~0.5% одного ядра в среднем, RAM 100–206 MB, нет reclaim-трэша / OOM-давления. На машину (13 GiB, 6 vCPU) влияние в пределах шума; главный едок RAM на боксе — mssql (2.1 GB).

Нашёл дыру: ни один snolla-стек не нёс mem_limit → cgroup-cap = вся память хоста (12.9 GiB). Течь в любом контейнере могла съесть весь бокс. По просьбе user'а выставил mem_limit: 512m всем пяти (env-preserving Portainer PUT, секреты вернул verbatim) + синхронизировал source-of-truth compose в репо.

Стек	Id	limit	статус
labtools.ru	17	512 MiB ✓	healthy
emspb	18	512 MiB ✓	healthy
labtools.pro	19	512 MiB ✓	healthy (200 внешним smoke)
tandemmebel	20	512 MiB ✓	healthy (ещё staging-хост)
kupimknigi	21	512 MiB ✓	healthy

Проверено: ops.docker.stats → limit=536870912 на всех. Пересоздание = секунды простоя, теги не поехали (pullImage:false).

Durable-правило закреплено (user: «дальше не забывать выставлять лимиты»):

• вики-канон portainer-stack-management-vds § Convention — app-стек обязан нести mem_limit;
• snolla-live-prod-inplace-image-bump step 6 — пункт чеклиста;
• авто-память vds-app-stacks-need-mem-limit.

Recent commits

• 9a92ff0b chore(vds): mem_limit 512m всему тиражу snolla (5 стеков + compose + вики)
• 3bc99923 meta(handoff): тираж 0.42.1 закрыт
• 8e3e5b43 wiki(snolla-0.42.1): рецепт + 3 рунбука

Open треки

Трек	Готовность	Entry-point
tandemmebel.ru cutover (последний из тиража)	staging GREEN, стек 20 tandemmebel:ed96b18 (0.42.0), mem_limit стоит, ждёт DNS	Триггер = владелец флипает reg.ru tandemmebel.ru+www→89.253.255.94. Порядок в STATUS.md-блоке [tandemmebel-web-vds-deploy]: verify авторит.NS → ТОЛЬКО ПОТОМ боевой Host() в стек 20 (LE-порядок критичен) → live-smoke (gallery-DoD 12/12). Если origin уехал — пересобрать HEAD, ре-DoD. К cutover можно сразу бампнуть до 0.42.1.
morethencms-s3-filestorage-provider	🟡 ждёт .dll от прога MoreThenCms	STATUS.md-блок
fix-nl-vds-reality-pq-dest	🟡 ждёт client-side (user меняет SNI)	STATUS.md-блок
harden-books-vds-exposed-ports / kreknin-self-backup	⚪ backlog	STATUS.md-блоки

Спроси user'а

• Версии тиража разъехались: kupimknigi (21) + tandemmebel (20) на 0.42.0, три остальных на 0.42.1 (order-фикс). Добампить оба до 0.42.1 для единого пина, или оставить? tandemmebel всё равно пересобирать к cutover — там сразу 0.42.1.
• Опционально: поставить периодический снапшот RAM трёх свежих (17/18/19) на пару суток, чтобы поймать дрейф во времени (одним снимком течь за дни не доказать). Не просили — предложение висит.

Не делать (preemptive guards)

• tandemmebel: НЕ трогать стек 20 / НЕ вставлять боевой Host ДО подтверждённого DNS-флипа на обоих авторит.NS (иначе LE HTTP-01 упадёт на RUVDS → сожжём rate-limit). Флип делает владелец.
• RUVDS IIS 80.64.31.36 — НЕ декоммишн (rollback всех мигрированных). Биндинги labtools.ru/pro оставлены как rollback.
• Новые app-стеки / правки существующих — всегда с mem_limit (см. вики-конвенцию), синхронно в Portainer И compose-копию.
• Смоук snolla-доменов гнать С VDS (воркстейшн ловит LAN-DNS-перехват прод-доменов).

Memory updates за сессию

• Новая: vds-app-stacks-need-mem-limit (durable-правило про лимиты).
• Подтвердились: ps51-iso8859-corrupts-portainer-stackfile (обошёл PS-грабли, PUT слал UTF-8-байтами), workstation-lan-dns-serves-local-cms-copy (smoke через --resolve).