fix(zone-configurator): raise memory limit 256Mi→512Mi + add liveness probe #245

Merged
k.renner merged 1 commits from fix/zone-configurator-memory-limit into master 2026-07-15 07:16:21 +00:00
Member

Symptom

The Presence Zone Configurator became unusable: "No Room Selected" in the Zone Editor, live tracking stuck on "Waiting for live data", every API request hanging. Reproduced from inside the pod too — even GET / timed out — so it was the app itself, not the Authentik gate.

Root cause

The pod was pegged at 254Mi / 256Mi memory (99%) burning ~0.95 CPU cores — Node/V8 GC-thrash at the cgroup memory limit. The event loop froze so the HTTP server answered nothing, but the process stayed just under the limit → never OOMKilled, never self-recovered (0 restarts, 66d uptime). A rollout restart cleared it (fresh RSS ~115Mi) and the UI — room load, live tracking, zone editing with drag-handles + "Show Zone Slots" — works again.

The heavy device re-discovery triggered by an entity rename (89 entities re-matched + very verbose candidate logging) on top of live tracking pushed a long-lived process over an already-tight 256Mi.

Fix

  • limits.memory 256Mi → 512Mi (headroom below the thrash zone); requests.memory 64Mi → 128Mi (realistic baseline).
  • Liveness + readiness httpGet / on the UI port. There was no probe, so the kubelet never restarted the hung server. Now a wedge fails the probe and the pod auto-recycles.

Validation

kubectl kustomize kubernetes/apps/zone-configurator green. Restarted pod verified responsive (inside-pod GET / + /api/rooms OK; gate returns 302; live target tracking confirmed in the browser).

🤖 Generated with Claude Code

## Symptom The Presence Zone Configurator became unusable: **"No Room Selected"** in the Zone Editor, live tracking stuck on *"Waiting for live data"*, every API request hanging. Reproduced from **inside the pod** too — even `GET /` timed out — so it was the app itself, not the Authentik gate. ## Root cause The pod was pegged at **254Mi / 256Mi memory (99%)** burning **~0.95 CPU cores** — Node/V8 **GC-thrash** at the cgroup memory limit. The event loop froze so the HTTP server answered nothing, but the process stayed just under the limit → **never OOMKilled, never self-recovered** (0 restarts, 66d uptime). A rollout restart cleared it (fresh RSS ~115Mi) and the UI — room load, live tracking, zone editing with drag-handles + "Show Zone Slots" — works again. The heavy device re-discovery triggered by an entity rename (89 entities re-matched + very verbose candidate logging) on top of live tracking pushed a long-lived process over an already-tight 256Mi. ## Fix - `limits.memory` **256Mi → 512Mi** (headroom below the thrash zone); `requests.memory` 64Mi → 128Mi (realistic baseline). - **Liveness + readiness** `httpGet /` on the UI port. There was **no probe**, so the kubelet never restarted the hung server. Now a wedge fails the probe and the pod auto-recycles. ## Validation `kubectl kustomize kubernetes/apps/zone-configurator` green. Restarted pod verified responsive (inside-pod `GET /` + `/api/rooms` OK; gate returns 302; live target tracking confirmed in the browser). 🤖 Generated with [Claude Code](https://claude.com/claude-code)
claude-bot added 1 commit 2026-07-15 07:08:47 +00:00
Der Configurator-Pod hing (UI nicht erreichbar, "No Room Selected" beim
Zonen-Editieren, Live-Tracking eingefroren): RSS lag bei 254Mi/256Mi und
~0,95 CPU-Kerne – klassisches Node/V8 GC-Thrashing am cgroup-Memory-Limit.
Der Prozess blieb knapp unter dem Limit, wurde also nie OOMKilled und kam
nie von selbst zurück; ein Neustart hat ihn befreit (frisch ~115Mi).

- limits.memory 256Mi → 512Mi (Headroom gegen GC-Thrash), requests.memory
  64Mi → 128Mi (realistischere Baseline).
- Liveness/Readiness httpGet auf / (Port http). Bisher gab es keine Probe,
  daher hat kubelet den hängenden Server nie neu gestartet. Jetzt schlägt
  die Probe beim Einfrieren fehl und der Pod wird automatisch recycelt.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
k.renner merged commit 5b5fdf22e7 into master 2026-07-15 07:16:21 +00:00
Sign in to join this conversation.