Skip to main content
← Back to list
01Issue
BugOpenSwamp CLIPublic
AssigneesNone

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 serve under systemd on an AWS t4g.large (2 vCPU arm64, 8 GiB), @swamp/s3-datastore 2026.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.

  1. 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.
  2. 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).

02Bog Flow
◉OPEN○TRIAGED○IN PROGRESS○SHIPPED

Open

10/31/2026, 12:39:50 PM

No activity in this phase yet.

03Sludge Pulse

Sign in to post a ripple.