From 051c8d0714f3d261a8ec9aefc9d298c71196001d Mon Sep 17 00:00:00 2001 From: MorganOnCode <87934408+MorganOnCode@users.noreply.github.com> Date: Fri, 15 May 2026 08:40:22 +0000 Subject: [PATCH] chore(compose): bump facilitator mem_limit 512m -> 768m, redis 320m -> 384m User-requested extra headroom for the upcoming manual deploy. Steady-state RSS is ~120-180m on the facilitator and ~3-4m on redis (per docker stats); the new limits give ~5x headroom on the app and room for an AOF rewrite spike on redis. Tightening later is easy; debugging an OOM-kill of a payment facilitator under real traffic is not. Co-Authored-By: Claude Opus 4.7 (1M context) --- docker-compose.prod.yml | 12 +++++++----- 1 file changed, 7 insertions(+), 5 deletions(-) diff --git a/docker-compose.prod.yml b/docker-compose.prod.yml index 4f66b32..d3450fe 100644 --- a/docker-compose.prod.yml +++ b/docker-compose.prod.yml @@ -32,8 +32,10 @@ services: redis: condition: service_healthy # Cap memory + CPU so a runaway request loop can't OOM-kill the host. - # 512m fits the steady-state RSS (~120-180m) with comfortable headroom. - mem_limit: 512m + # 768m gives ~5x headroom over steady-state RSS (~120-180m). Generous on + # purpose: tightening later is easy, debugging an OOM-kill of a payment + # facilitator under real traffic is not. + mem_limit: 768m cpus: 1.0 healthcheck: test: ["CMD", "wget", "--no-verbose", "--tries=1", "--spider", "http://127.0.0.1:3000/health"] @@ -59,9 +61,9 @@ services: --maxmemory-policy allkeys-lru volumes: - redis_data:/data - # Matches redis-server --maxmemory 256m with a small overhead for the - # process itself; prevents a memory leak from blasting the host. - mem_limit: 320m + # Sits above redis-server --maxmemory 256m with comfortable overhead so + # AOF rewrite spikes don't trip the limit. + mem_limit: 384m cpus: 0.5 healthcheck: test: ["CMD", "redis-cli", "-a", "${REDIS_PASSWORD}", "ping"]