viktor/infra
1
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions

chrome-service: raise noVNC sidecar memory limit 96Mi->256Mi (fix OOMKill)
All checks were successful
ci/woodpecker/push/default Pipeline was successful
Details

Browse source 
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 <noreply@anthropic.com>
This commit is contained in:
Viktor Barzin 2026-06-28 15:39:17 +00:00
parent 2e50c1235c
commit 35c0057d83
1 changed files with 6 additions and 2 deletions
Download patch file Download diff file Expand all files Collapse all files

8
stacks/chrome-service/main.tf
View file

@ -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" }
}
}