Relationships
#4224 swamp serve reaches the V8 heap limit within 2–60 min under a small remote-worker workload (~20 runs, ~3.5k record versions)
Opened by vcjdeboer · 10/31/2026
Setup.
- swamp 20261030.160426.0-sha.a2f815f3, also seen on 20261027.021509.0-sha.f96841b5.
- One
swamp serveunder systemd on an AWS t4g.large (2 vCPU arm64, 8 GiB),@swamp/s3-datastore2026.10.24.2, one remote worker. - The workload: about 20 sequential analysis workflow runs, 7–11 model-method steps each, then two concurrent runs and a serve restart.
What happens. serve logs # Fatal JavaScript out of memory: Ineffective mark-compacts near heap limit (or Reached heap limit), exits code=dumped, status=5/TRAP and systemd restarts it. This happened 6 times across 3 sittings:
| date (UTC) | build | uptime at crash |
|---|---|---|
| 2026-10-30 14:15 | f96841b5 | ~60 min |
| 2026-10-30 21:25 | a2f815f3 | ~55 min |
| 2026-10-30 21:43 | a2f815f3 | 18 min after restart |
| 2026-10-31 11:22 | a2f815f3 | 57 min |
| 2026-10-31 11:44 | a2f815f3 | 21 min after restart |
| 2026-10-31 11:52 | a2f815f3 | 2.3 min after a restart |
- The kernel OOM killer never fired.
- The cgroup's MemoryCurrent was 3.1–3.8 GB afterwards, and that includes page cache.
- The 2.3-minute crash suggests that either the start itself is heavy (catalog rebuild?) or the growth is fast under concurrent load.
Scale, for comparison with earlier serve OOMs.
- About 3.5k record versions in the datastore (a retention plan listed 3,577), about 20 workflow runs per sitting, and one worker.
- That's much smaller than #1684 (2,000+ model definitions), #1552 (~400 artifacts per run) or #1558 (all runs loaded at boot).
Not asking for a bigger heap. We read #636: a larger --max-old-space-size would only delay this, and the compiled binary's baked v8_flags contain none anyway. What we'd like to find is what grows.
Debug-level hints from the same window (SWAMP_LOG_LEVEL=debug, see #4102):
- 13,274
Query predicate skipped row "leases"/…and"pending"/…lines against 268 worker handler calls in 23 minutes. Syncing behavior @…extension re-syncs: 22 in the same 23 minutes.
Asks.
- Is this a known growth path in serve on a2f815f3? Possibly the boot full pull of #2435 (the 2.3-minute crash came right after a restart), the catalog rebuild, or per-connection state across ~200 authenticated WebSocket connections.
- Is there a flag or debug mode for heap growth that works with the compiled binary? We can rerun a sitting with it and send the output.
Related: #4102 (trace of the same sittings), #636 (heap not configurable, by design), #2435 (serve boot hydration).
Open
No activity in this phase yet.
Sign in to post a ripple.