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

Relationships

#1285 serve: main JS thread holds ~40–70% of a core while idle (no clients, no runs, --no-schedule)

Opened by ehazlett · 7/20/2026

Summary

A serve process with no client connected, no active workflow runs, and --no-schedule set still holds a large, steady fraction of one core. The load is on the main event-loop thread, which points at a hot timer/poll rather than request work. Besides wasting a core, it starves request handling and produces multi-second tail latencies on otherwise sub-second reads.

Environment

  • swamp 20260718.081020.0-sha.fc14abbd
  • serve with token auth, --no-schedule, single repo (~581 data records; datastore has accumulated a sizeable WAL). Run history: 30 succeeded / 4 failed / a few suspended.

Measurements

Sampling /proc/<pid>/task/*/stat (utime + stime deltas) over several-second windows with no client connected:

  • Whole process: ~40–70% of one core, sustained, across repeated windows.
  • Per-thread over a 3s window:
    • main event-loop thread: ~38%
    • four V8 worker threads: ~1.7% each
    • tokio worker threads: ~0.3% each

Under an added read load the same process rose to ~112% and individual data.query calls slowed (~570ms to ~1000ms), i.e. the idle work contends with request handling.

Impact

  • One core consumed continuously at rest.
  • Tail latencies: an otherwise ~500ms read occasionally spikes to ~3.4s, consistent with the event loop being busy when the request arrives.

Suggested direction

  • Profile the main event-loop thread at rest (no clients) to find the hot timer/poll.
  • Confirm whether any internal loop ignores --no-schedule, or polls the datastore / WAL on a tight interval.

Repro

  1. Start serve with --no-schedule and no clients.
  2. Sample the process's CPU (e.g. /proc/<pid>/stat, or per-thread via /proc/<pid>/task/*/stat) over several seconds.
  3. Observe sustained main-thread CPU with zero external traffic.

The scan-cost issue #1284 (https://swamp-club.com/lab/1284) sets the ~500ms baseline for reads; this issue explains the multi-second tail on top of it.

02Bog Flow
OPENTRIAGEDIN PROGRESSSHIPPED

Open

7/20/2026, 5:13:13 AM

No activity in this phase yet.

03Sludge Pulse

Sign in to post a ripple.