Antes de Go 1.3, el tiempo de ejecución utilizaba pilas segmentadas que se dividían en fragmentos vinculados en los límites de las llamadas a funciones. Este diseño causaba graves bajones de rendimiento por "divisiones calientes" cuando se cruzaba el límite de la pila con frecuencia durante bucles ajustados. Go 1.3 reemplazó esto con pilas contiguas que se copian a regiones contiguas más grandes y únicas durante el crecimiento. Sin embargo, las primeras implementaciones de pilas contiguas nunca liberaron memoria de nuevo al montón, causando un crecimiento permanente de RSS para goroutines que requerían temporalmente pilas de llamadas profundas durante la inicialización o el procesamiento por lotes. Go 1.5 introdujo la reducción automática de pilas para reclamar la memoria de pila no utilizada durante los ciclos de recolección de basura, completando el ciclo de gestión de memoria para las pilas de goroutines.
Sin un mecanismo de reducción, una goroutine que entra temporalmente en una recursión profunda (por ejemplo, al procesar un documento JSON profundamente anidado o recorrer un árbol complejo de dependencias) retendría su asignación máxima de pila indefinidamente incluso después de regresar a un bucle de eventos inactivo. Esto lleva a la acumulación de memoria en aplicaciones de larga duración, particularmente aquellas que utilizan grupos de trabajadores donde las goroutines alternan entre tareas de alta pila y estados inactivos. El desafío radica en identificar de forma segura cuándo una pila está realmente infrautilizada y reubicar las tramas activas en una región de memoria más pequeña sin corromper los cálculos en progreso, punteros asignados a la pila o violar los requisitos de ABI para las convenciones de llamada.
El tiempo de ejecución de Go reduce las pilas durante la fase de marcado del GC al escanear los conjuntos de raíces. Examina el uso de la pila de cada goroutine; si la marca de alta del porción utilizada cae por debajo de una cuarta parte (25%) del tamaño de pila actualmente asignado, el tiempo de ejecución asigna una nueva pila que tiene la mitad del tamaño de la actual (pero nunca más pequeña que el mínimo de 2KB). Luego, el tiempo de ejecución detiene de manera asincrónica la goroutine objetivo en un punto seguro, copia los tramas de pila activas a la nueva región más pequeña, utiliza mapas de punteros generados por el compilador para actualizar todos los punteros interiores que hacen referencia a direcciones de pila, y libera la memoria de la antigua pila de nuevo al asignador mheap del tiempo de ejecución.
Operamos un servicio de procesamiento de logs de alto rendimiento donde cada goroutine manejaba el análisis de cargas útiles JSON potencialmente profundamente anidadas (hasta 10,000 niveles de profundidad durante ataques de entradas mal formadas). Después de procesar, estas goroutines regresaban a un sync.Pool para esperar nuevas conexiones. Observamos que la memoria RSS del servicio crecía linealmente con el número de goroutines en el grupo, nunca liberando memoria incluso durante períodos de inactividad, lo que eventualmente provocó muertes por OOM en contenedores con límites de 4GB a pesar de que el conjunto de trabajo real era solo de 200MB.
Consideramos eliminar por la fuerza a las goroutines en el grupo después de un número determinado de solicitudes procesadas y engendrar reemplazos frescos. Esto garantizaba la liberación de la memoria de pila ya que las nuevas goroutines comienzan con pilas mínimas de 2KB. Sin embargo, este enfoque introdujo una sobrecarga significativa de CPU debido a la constante creación y destrucción de goroutines, interrumpió las optimizaciones de agrupamiento de conexiones TCP y causó latencias más altas debido a los inicios en frío del caché.
Implementar un límite duro en el crecimiento de la pila a través de debug.SetMaxStack evitaría la asignación excesiva durante los eventos de recursión profunda. Si bien esto protegía contra OOM, provocaba que tareas de análisis legítimas pero profundas paniqueen con runtime: goroutine stack exceeds 1000000000-byte limit. Esto resultó en la pérdida de datos de clientes y errores del servicio que violaron nuestros SLAs de confiabilidad, lo que lo hacía inaceptable para producción.
Evaluamos llamar periódicamente a runtime.GC() seguido de debug.FreeOSMemory() cada 30 segundos para forzar el escaneo de pilas y la reducción. Esto redujo exitosamente el RSS pero introdujo pausas de stop-the-world de 5-10ms en cada invocación, lo que violó nuestros requisitos de latencia p99 de <2ms para el nivel de API y aumentó la utilización de CPU en un 15% debido a las colecciones completas forzadas.
Finalmente, nos basamos en el mecanismo de reducción de pilas nativo de Go asegurando que ejecutáramos Go 1.20+ y ajustamos GOGC para desencadenar recolecciones de basura más frecuentes (configurándolo a 50 en lugar de 100). Esto aumentó la frecuencia de oportunidades de reducción de pilas sin intervención manual. También reestructuramos el analizador para usar un enfoque iterativo con una pila asignada en el montón explícitamente para el seguimiento de caminos, reduciendo la profundidad máxima de recursión de 10,000 a 100. La combinación permitió que la reducción natural ocurriera con suficiente frecuencia para mantener la memoria acotada.
La RSS del servicio se estabilizó en aproximadamente 800MB bajo carga, down de el anterior límite de 3.8GB. Los perfiles de pila de goroutine mostraron que el 95% de los trabajadores en el grupo mantuvieron el tamaño mínimo de pila de 2KB entre solicitudes, con picos que solo ocurrían durante el análisis activo. Las muertes por OOM cesaron por completo, y la latencia p99 se mantuvo por debajo de 1.5ms ya que evitamos pausas manuales de GC y la rotación de goroutines.
¿Se produce la reducción de pila inmediatamente cuando una función retorna y el puntero de pila disminuye?
No, el tiempo de ejecución no monitorea los decrementos del puntero de pila en tiempo real para activar la desasignación inmediata. La reducción se lleva a cabo exclusivamente durante la fase de marcado de recolección de basura cuando el planificador escanea todas las pilas de goroutines. El tiempo de ejecución verifica la marca de alta del uso de la pila desde la última GC. Si esta marca de alta está por debajo del 25% de la asignación física actual, solo entonces se ejecuta la lógica de reducción. Esta evaluación perezosa amortigua el costo de copiar pilas a través de todas las goroutines durante un período en el que el mundo ya está en pausa para el marcado, aunque la copia real requiere detener la goroutine individual.
¿Cuál es la proporción exacta de reducción y el tamaño mínimo, y el tiempo de ejecución alguna vez libera memoria de nuevo al sistema operativo?
Cuando una pila califica para su reducción, el tiempo de ejecución asigna una nueva pila con la mitad del tamaño de la actual. Esta reducción geométrica evita el thrashing donde una goroutine oscilando ligeramente por encima y por debajo de un umbral crecería y encogería constantemente. El nuevo tamaño está limitado por debajo por el tamaño mínimo de pila de la plataforma, que típicamente es de 2KB en sistemas de 64 bits. La memoria de la antigua pila se devuelve al mheap del tiempo de ejecución, no directamente al sistema operativo. El sistema operativo solo reclama esta memoria física si el recolector determina que el montón ha estado inactivo y excede el objetivo, o si se invoca debug.FreeOSMemory().
¿Se detiene la goroutine durante la reducción de pila y cómo se actualizan los punteros?
Sí, la reducción requiere detener la goroutine objetivo en un punto seguro, similar al crecimiento de la pila. El tiempo de ejecución debe copiar las tramas activas a una nueva ubicación de memoria y actualizar todos los punteros que hacen referencia a variables asignadas en la pila. El compilador genera mapas de punteros que identifican qué palabras en cada trama son punteros. Durante la reducción, el tiempo de ejecución utiliza estos mapas para encontrar y ajustar los punteros interiores para apuntar a las nuevas direcciones de pila. Esta operación no es concurrente; la goroutine no puede ejecutarse durante la copia, pero otras goroutines continúan ejecutándose.