From 35c0057d831ed5595ae878aba0d1d2bb580029f2 Mon Sep 17 00:00:00 2001 From: Viktor Barzin Date: Sun, 28 Jun 2026 15:39:17 +0000 Subject: [PATCH] chrome-service: raise noVNC sidecar memory limit 96Mi->256Mi (fix OOMKill) MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit The noVNC sidecar (x11vnc + websockify) was OOMKilled (exit 137) repeatedly whenever someone actively opened chrome.viktorbarzin.me — the view connected then froze/hung. Idle usage is ~37Mi, but x11vnc + websockify framebuffer/encode buffers spike past the 96Mi cap when streaming the 1280x720 screen to a client. Raised request 32Mi->64Mi, limit 96Mi->256Mi (Burstable, aux tier). Already applied live via a transient kubectl patch (Recreate rollout, verified 0 restarts since); this lands the durable state so the next apply / daily drift-detection doesn't revert it to 96Mi. Co-Authored-By: Claude Opus 4.8 --- stacks/chrome-service/main.tf | 8 ++++++-- 1 file changed, 6 insertions(+), 2 deletions(-) diff --git a/stacks/chrome-service/main.tf b/stacks/chrome-service/main.tf index 382cc0c7..82e8fe45 100644 --- a/stacks/chrome-service/main.tf +++ b/stacks/chrome-service/main.tf @@ -359,9 +359,13 @@ resource "kubernetes_deployment" "chrome_service" { # x11vnc connects to the chrome-service container's Xvfb over # localhost TCP (shared pod network). Same uid 1000 as chrome # container so we can read MIT-MAGIC-COOKIE if Xvfb adds one. + # 256Mi (was 96Mi): the 96Mi cap OOMKilled (exit 137) the sidecar under + # ACTIVE VNC use — x11vnc + websockify framebuffer/encode buffers spike + # well past idle (~37Mi) when a client streams the 1280x720 screen, so the + # noVNC view froze/hung on connect. Bumped 2026-06-28. resources { - requests = { cpu = "10m", memory = "32Mi" } - limits = { memory = "96Mi" } + requests = { cpu = "10m", memory = "64Mi" } + limits = { memory = "256Mi" } } }