¿Contenedor bloqueado? Cómo auditar límites de CPU y memoria

¿Por qué tu contenedor parece lento o se bloquea de la nada?

Cuando una aplicación se ejecuta dentro de un contenedor Docker, comparte exactamente el mismo núcleo del sistema operacional de la computadora principal, conocido como host. A menudo, notamos que la aplicación tartamudea, tarda en responder o parece congelada, mientras que las herramientas comunes de monitoreo muestran suficiente capacidad libre. En la práctica, esto significa que la aplicación puede estar sufriendo un estrangulamiento invisible de recursos, donde el sistema restringe el ritmo de trabajo sin notificar directamente a la aplicación. Para comprender a fondo cómo prevenir estos problemas, vale la pena consultar nuestra guía sobre cómo limitar recursos con cgroups v2 para garantizar la estabilidad operativa.

Este comportamiento misterioso suele ocurrir porque Docker utiliza una tecnología interna de Linux llamada cgroups, abreviatura de grupos de control. El cgroup funciona como un portero riguroso que inspecciona el consumo exacto de procesador, memoria y disco de cada programa en ejecución. Si el contenedor intenta usar más de lo acordado en el contrato de configuración, el portero entra en acción. Dependiendo de cómo se haya configurado el entorno, simplemente puede ralentizar el programa o terminar abruptamente el proceso para proteger a todo el servidor contra caídas catastróficas.

¿Qué es el throttling de CPU y cómo estrangula tus aplicaciones?

El procesador de la computadora divide el tiempo en fracciones de milisegundos para atender cientos de tareas simultáneas. Cuando definimos un límite de procesamiento para un contenedor, el sistema operativo garantiza que no supere esa cuota dentro de un período específico. Si el contenedor gasta toda su porción de tiempo antes de que termine el período, el sistema lo coloca en pausa forzada hasta el próximo ciclo. Este mecanismo se conoce como throttling de CPU, es decir, el estrangulamiento de la capacidad de procesamiento por falta de cuota disponible.

En la rutina de ingeniería, es muy común confundir este estrangulamiento con la falta de capacidad bruta de hardware. El servidor físico puede tener núcleos ociosos, pero ese contenedor específico sigue atascado porque alcanzó el límite de su propia regla. Esto sucede frecuentemente con aplicaciones pesadas escritas en lenguajes que utilizan recolector de basura, como Java o Node.js, las cuales realizan picos repentinos de procesamiento y terminan penalizadas por las reglas restrictivas impuestas por el entorno aislado.

Cómo auditar el uso real de CPU directamente en el sistema de archivos del host

Para descubrir si tu contenedor está sufriendo pausas forzadas, no necesitamos instalar software complejo de monitoreo. El propio núcleo de Linux almacena todas estas estadísticas en archivos virtuales organizados dentro de la carpeta donde opera el cgroup. En el sistema moderno cgroup v2, por ejemplo, el archivo responsable de registrar las estadísticas de procesamiento se llama cpu.stat. Podemos inspeccionar este archivo directamente en la terminal del host para extraer números precisos sobre el comportamiento del contenedor.

Para realizar esta auditoría en la práctica, puedes seguir los pasos a continuación utilizando la terminal de tu servidor Linux con privilegios administrativos.

1. Identifica el identificador único completo del contenedor en ejecución ejecutando el comando tradicional de listado.

   docker ps --no-trunc

2. Accede al directorio correspondiente al contenedor dentro del árbol de control de recursos del sistema operativo.

   cd /sys/fs/cgroup/docker/<TU_ID_DE_CONTENEDOR>

3. Lee el archivo de estadísticas de procesamiento para verificar la cantidad de interrupciones sufridas.

   cat cpu.stat

Al examinar el contenido devuelto por este archivo, presta especial atención a dos líneas fundamentales que aparecen en el listado: nr_throttled y throttled_usec. La primera muestra cuántas veces el contenedor fue frenado por exceder la cuota, mientras que la segunda revela el tiempo total en microsegundos que la aplicación permaneció congelada esperando el próximo ciclo. Si estos números aumentan rápidamente mientras la aplicación se ejecuta, tienes la prueba matemática de que el límite configurado está estrangulando el servicio.

Comprendiendo los desbordamientos de memoria y su impacto oculto en el sistema

Mientras el procesamiento sufre pausas temporales, la gestión de memoria en los contenedores lidia con reglas mucho más estrictas y directas. Si un programa consume más memoria RAM de la permitida, no recibe una pausa para respirar; en la mayoría de los casos, el sistema operativo aplica un castigo severo y finaliza el proceso instantáneamente. Este evento se conoce como desbordamiento de límite, generando fallas inesperadas que a menudo se confunden con errores de código en la aplicación. Para complementar tu análisis de estabilidad y entender los efectos de estas ocurrencias, consulta también nuestro artículo sobre cómo auditar el OOM Killer con dmesg y descubre los registros dejados por el sistema.

Para auditar el consumo real de memoria sin depender de paneles externos, cgroup v2 proporciona el archivo memory.current, que muestra con precisión cuántos bytes está utilizando el contenedor en ese milisegundo. Comparar este valor con el límite máximo estipulado en el archivo memory.max permite predecir fallas antes de que ocurra lo peores escenarios. Si el valor actual está constantemente pegado al techo, la aplicación está a punto de sufrir una interrupción forzada, lo que requiere un redimensionamiento urgente de la infraestructura o una optimización en el código fuente. Para profundizar en estos conceptos arquitectónicos en producción, consulte también nuestro análisis técnico sobre Cómo inspeccionar tráfico mTLS en pods de Kubernetes con cURL.

Consideraciones finales para mantener contenedores estables y predecibles

Auditar el comportamiento de los contenedores directamente en el host de Linux a través de cgroups transforma la manera en que diagnosticamos problemas de rendimiento en entornos modernos. En lugar de adivinar la causa raíz basándonos en suposiciones, la lectura directa de las métricas del kernel ofrece datos concretos sobre el throttling de CPU y la presión de memoria. De este modo, logramos ajustar los límites de los contenedores con precisión quirúrgica, asegurando que los servicios funcionen con alto rendimiento, sin desperdicio de hardware y libres de bloqueos misteriosos en el día a día.