GOMAXPROCS define el número máximo de hilos del sistema operativo (OS threads) que pueden ejecutar código Go de forma simultánea. Aunque solemos pensar en la concurrencia a través de las goroutines, estas no corren solas; necesitan un contexto de ejecución para avanzar. En el modelo de programación de Go (conocido como modelo G-M-P), el P representa un recurso de procesamiento lógico. GOMAXPROCS controla cuántos de estos recursos P existen.
Para entender por qué esto es crucial, debemos separar la concurrencia (la estructura de tu código para manejar múltiples tareas) del paralelismo (la ejecución real de esas tareas en distintos núcleos de CPU al mismo tiempo). Las goroutines son entidades lógicas muy ligeras, pero para que una goroutine se ejecute, debe estar asociada a un hilo del sistema operativo (M) a través de un procesador lógico (P).
Si intentas ejecutar más hilos de los que tus núcleos físicos permiten, el sistema operativo se verá obligado a realizar context switching (cambiar rápidamente entre hilos), lo que consume ciclos de CPU valiosos en la gestión del kernel en lugar de en tu lógica de negocio. Por eso, aumentar GOMAXPROCS sin tener el hardware para respaldarlo solo introduce latencia y contención de memoria.
En la mayoría de los escenarios, no necesitas tocar este valor, ya que Go lo establece por defecto igual al número de núcleos lógicos de la máquina [disponible desde Go 1.5]. Sin embargo, el momento crítico surge en entornos de contenedores como Docker o Kubernetes. Si tu contenedor tiene un límite de CPU de 2 núcleos pero el host tiene 64, la runtime de Go leerá erróneamente los 64 núcleos del host. Esto provoca que la aplicación intente lanzar demasiados hilos, peleándose por los 2 núcleos asignados por el límite del contenedor, resultando en un rendimiento desastroso.
package main
import (
"fmt"
"runtime"
"sync"
"time"
)
// simulaTareaCPU realiza un trabajo intensivo de CPU para demostrar el uso de recursos.
func simulaTareaCPU(id int, wg *sync.WaitGroup) {
defer wg.Done()
fmt.Printf("[Worker %d] Iniciando tarea en un hilo de OS...\n", id)
// Un bucle pesado para asegurar uso de CPU
for i := 0; i < 1000000000; i++ {
_ = i * i
}
fmt.Printf("[Worker %d] Tarea completada.\n", id)
}
func main() {
// 1. Ver la diferencia entre hardware y configuración de Go
numCPUsHardware := runtime.NumCPU()
configuracionActual := runtime.GOMAXPROCS(0) // Passing 0 returns current setting
fmt.Printf("--- Información del Sistema ---\n")
fmt.Printf("Núcleos lógicos (hardware): %d\n", numCPUsHardware)
fmt.Printf("GOMAXPROCS actual: %d\n", configuracionActual)
fmt.Printf("-------------------------------\n\n")
// 2. Ejecución con la configuración actual
fmt.Println("Ejecutando carga de trabajo con la configuración actual...")
ejecutarCarga(configuracionActual)
// 3. Ajustando GOMAXPROCS dinámicamente
// Simulamos que estamos en un contenedor con recursos limitados a 2 núcleos
limitado := 2
fmt.Printf("\nReajustando GOMAXPROCS a %d (Simulando entorno limitado)...\n", limitado)
runtime.GOMAXPROCS(limitado)
ejecutarCarga(limitado)
}
func ejecutarCarga(n int) {
var wg sync.WaitGroup
inicio := time.Now()
// Lanzamos goroutines que intentarán usar los recursos disponibles
for i := 1; i <= n+2; i++ {
wg.Add(1)
go simulaTareaCPU(i, &wg)
}
wg.Wait()
fmt.Printf("Tiempo de ejecución: %v\n\n", time.Since(inicio))
}
Análisis del código
En la función main, primero utilizamos runtime.NumCPU() para obtener el número de núcleos lógicos reales de la máquina. Es fundamental la llamada runtime.GOMAXPROCS(0). En Go, pasarle un valor de 0 a esta función no cambia la configuración, sino que simplemente nos devuelve el valor actual que la runtime tiene configurado. Esto es útil para auditoría de logs antes de decidir si el entorno es el adecuado.
En ejecutarCarga, lanzamos un número de goroutines que excede ligeramente el valor de n (el número de procesadores lógicos). Cuando GOMAXPROCS es igual a n, cada goroutine puede encontrar un procesador P disponible para ejecutarse en paralelo casi de inmediato. Sin embargo, si incrementamos el número de hilos de trabajo por encima de GOMAXPROCS, las goroutines entrarán en una cola de espera, siendo gestionadas por el scheduler de Go hasta que un hilo se libere.
Finalmente, al ejecutar runtime.GOMAXPROCS(limitado), estamos forzando a la runtime a reducir sus recursos de procesamiento. Si en un sistema de 8 núcleos bajamos a 2, verás que aunque lancemos 10 goroutines, la ejecución total será más lenta o estará más contenida, porque solo 2 hilos de OS podrán estar “en caliente” procesando código real al mismo tiempo, independientemente de cuántas goroutines tengamos activas.
El error frecuente
El error más peligroso ocurre en despliegues en Kubernetes con resources.limits.cpu. Si tu límite es de 500m (medio núcleo) o 2 CPUs, pero el nodo físico tiene 32 CPUs, runtime.NumCPU() te devolverá 32.
// ERROR TÍPICO EN CONTENEDORES
func main() {
// Si el contenedor tiene un límite de 2 CPUs pero el host tiene 64:
// runtime.NumCPU() -> 64
// runtime.GOMAXPROCS(0) -> 64 (esto es un peligro)
// La aplicación intentará paralelizar en 64 hilos, pero el kernel
// solo le dará tiempo de CPU a 2. Esto causa un "throttling"
// agresivo y latencias enormes.
}
Para evitar esto, en entornos de contenedores es una práctica estándar utilizar la librería go.uber.org/automaxprocs. Esta librería lee correctamente los límites de los cgroups del contenedor y ajusta GOMAXPROCS automáticamente al valor correcto, asegurando que tu aplicación use solo el paralelismo para el que ha sido limitada.
N° 132