Server
Garbage collection pause
Also called GC pause.
Garbage collection pause is a stretch where the runtime stops or slows your code to reclaim unused memory. Requests that arrive during it simply wait.
How it is measured
Read it from GC logs or runtime metrics: pause duration per collection in milliseconds, collections per minute, and the share of wall time spent collecting. In the JVM that is `-Xlog:gc`, in Node it is `--trace-gc` or `perf_hooks`, in Go it is `GODEBUG=gctrace=1`.
Short young-generation pauses of a few milliseconds are normal. A full collection of 800 ms or more, repeating every few minutes, is the pattern that shows up as a flat band of slow requests in p99.
Worked example
A Java search service for a catalogue runs with a 6 GB heap and a p50 of 35 ms. Every four minutes p99 jumps to 1.1 seconds for a few seconds. GC logs show a full collection of 940 ms each time, triggered when old-generation memory fills.
Switching to a collector tuned for low pauses and trimming a 1.4 GB in-memory cache cut the worst pause to 45 ms, and the four-minute spikes vanished from the latency chart.
How it differs
A GC pause is time the runtime takes your threads away to clean memory. A memory leak is memory that never becomes free at all. A pause happens even in a healthy process, and a leak makes pauses longer and more frequent over time. Tail latency is the symptom users see from either.
Common errors
Blaming the network for a regular once-every-few-minutes spike. Reading only average latency. Giving the heap more memory and getting longer, rarer pauses. Allocating huge short-lived objects in a hot path. Tuning flags without reading the GC log first.
In practice
Turn on GC logging for one service this week and line the pause timestamps up with your p99 graph. If they match, reduce allocation in the hottest endpoint before touching collector settings.