Mark assist
Marking work done by an allocating goroutine itself, when the program allocates faster than the background workers can mark.
Marking work done by an allocating goroutine itself, when the program allocates faster than the background workers can mark.
During a cycle the runtime tries to finish marking before the heap reaches the goal. Dedicated background workers use 25 percent of the processors. If a goroutine allocates faster than they progress, it is charged and must do a proportional amount of marking before its allocation can proceed: an assist.
Assists show in the gctrace line as the first number of the CPU time triple (assist, background, idle) and as extra latency for requests that allocate heavily. Persistent assists suggest that the heap goal is too close to the live heap (raise GOGC or the memory limit) or that the allocation rate is too high.
Official documentation: A Guide to the Go Garbage Collector
GOGC
The main Go GC tuning knob: the percentage of the live heap that may be allocated before the next cycle starts. The default is 100.
With GOGC=100, the heap goal is twice the live heap (plus stacks and globals, since Go 1.18): a program with 100 MiB of live heap starts a cycle at about 200 MiB. Doubling GOGC doubles the extra memory and roughly halves the CPU cost of GC, and the other way round. Set it with the GOGC environment variable or debug.SetGCPercent. GOGC=off disables the collector, which is only reasonable together with a memory limit.
In gctrace, compare the heap sizes (at start, at end, live) with the goal. A program with a small, stable live heap and plenty of spare memory can raise GOGC to spend less CPU on GC. A program in a container close to its memory limit should rather use GOMEMLIMIT.
Official documentation: A Guide to the Go Garbage Collector
Heap goal
The total heap size at which the Go runtime wants the current collection to have finished.
At the end of each cycle the runtime computes the goal from the live heap, the stacks, the globals and GOGC (goal = live + (live + stacks + globals) x GOGC / 100), or from the memory limit if it is lower. The pacer starts marking early enough to finish as the heap reaches the goal: earlier when the allocation rate is high or marking is slow.
In gctrace the goal appears as the MB goal field. If the heap routinely overshoots it, the pacer is losing the race: expect mark assists and little margin.
Official documentation: A Guide to the Go Garbage Collector
Mark assist