---
name: gc-or-allocator-pressure
description: Diagnose Go GC, allocation churn, and allocator/profile-driven CPU or latency root causes.
---

# Use When

Use this family subskill when allocation churn, Go GC pause/frequency/duration, or allocator
hot paths are the primary latency/CPU amplifier or root mechanism.

# Required Evidence

- `go_gc_duration_seconds`, `go_gc_pauses_seconds`, and related count/sum/bucket series.
- GC frequency, pause P99, duration rate, or STW evidence on affected instances.
- Continuous profiling or allocation stack evidence when claiming GC is primary.

# Classification

- `standard_root_cause_class`: `gc_or_allocator_pressure`
- compatible `primary_class`: `tidb_cpu_gc_or_memory`
- common symptom tags: `gc_signal`, `high_cpu`, `slow_query`
- specialist skills: `tidb-perf-diagnosis`, continuous profiling

# Decision Rules

- For high TiDB CPU, GC checks are mandatory.
- Mark GC as secondary when it is downstream of large scans or memory-heavy SQL and does not
  explain most CPU/latency by itself.
- Heap profile, dominant allocation stack, or known fixed issue correlation can make this
  family primary when it explains the user-visible latency or CPU path better than workload,
  SQL plan, lock, or capacity evidence.
- Do not claim GC or allocator pressure as primary from pause metrics alone. Require profile,
  dominant stack, known issue correlation, or a clear GC duration/frequency chain that explains
  the user-visible latency better than SQL plan, lock, or capacity explanations.
- Recommend continuous profiling when GC is abnormal and primary/contributing status needs
  confirmation.

# Final Response Anchors

- State whether GC is `primary`, `contributing`, or `secondary`.
- Include GC metric names and recommend continuous profiling when abnormal.