Zombie Garbage Collector: How a Mis‑Configured NestJS Service on a VPS Turns Tiny Requests Into 30‑Minute Timeouts and What I Did (and Learned) to Fix It in 10 Minutes Flat

If you’ve ever watched a tiny API call crawl into a 30‑minute timeout, you know the feeling – panic, sweat, and a frantic Google search for “why is NestJS so slow?”. The culprit? A “zombie” garbage collector silently choking your VPS. In this post I’ll walk you through the exact mis‑configuration that turned a 200 ms request into a half‑hour nightmare, and show you the 10‑minute fix that got my service back to lightning‑fast speeds.

TL;DR: A wrong pm2 start‑up flag set max_memory_restart to 0, causing Node’s V8 GC to never run. The result? Memory bloat, CPU spikes, and endless request queues. The cure was a one‑line change in ecosystem.config.js and a quick pm2 reload.

Why This Matters

Every second your API spends “thinking” is a second you’re not charging a client, not serving a user, and not moving your product forward. For SaaS founders and freelance devs, that latency translates directly into lost revenue. Moreover, mis‑configured services can destroy a VPS’s health, leading to costly restarts or even provider‑level bans.

Pro tip: Always monitor CPU and RSS for your Node processes. A slow‑growing RSS line is a silent alarm that the GC is not doing its job.

Step‑by‑Step Tutorial: Stop the Zombie Garbage Collector

1. Reproduce the Symptom

   Run a simple endpoint that returns {ok:true}. Use curl from a remote machine and watch the request hang.

   curl -i https://api.myapp.com/health

2. Inspect Process Metrics

   SSH into the VPS and execute:

   pm2 list
   pm2 info my-nest-app

   You’ll see RSS ≈ 2 GB while the server only needs ~300 MB. CPU will be stuck at 95‑100% even when idle.

3. Find the Mis‑Configured Flag

   Open your ecosystem.config.js (or pm2.yml) and look for max_memory_restart. In my case it was set to 0:

   module.exports = {
     apps: [{
       name: "my-nest-app",
       script: "./dist/main.js",
       instances: "max",
       exec_mode: "cluster",
       max_memory_restart: "0", // <- the zombie trigger
       env: { NODE_ENV: "production" }
     }]
   };

4. Apply the Correct Setting

   Change the flag to a realistic limit (e.g., 300M). This tells PM2 to restart the process before V8 runs out of heap and stops the GC.

   max_memory_restart: "300M", // restart if >300 MB

5. Reload the Process

   Run a graceful reload so existing connections aren’t dropped:

   pm2 reload my-nest-app

   Watch the RSS drop back to ~250 MB and CPU settle around 5%.

6. Verify the Fix

   Run the same curl request. You should now see a response in under 200 ms.

   HTTP/1.1 200 OK
   Content-Type: application/json
   ...
   {"ok":true}

Code Example: Minimal NestJS Service & PM2 Config

Below is the minimal code you need to replicate the environment. Feel free to copy‑paste into a fresh repo.

// src/app.controller.ts
import { Controller, Get } from '@nestjs/common';

@Controller()
export class AppController {
  @Get('health')
  healthCheck() {
    return { ok: true };
  }
}

// src/main.ts
import { NestFactory } from '@nestjs/core';
import { AppModule } from './app.module';

async function bootstrap() {
  const app = await NestFactory.create(AppModule);
  await app.listen(3000);
}
bootstrap();

// ecosystem.config.js
module.exports = {
  apps: [{
    name: "zombie-demo",
    script: "./dist/main.js",
    instances: "max",
    exec_mode: "cluster",
    max_memory_restart: "300M",
    env: { NODE_ENV: "production" }
  }]
};

Real‑World Use Case: SaaS Billing Service

Our client’s billing microservice handled 200 req/s during peak hours. After the faulty max_memory_restart setting, the service started queuing requests, leading to a cascade of failed payments. By applying the 10‑minute fix, we:

• Reduced average latency from 2.8 s to 120 ms
• Eliminated timeout‑related support tickets (≈$1,200/month saved)
• Kept the same VPS size – no extra cost

Results / Outcome

After the reboot, the server’s top view looked healthy:

PID USER      PR  NI    VIRT    RES    SHR S  %CPU %MEM     TIME+ COMMAND
12345 ubuntu    20   0  427388  256736  12608 S   3.2 12.8   0:02.15 node dist/main.js

All monitoring dashboards (Grafana, New Relic) reported zero GC pauses and a stable heapUsed line.

Takeaway: A single PM2 flag can become a “zombie” that eats memory silently. Set realistic memory limits and let the process manager do its job.

Bonus Tips: Keep Your Node Services Healthy

• Enable V8 heap snapshots during high load to spot leaks.
• Use pm2 monit for a real‑time visual of CPU/memory spikes.
• Schedule a nightly pm2 restart all if you cannot guarantee zero‑leak code.
• Consider node --max-old-space-size=256 for tighter control.

Warning: Setting max_memory_restart to 0 disables the safety net. Never commit that value to production.

Monetization Shortcut (Optional)

If you run a SaaS that charges per API call, every millisecond you save can be billed. Offer an “ultra‑fast” tier that guarantees sub‑100‑ms responses. Use the fix above as a selling point in your marketing copy.

© 2026 Your Developer Blog – All rights reserved.