---
name: omniroute-heap-bloat-503
description: OmniRoute :20127/:20128 течёт ~200MB/сутки; next-server >400MB → heap-guard сбрасывает ВСЕ запросы 503 «resource pressure»; чинится рестартом раздутого воркера
metadata: 
  node_type: memory
  type: project
  originSessionId: 805ead91-dfa3-49d2-a5e6-01a980e715fd
---

**КОРЕНЬ «почему вдруг» (выяснено 2026-06-22):** долго было ок → начало течь ~19 июня. Причина — **апгрейд omniroute через Codex ~7–9 июня на тяжёлую Next.js-16-версию** (эндпоинты image/video + расширенный providers-слой; бэкапы `~/.codex/*-pre-app-20260609`, `config.toml.bak-before-omniroute`). Codex НИЧЕГО не портил руками: глоб.пакет `/opt/homebrew/lib/node_modules/omniroute` чист (0 файлов правлено после install), кривых команд в history нет, переустановка 22 июня 11:08 до v3.8.33 — это self-update/update-notifier, не Codex. Это РЕГРЕСС новой версии: прогретый baseline вырос до ~400MB (впритык к guard) + течь в `open-sse`-стриминге. **Откат запрещён юзером** (конфиги провайдеров не сойдутся со старой версией) → лечим watchdog'ом + репорт апстриму; опц. снизить baseline отключением неиспользуемых image/video/провайдеров в дашборде (живой конфиг в доме omniroute_svc, недоступен из CLI). `omniroute-mindshub-app` v1.0.0 (~/Services, ставился 7 июня) — дормант, НЕ слушает; реальный leaker = next-server глоб.пакета: :20127 = мост (pid-нода), :20128 = ядро (тот что течёт/бунсим).

**Симптом:** любой потребитель OmniRoute (CebersPost-дайджест, Делор, FreeTierRadar) получает `503 "Service temporarily unavailable due to resource pressure. Retry shortly. (reset after Ns)"` на ВСЕ модели сразу (zai/glm, gemini-cli, cerebras, nvidia) на обеих шинах :20127 и :20129.

**Корень (2026-06-19):** OmniRoute = супервизор `omniroute.mjs` (под юзером **omniroute_svc**, orphan PPID=1, НЕ под видимым launchd) + дочерний `next-server`. Архитектура: **:20127 — мост** (`/health` → `omniroute_base_url: :20128`), реальное ядро на **:20128**; :20129 — OpenAI-шина. heap-guard (`open-sse/utils/heapPressure.ts`, floor 400MB) при `heapUsed > 400MB` отдаёт 503 на КАЖДЫЙ запрос. За ~24ч next-server разбухает (был 462MB) → шлёт 503 всем. egress (xray :2081) при этом жив — путать не надо.

**Диагностика:** `ps -axo pid,ppid,rss,etime,command | grep -iE "omniroute|next-server"` — искать дочерний next-server супервизора `omniroute.mjs` с RSS под/над 400MB. Воспроизвести 503: probe на :20129 `/v1/chat/completions` или :20127 `/v1/messages` — если латентность 6-9с потом 503 = он.

**Фикс (нужен root — процесс под omniroute_svc):** `sudo kill <pid next-server>` — супервизор `omniroute.mjs` САМ поднимает свежий воркер за ~15с (проверено: 462MB → fresh, 503 ушёл, primary+фолбэки 200). Бить только next-server супервизора omniroute.mjs (на mini есть и ДРУГИЕ next-server — не задеть). su к omniroute_svc НЕ работает («su: Sorry»); `sudo` под cebers_mini = root (пароль cebers_mini в [[mac_mini_upterm_access]]).

**Durable — ОБНОВЛЕНО на threshold-watchdog (2026-06-22):** прежний дневной баунс (04:30) оказался НЕДОСТАТОЧЕН — после рестарта в 04:30 (456MB) шина к обеду снова разбухала до ~490MB и упиралась в guard. ЗАМЕНЁН: тот же `local.omniroute-bounce` (root LaunchDaemon, `/usr/local/bin/omniroute_bounce.sh` + `/Library/LaunchDaemons/local.omniroute-bounce.plist`) теперь **health-aware watchdog v2** (2026-06-22): `StartInterval=300` (каждые 5 мин), два независимых триггера на omniroute-воркер (родитель omniroute.mjs): **(1) превентивно** `RSS > THRESHOLD_MB` (дефолт **520**); **(2) реактивно** — РЕАЛЬНАЯ проба `POST {} → :20127/v1/messages` с ключом: здоровая шина даёт **400 за ~15мс БЕЗ вызова провайдера** (нулевая стоимость, нет ложных тревог от медленного LLM), а при heap-bloat'е guard режет всё в **503** → bounce; таймаут/000 тоже bounce. Ключ читается из `/Users/cebers_mini/.codex/omniroute.env` (root его видит). ⚠️ Порог НЕ 400: прогретый baseline v3.8.33 ≈400–420MB (холодный 141MB → +255MB/8мин на бандлы+реестр), рабочий разброс 287–452MB (GC-шум) → 400 давал бы термошинг. 520 = выше шума; реальную поломку добивает health-проба, даже если RSS отстаёт от heapUsed. `/health` для этого БЕСПОЛЕЗЕН (на :20127 = здоровье моста, отдаёт ok даже когда ядро :20128 в 503; на :20128 = 404). Проверено вживую: health=400→ok не трогает; форс THRESHOLD_MB=100→kill→респавн→200/0.85с (ветку «именно 503» искусственно не валил — тот же kill-путь). `:20127`=мост (node), `:20128`=ядро next-server (то что течёт/бьём). Под порогом — логирует `ok ... <= 400MB`, не трогает. Хирургично (матч по родителю `*omniroute*omniroute.mjs*` → другие next-server zemlya/torgiradar целы). Лог `/var/log/omniroute-bounce.log`. **Проверено E2E 2026-06-22:** под порогом не трогает (319MB→ok); форс THRESHOLD_MB=100 → убил pid 64503, супервизор поднял свежий pid 97333 @141MB, шина 200/0.85с после ~5с прогрева (краткий 500-блип на тёплом старте, покрыт fallback голосов). Порог 400 по RSS срабатывает РАНЬШЕ heap-guard (тот меряет heapUsed, RSS>heapUsed → баунсим до того как guard начнёт 503). Установка требовала root (процесс под omniroute_svc); ставится одной `sudo bash -c` (install+bootstrap system). (2) CebersPost `drafter._call_model` — retry 3× backoff 4→8с (commit 569ef06). См. [[ceberspost_overview]], [[omniroute_cloud_bus]].
