Memory Profiling: It's Not Just CPU

The Silent Killer

CPU issues make things slow. Memory issues make things crash — specifically, they trigger an OOM Kill (Out Of Memory Kill), where the Linux kernel forcibly terminates your process because the node has run out of RAM. Kubernetes then restarts the pod, which can cause cascading failures if the memory leak is fast enough.

Continuous profilers track memory allocation in two distinct ways:

• inuse_space (Live heap): How much memory is the application holding right now? This is the metric for finding memory leaks — functions that allocate memory and never release it. A rising inuse_space over time is a classic leak signature.
• alloc_objects (Allocation rate): How many objects is the application creating per second, regardless of whether they're immediately freed? This finds allocation churn — code that creates and discards millions of short-lived objects, which is fast but forces the Garbage Collector (GC) to run constantly.

The CPU-Memory Interaction Trap

This is a subtle failure mode that trips up many engineers. Consider this scenario:

1. A function read_file() reads a large file into memory on every request.
2. On the CPU flamegraph, read_file() appears as a narrow bar — it runs quickly.
3. On the memory flamegraph, read_file() appears as a very wide bar — it allocates hundreds of megabytes per second.
4. The GC must constantly collect this memory, which pauses the application and shows up as mysterious CPU spikes attributed to the runtime, not to read_file().

Without memory profiling, you would spend hours trying to optimize the wrong functions. The CPU flamegraph alone is misleading because the cause (allocation in read_file) and the symptom (GC CPU spikes) appear in different places.

Rule of thumb: Always look at both CPU and memory flamegraphs together. A function that is narrow on CPU but wide on memory is often the root cause of CPU problems you cannot explain from the CPU flamegraph alone.