What does runtime.MemProfileRate control in Go, and what is its default value?

## The rate is a byte interval, not a percentage `runtime.MemProfileRate` is a plain `int` variable in the `runtime` package holding a number of bytes. The profiler's goal is to record roughly **one allocation for every `MemProfileRate` bytes allocated** across the whole program. Its default value is 512 KB (524288). So it is not "sample 1% of allocations" and not "sample every 512 KB *of one allocation site*". It is a global byte odometer: as your program allocates, every time it has passed roughly another `MemProfileRate` bytes, the allocation that trips the counter is recorded with its full call stack. ## Why sampled at all Recording every allocation with a stack trace would be ruinous. Go programs allocate constantly — every string concatenation, every append that grows, every interface box — and capturing a stack per allocation would dominate runtime and inflate the profile itself. Sampling at 512 KB makes memory profiling cheap enough to leave **on by default in every Go program**, which is why you can pull a heap profile from a production service that was not started in any special mode. That default-on property is the reason the rate is chosen the way it is. ## Scaling: why the numbers are estimates A sampled allocation stands in for the allocations the profiler did not record around it, so the runtime scales each sample up when it builds the profile. A stack that truly allocated 8 GB will report close to 8 GB even though only a few thousand allocations were captured. The consequence for reading a profile is that **large entries are trustworthy and small ones are noisy**. If one site shows 40 GB and another shows 12 GB, that ordering is real. If two sites show 512 KB and 1 MB, you may be looking at one and two sampled allocations, and the difference means nothing. Anything that allocates only a little, or allocates only on a rare path, may not appear at all. ## Turning the resolution up When you want exact attribution — typically in a benchmark that isolates one function — set the rate to 1: ```go func init() { runtime.MemProfileRate = 1 // record every allocation: benchmarks only } ``` or pass `go test -memprofilerate=1` for that run. Now every allocation is recorded, the counts are exact, and the program is much slower and holds far more profiling state. This is a measurement mode, not an operating mode. Setting it to 0 disables memory profiling. That saves a small amount of work but costs you the ability to diagnose a memory problem in that process at all, which is almost never a trade worth making in a service. ## Set it once, early The rate should be changed at most once, as early in execution as possible. If you flip it halfway through a run, the profile you eventually write is a mixture of records gathered under different scaling assumptions, and the totals are meaningless. Treat it as a startup decision, not a runtime knob. ## What it does not change It does not change what the profile measures, only how finely. The four sample indexes — live bytes, live objects, cumulative bytes, cumulative objects — are the same at any rate. It also does not affect CPU profiling, blocking or contention profiles; those have their own independent controls. ## Interview-shaped takeaways * Default 512 KB, expressed in bytes allocated per sample. * Numbers in a heap profile are **scaled estimates**; treat small entries with suspicion. * 1 = record everything (benchmarks), 0 = off. * Set once at startup. * Memory profiling is on by default in every Go program, which is why the rate matters: it is a permanent, low-grade tax that buys you always-available diagnosis.