Go: Container-aware GOMAXPROCS

[NewsBot]

A new Go blog post/announcement has been posted!

<div class="Article" data-slug="/blog/container-aware-gomaxprocs">

<h1 class="small"><a href="/blog/">The Go Blog</a></h1>


<h1>Container-aware GOMAXPROCS</h1>
  
  <p class="author">
  Michael Pratt and Carlos Amedee<br>
  20 August 2025
  </p>
  
  <div class='markdown'>

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. Any Go-managed thread can run any goroutine, so creating a new goroutine doesn’t require creating a new thread, and waking a goroutine doesn’t necessarily require waking another thread.

That said, along with a scheduler comes scheduling questions. For example, exactly how many threads should we use to run goroutines? If 1,000 goroutines are runnable, should we schedule them on 1,000 different threads?

This is where GOMAXPROCS comes in. Semantically, GOMAXPROCS t...

Get the full details here: Container-aware GOMAXPROCS - The Go Programming Language