Does PM2 Cluster Mode impact memory overhead when using the max instance setting?

Answer to the Question

Yes – when PM2 runs in cluster mode with instances: max, the total memory footprint grows roughly linearly with the number of logical CPU cores. Each worker is a distinct Node.js process with its own V8 heap, so the master process plus the monitoring stack add only a small, constant overhead.

Confirmed Facts

• Master process memory: ~10–20 MB, independent of worker count.
• Each worker starts with a fresh V8 heap; the first worker may inherit a bit of the master’s memory, but subsequent workers start clean.
• Per‑worker memory usage is dominated by the application’s code, data, and any libraries it loads.
• Total memory ≈ (worker count × per‑worker memory) + master overhead + PM2 monitoring overhead.

Likely Explanation

Because the max setting tells PM2 to spawn one worker per logical CPU core, an 8‑core host will run eight separate Node.js processes. If each worker consumes ~200 MB under load, the cluster will use ~1.6 GB plus the master’s ~15 MB, yielding ~1.6 GB total. Memory leaks in any worker can quickly inflate the aggregate usage.

Steps to Verify Your Own Overhead

1. Run a single instance:

   pm2 start app.js
   pm2 monit
   

   Record the RSS (Resident Set Size) shown for the worker.
2. Run cluster mode with max workers:

   pm2 start app.js -i max
   

   Use pm2 monit or ps -o pid,rss -p $(pm2 pid ) to capture each worker’s RSS.
3. Sum the RSS values of all workers plus the master process’s RSS (visible in pm2 monit).
4. Compare the total to the single‑instance value. A linear increase indicates no hidden shared memory.

Can PM2 Limit Aggregate Memory Without Fixing Instance Count?

PM2 itself does not expose a per‑cluster memory cap. The max option simply caps the worker count. To constrain total memory you typically:

• Set a fixed instances value that fits your RAM budget.
• Use OS‑level limits (cgroups, ulimit, Docker resource constraints) to cap each worker or the whole process group.
• Implement graceful restart logic that monitors process.memoryUsage() and triggers a reload if a threshold is exceeded.

Missing Diagnostic Detail Needed?

To give a precise recommendation on whether instances: max is safe for your environment, we need the average per‑worker memory usage under realistic load. If you can provide that figure, we can calculate the expected aggregate footprint and advise whether a stricter worker count or OS limits are warranted.