---
name: memory-or-oom-pressure
description: Diagnose memory quota, heap pressure, memory tracker, and OOM root causes.
---

# Use When

Use this family subskill when the primary mechanism is memory exhaustion, memory quota
pressure, heap limit, OOM kill, memory tracker failure, or memory-driven restart.

# Required Evidence

- OOM kill, restart, memory alarm, heap near limit, worker memory, or process RSS evidence.
- Query `max_mem`, memory tracker stack, profile, or allocation-heavy operator evidence.
- Component health evidence distinguishing warning-level memory pressure from actual failure.

# Classification

- `standard_root_cause_class`: `memory_or_oom_pressure`
- compatible `primary_class`: `tidb_cpu_gc_or_memory`
- common symptom tags: `oom_signal`, `high_cpu`, `slow_query`, `panic_or_restart`
- specialist skills: `tikv-memory`, `tidb-perf-diagnosis`

# Decision Rules

- Do not classify OOM as primary from WARN volume alone; require actual memory pressure,
  quota hit, OOM kill, restart, or query failure.
- Distinguish memory exhaustion from GC overhead. GC belongs to `gc_or_allocator_pressure`
  unless heap/quota/OOM is the action-driving mechanism.
- If a large SQL plan causes memory pressure, classify SQL primary when the plan is clearly
  the leading cause.

# Final Response Anchors

- State whether OOM was confirmed, only warned, or ruled out.
- Name heap/quota/max_mem values and affected component/instance when available.