# Memory Growth And OOM

## Question

Which process and memory consumer grew before the OOM/restart, and what
workload, backlog, or leak path directly explains it?

## Enter When

Use for memory growth, OOM, restart, heap-profile evidence, coprocessor task
backlog, transaction-lock memory, cache/buffer growth, or suspected leak.

## First Batch

1. Align process/container memory, OOM/restart time, and the affected instance.
2. Use available OOM record, heap profile, memory-consumer metrics, or
   mechanism-specific logs to locate the growing owner.
3. Correlate only the relevant workload/backlog through customer Digests,
   expensive-query/Slow Query, TopSQL, task queue, or lock evidence.

## Decision

Memory growth plus a coincident SQL is not attribution. Require the consumer or
allocation path to connect the workload/backlog to growth. Separate a bounded
workload spike from persistent leak-like growth. Treat old configuration
workarounds and fixed-version claims as unverified until checked for the target
version.

## Strongest Alternative And Stop

Check container limit/host pressure and restart reason as the strongest
alternative. Stop after identifying the consumer boundary or naming the exact
missing heap/OOM artifact. Never trigger profiling or configuration changes
when the provider contract does not explicitly allow safe read-only capture.