Only 54 µs of that 68 ms collection was a pause
A gctrace line carries eleven numbers. Two are stop-the-world, one has a third of the GC subtracted out of it, and the biggest one is not a pause at all.
−04 · Category
Runtime internals
The scheduler, the memory allocator, the garbage collector, goroutine stacks, the netpoller, runtime/trace. What actually happens beneath a language feature.
Articles in “Runtime internals”
7 articlesRuntime internals
Green Tea cut my GC time 63%, and raised it 39%
One heap shape lost 63% of its collector CPU and gained 14% throughput. Another gained 39% collector CPU and lost nothing. Same flag, same binary pair, same machine.
The GOGC I set next to GOMEMLIMIT never fired
GOGC=100 with a 256 MiB limit produced exactly what GOGC=off produced: same collections, same CPU share, same throughput. The tighter rule binds, the other goes quiet.
A 1 MiB goroutine stack costs 136µs and reports 144 B/op
Reaching a 1 MiB stack copied it nine times. The copying cost 136µs of CPU that -benchmem reports as 144 bytes, because stack memory is not heap memory.
GOMAXPROCS is not your thread count
GOMAXPROCS=1 with 200 goroutines blocked in read(2) produced 202 OS threads. Measured on go1.27.0, alongside the container case Go 1.25 changed.
sync.Pool survives one GC, not two
A pool holding 100 objects lost none across one collection and all 100 across two. Here is the victim cache, and what it costs at 122,000 ops per millisecond.
What the Go scheduler does when your goroutine blocks
A blocking syscall costs an OS thread. A blocking network read costs nothing. Measured with 200 goroutines, GOMAXPROCS=2 and a thread count.