• The Go Blog Container-aware GOMAXPROCS Go 1.25 includes new container-aware GOMAXPROCS defaults, providing more sensible default behavior for many container workloads, avoiding throttling that can impact tail latency, and improving Go’s out-of-the-box production-readiness. • In this post, we will dive into how Go schedules goroutines, how that scheduling interacts with container-level CPU controls, and how Go can perform better with awareness of container CPU controls. • GOMAXPROCS One of Go’s strengths is its built-in and easy-to-use concurrency via goroutines. • From a semantic perspective, goroutines appear very similar to operating system threads, enabling us to write simple, blocking code. • On the other hand, goroutines are more lightweight than operating system threads, making it much cheaper to create and destroy them on the fly. • While a Go implementation could map each goroutine to a dedicated operating system thread, Go keeps goroutines lightweight with a runtime scheduler that makes threads fungible.

Article Summaries:

  • Container‑aware GOMAXPROCS Go 1.25 introduces a new default for GOMAXPROCS that is aware of container CPU limits. Previously, GOMAXPROCS defaulted to the total number of logical CPUs on a host, which could cause unnecessary thread oversubscription when a Go application runs inside a container with restricted CPU quotas. The updated default now aligns the number of runnable threads with the container’s CPU allocation, reducing OS‑level scheduling overhead, preventing throttling that hurts tail latency, and improving Go’s out‑of‑the‑box production readiness for container‑orchestrated workloads.

Sources: