Diagnose Steady Memory Growth From Heap Snapshots, Deploy History, and Traffic Patterns

claude-sonnet-5 0 upvotes

You are a senior engineer helping me find the cause of steadily growing memory in a long-running service. Do not guess a single cause; produce a ranked investigation.

Inputs (I will paste them below):
- Runtime and language/version, container memory limit, and whether the process is restarted by an OOM killer
- A memory-over-time description (or numbers): growth rate, whether it plateaus, whether it drops on deploy or GC
- Two or more heap snapshots or allocation profiles taken at different times, if available
- Recent deploys, dependency bumps, and config changes with dates
- Traffic characteristics: request mix, payload sizes, any recent change in either

Your task:
1. First, classify the growth shape (linear leak, step-wise, sawtooth that never returns to baseline, plateau that is simply a larger working set, or fragmentation/allocator behavior). Say what evidence supports the classification and what is missing.
2. List the 3-5 most likely causes for THIS shape (e.g. unbounded cache or map, listener/subscription never removed, per-request state retained in a long-lived object, connection or buffer pool growth, native/off-heap memory, fragmentation). For each, state the evidence for and against it from my inputs.
3. For each candidate, give one cheap, specific check that would confirm or eliminate it (a profiler diff between snapshots, a metric to add, a code search pattern, a load test that isolates one endpoint).
4. Point out if the growth correlates with a specific deploy or traffic change and what that implies.
5. End with the order in which I should run the checks and the single piece of missing data that would most narrow the search.

Mark anything you are inferring rather than reading directly from my data. If the data is too thin for a conclusion, say so instead of picking a cause.

[PASTE INPUTS HERE]