0 releases 36 tags

RSS feed

• v1.7.4 5dcae5b3ce

  Compare

  fix(deploy): bump registry pod memory to match doubled pgxpool size (#1225)

  Ghost released this 2026-04-29 14:05:09 -04:00 | 128 commits to main since this release

  Summary

  Follow-up to #1221. That PR doubled pgxpool MaxConns from 30 to 60 per
  pod without bumping the registry pod memory limit. pgxpool keeps
  per-connection state in the Go process (prepared statement cache,
  scratch buffers, row iteration state), so memory grew roughly
  proportionally — peak per-pod usage shifted from ~330 MB to ~450 MB
  against a 512 MiB limit.

  What surfaced it

  Pod tx49f was OOMKilled at 17:01 UTC on 2026-04-29 (exitCode 137,
  reason: OOMKilled). Memory history from Cloud Monitoring confirms the
  regression:

  Pods	Peak 30-min memory
  Pre-#1221 (MaxConns=30)	178–333 MB
  Post-#1221 (MaxConns=60)	437–449 MB
  Old limit	512 MiB ← right at the edge

  Other pod was at 394 MB at the time of inspection — could OOM again.

  Fix

  deploy/pkg/k8s/registry.go:217-225:

  	Before	After
  requests.memory	256 MiB	512 MiB
  limits.memory	512 MiB	1 GiB

  1 GiB is ~2× the current peak under load — gives room for traffic spikes
  without immediate OOM risk. Either node has 4–5 GiB free allocatable
  memory, so the new request fits comfortably.

  Test plan

  • go build ./... clean
  • golangci-lint run clean
  • After release + prod promotion: pod memory stabilises around 450
    MB peak with no OOMKills
  • After release + prod promotion: tx49f restartCount stops climbing
    (currently at 5)

  Deployment

  Zero downtime — Deployment template change only, rolling update with
  maxSurge: 1, maxUnavailable: 0. No PG involvement (no
  max_connections change, no shared_preload_libraries change). Same
  shape as a normal v1.7.x image promotion.

  🤖 Generated with Claude Code

  Co-authored-by: Claude Opus 4.7 (1M context) noreply@anthropic.com

  Downloads

  • Source code (ZIP)
    1 download
  • Source code (TAR.GZ)
    1 download