Zero-Growth Stack, Real Gains: How Stack Allocation Can Save 10% CPU in Go

Summary

At Uber, repeated Go goroutine stack expansion consumed substantial CPU in a service whose stack-memory usage remained low, making memory a viable trade-off. Go starts goroutines with 2KB stacks and doubles them when needed, copying the previous stack; the post also notes that adaptive stack sizing and stack shrinking can add runtime cost. Uber patched the runtime, disabled adaptive sizing and shrinking, and used profile-guided analysis of pprof traces plus assembly-derived function stack usage to choose a static power-of-two starting size. For the profiled service, the analyzer identified about 19KB of required stack usage, leading to a 32KB setting instead of 2KB. After deployment, stack-growth CPU fell from close to 10% to below 1%, while most instances used about 50MB of stack and a few reached 200MB.

Takeaways

1. 1

   Go goroutines begin with 2KB stacks and expand by allocating a stack twice as large and copying the previous contents, which can create significant CPU overhead.

2. 2

   Uber’s analyzer filters pprof traces reaching copystack and uses assembly instructions to calculate stack usage for each function and trace. A roughly 19KB requirement maps to a 32KB power-of-two starting stack.

3. 3

   Moving the service’s starting stack from 2KB to 32KB reduced stack-growth CPU from close to 10% to below 1%; most instances used about 50MB of stack, while a few reached 200MB.

FAQ