In a gctrace line, what do `42->44->21 MB` and the `3%` field mean?

## The whole line A complete gctrace line has this shape: ``` gc 47 @12.043s 3%: 0.11+5.8+0.09 ms clock, 0.9+1.4/4.2/0+0.7 ms cpu, 42->44->21 MB, 43 MB goal, 1 MB stacks, 0 MB globals, 8 P ``` Each group answers a different question, and the two asked about here are the two people misread most often. ## `42->44->21 MB` — three heap sizes, not one The triple is **heap size at the start of the cycle**, **heap size at the end of the cycle**, and **live heap** — the bytes marking proved were still reachable. The first number tells you where the collector fired. It is a trigger point, not a measure of your program's appetite for memory: the collector starts a cycle when the heap reaches its target, so this number tracks the target far more than it tracks your data. The second number is almost always larger than the first, and that is expected rather than alarming. Go marks concurrently: the program keeps running and keeps allocating for the whole marking phase, so the heap grows underneath the collector. The gap between the first two numbers is roughly how much the program allocated while the cycle was in flight. A cycle that takes a long time to mark, on a program that allocates fast, shows a big gap. The third number is the one that matters for retention. It is the live heap: the memory that survived. If your program is genuinely accumulating memory it cannot release, this number climbs, cycle after cycle, and drags the trigger point and the collection frequency up behind it. If it is flat across hundreds of cycles, whatever else is going on, the reachable heap is not growing. A common mistake is to read the third number as "the memory this process uses". It is not. It is the live Go heap at one instant, measured immediately after marking. The process also holds goroutine stacks, runtime metadata, and heap spans the runtime has emptied but not handed back to the operating system, none of which appear in that number. ## `3%` — cumulative, not current The percentage is the share of the program's total available CPU time that has gone into garbage collection **since the process started**. It is an average over the whole run, not a reading for the cycle on that line and not a rolling window. The consequence is worth stating explicitly, because it catches people during an incident. A service that has been up for ten hours accumulated ten hours of denominator. If it began collecting furiously twenty minutes ago, those twenty minutes are diluted by the ten calm hours before them, and the percentage barely moves. Reading it as "we are fine, GC is only at 3%" during an incident is a real and common error. The way to get a recent figure is to difference two samples: note the percentage and the timestamp on one line, note them again some minutes later, and reason about the change. Failing that, the honest recent signals are elsewhere on the line: the phase timings getting longer, and the `@…s` timestamps of consecutive cycles crowding closer together. ## The other fields, briefly `gc 47` is the cycle counter and `@12.043s` the seconds since start-up; together they give you collection frequency for free — subtract consecutive timestamps. `0.11+5.8+0.09 ms clock` is wall-clock time for the cycle's three phases: **stop-the-world sweep termination**, **concurrent mark and scan**, and **stop-the-world mark termination**. The first and third are the pauses; the middle is concurrent work overlapping your program. So in that example the program was actually stopped for about 0.2 ms in total, even though the cycle spanned nearly six milliseconds. `0.9+1.4/4.2/0+0.7 ms cpu` is CPU time for the same work summed across processors. The middle three figures split the concurrent phase into assist time (collection performed inline with allocation), background collector time, and idle time. `43 MB goal` is the heap size the collector was aiming to finish under for that cycle. `1 MB stacks` and `0 MB globals` report the scannable goroutine-stack and global-variable memory. `8 P` is how many logical processors the runtime was using. ## Reading the series One line is a snapshot. The value is in a stretch of them, and there are three trends worth naming. A rising third number means real retention. Falling gaps between timestamps mean cycles are crowding — the program is allocating faster or the heap target is not moving up with it. A growing middle clock figure means marking itself is taking longer, which usually follows from more live pointers to trace.