Assist Ratio Spikes: Behavior During Traffic Surges¶
Context¶
A key question when increasing GOGC is: "What happens when allocation suddenly spikes?" The theoretical answer is that assistRatio increases, forcing mutators to do mark work and creating backpressure. But what does this look like in production?
Theoretical Prediction¶
From GC Pacer and Allocation articles:
When allocation outpaces GC: 1. Heap grows faster than expected 2. assistRatio increases exponentially 3. Allocators perform mark assist work 4. Backpressure slows down allocation rate 5. Heap growth is throttled
Production Observation¶
Campaign Start: Traffic Spike¶

Observations during traffic spike: 1. Transient assistRatio increases: Sharp but brief spikes in assist ratio 2. No runaway heap growth: Memory growth rate flattened, stabilized within bounds 3. Quick stabilization: assistRatio returned to baseline within minutes
After Traffic Normalized¶
Observations: 1. assistRatio decreased: Returned to baseline levels 2. Background workers handled marking: No extended assist periods 3. No latency degradation: STW and API latency remained stable
Why This Matters¶
Common Fear: "Spiral of Death"¶
Concern that increased GOGC could cause: - Allocation spike → higher assistRatio → more GC work → slower allocation → higher assistRatio → ...
Reality: Self-Regulating System¶
The production data shows: 1. Brief spikes, not sustained elevation: assistRatio spikes are transient 2. Effective throttling: Heap growth rate flattens before hitting limits 3. No latency impact: P99 remains stable despite assist work
Quantitative Evidence¶
From our 67 services during campaign start:
| Metric | Observation | Interpretation |
|---|---|---|
| assistRatio spike duration | < 5 minutes | Transient, not sustained |
| Heap growth rate | Flattened after spike | Effective throttling |
| API P99 latency | Stable (< 5% change) | No user-visible impact |
| STW P99 | Stable | Assist work didn't prolong pauses |
Theoretical Validation¶
This confirms our understanding from Allocation and GC article:
Assist Mechanism Works as Designed¶
- Feedback loop:
assistRatioresponds to allocation rate - Backpressure: Mutators are throttled just enough to prevent OOM
- Self-correcting: Once GC catches up,
assistRatiodecreases
Key Insight¶
The assist ratio spike is transient because: 1. Background workers are always marking, reducing total work needed 2. Mark assist is incremental—small amount per allocation 3. Pacer recalculates each GC cycle, adjusting to new conditions
Practical Implications¶
For Bursty Workloads¶
Services with: - Sudden traffic spikes (e.g., campaigns, events) - Batch processing windows - Uneven allocation patterns
Can safely use higher GOGC—the assist mechanism provides natural throttling without user-visible impact.
For Monitoring¶
Key metrics to track: - assistRatio spike frequency: Should be transient (< 5 minutes) - Heap growth rate during spikes: Should flatten, not accelerate - API latency during spikes: Should remain stable
For Tuning¶
- Don't fear assist work: It's the runtime's safety mechanism
- Do monitor spike duration: Sustained high
assistRatioindicates deeper issues - Do check latency: If P99 degrades during spikes, reduce
GOGC
Edge Cases¶
When Assist Spikes Indicate Problems¶
- Sustained elevation:
assistRatiostays high for > 10 minutes - Latency degradation: P99 increases significantly during spikes
- Heap growth acceleration: Rate doesn't flatten during spikes
These indicate: - GOGC is too aggressive for the workload - Memory headroom is insufficient - Allocation pattern is pathological (e.g., massive objects)
Related Topics¶
- Allocation and GC - How assist work works
- GC Pacer Theory - Assist ratio in trigger calculation
- Memory Lock Behavior - How memory stabilizes