JavaScript Memory Footprint on Low-Traffic Node.js Workloads

A minimal, dependency-free Node.js HTTP server typically reaches a steady-state Resident Set Size (RSS) between 20 MB and 80 MB. While the actual JavaScript heapUsed may only be a few megabytes, the total process memory includes the V8 isolate, the libuv event loop, and core module overhead.

Memory Baseline vs. GC Frequency

Under infrequent event loop activity, garbage collection (GC) frequency does not significantly impact the baseline memory usage. In a low-traffic scenario, the memory footprint is dominated by the runtime's static overhead rather than the allocation of short-lived request objects.

Confirmed Runtime Behavior

• RSS vs. Heap: The OS-level memory (RSS) remains higher than the V8 heap because it includes native buffers, the executable code, and memory reserved by the V8 engine that has not yet been returned to the operating system.
• Idle Stability: Once the process has warmed up and loaded core modules, the memory floor remains relatively stable regardless of how rarely the server receives requests.
• GC Impact: Periodic GC cycles create a "sawtooth" pattern in heapUsed, but these fluctuations rarely move the RSS baseline significantly unless the heap grows large enough to trigger a major GC that releases pages back to the OS.

Optimization Steps for Minimal Footprints

If you are optimizing for the lowest possible operational cost (e.g., small container limits), follow these steps:

1. Limit Heap Reservation: Use the --max-old-space-size flag to prevent V8 from reserving an unnecessarily large heap area. For a minimal server, setting this to 64MB or 128MB can help keep the process footprint tight.
2. Avoid Heavy Frameworks: Use the native http module instead of large frameworks to keep the initial module-loading overhead low.
3. Monitor RSS, Not Heap: When setting container memory limits, base your calculations on the process RSS, as the container orchestrator (like Kubernetes) triggers OOM kills based on resident memory, not V8's internal heap metrics.

Verification Command

To verify your specific baseline, run your server and use the following command to check the actual memory usage from the runtime's perspective:

console.log(process.memoryUsage());

Compare the rss value (total memory allocated for the process) against heapUsed (memory actually used by JS objects) after the server has been idle for several minutes.

Missing Diagnostic Detail: Are you running this workload in a containerized environment (e.g., Docker/K8s) or on a bare-metal/VM OS? This changes whether you should prioritize V8 heap flags or OS-level memory cgroup limits.