Senior · Design · A complete memory incident investigation

How would you run a repeatable memory investigation across several service replicas?

Think through your answer before opening the explanation.

Memory & GC

Reveal answer and reasoning

Choose the observed ownership defect or allocation bottleneck explicitly. An unbounded cache needs a retention policy; a slow finalizer needs a resource-release investigation; excessive temporary copies may need a pipeline change; native growth needs native evidence. Apply one meaningful change and rerun the same workload. Verify correctness, peak memory, recovery after idle, throughput and latency rather than selecting only the chart that improved.

For an interview, present your evidence chain: symptom, aligned measurements, representative retained types, root path, intended lifetime, intervention and repeatable result. Explain alternative hypotheses and which observation would distinguish them. A strong answer admits when managed evidence is insufficient to explain a process-memory delta, and it does not use a local microbenchmark as proof that a clustered production system has been load-tested.

Change the synthetic fixture so managed live memory rises almost as much as process memory. Explain why retained managed graphs become a more plausible next target without asserting causation from correlation alone. Then keep managed live flat and increase only the process measurement, listing at least three nonmanaged or accounting explanations worth checking.

Write an incident worksheet for two replicas with different traffic partitions. Include deployment identity, timestamps, workload counts, GC indexes, allocation deltas, retained-type evidence and the exact ownership edge you plan to change. Finish by defining a passing recovery condition after an idle interval and a failing condition under renewed load, so the investigation ends with a testable improvement rather than a reassuring screenshot.

What a strong answer covers

  • A managed heap snapshot is not a complete process-memory account.
  • Allocation rate, last-GC snapshots and RSS need aligned observation windows.
  • A retaining path proves ownership; a large type count alone does not prove a leak.

Common pitfall

Subtracting an unaligned managed snapshot from working set and labeling the remainder an exact native-memory total.

Follow-up questions

  1. How do you prove two snapshots came from the same replica and workload phase?
  2. Which result would falsify your proposed retention fix?

Self-review

Choose what to revisit. These marks are your own assessment and are separate from lesson completion.

Primary references

Open lesson and code ↗

← All interview questions