performance-observabilityAnswer last reviewed July 2026

Suppose your p99 shows these periodic spikes and they line up with garbage collection. How do you think about that, and what would you actually change?

A strong answer ties GC pauses to the latency-tail spikes and reaches for allocation rate as the first lever, long before any GC tuning flag

What an AI-prepared candidate might say

So V8's garbage collector is generational. Most objects die young and get collected quickly in the young generation by minor GCs, which are fast. Objects that survive get promoted to the old generation, and that gets collected by major GCs, which are more expensive and can pause the process. And since Node runs your JavaScript on one thread and GC runs on that same thread, a long major GC blocks your request callbacks, which is basically the latency spike you're seeing. To cut the impact you want to make less garbage. Avoid allocations you don't need, reuse buffers and objects, drop references you're done with. There are flags like --max-old-space-size to tune the heap, but that's kind of a blunt tool. Lowering allocation pressure is usually the better move, since GC then runs less often and has less to do. --trace-gc or performance hooks tell you how much time actually goes to collection.

Senior
Locked

Why the generational design keeps minor GC cheap while major GC is the pause that hurts, how that pause turns into tail latency, and why allocation rate drives all of it.

Unlock the depth
Staff
Locked

How to measure GC pause time against your SLO, cut allocation pressure before you touch a single flag, and tell when a heap-size change helps and when it just hides the problem.

Unlock the depth
Follow-up chain
Suppose your p99 shows these periodic spikes and they line up with garbage collection. How do you think about that, and what would you actually change? | NodeBook