Optimización de Contenedores Docker: Solución de Cuellos de Botella de Rendimiento

Cuando un contenedor Docker es lento, rara vez el contenedor es la explicación completa. El problema suele estar una capa más abajo: limitación de CPU, presión de memoria, escrituras lentas en disco, retrasos de DNS, vecinos ruidosos en el host o una aplicación que ya era ineficiente antes de ser contenerizada.

La forma más rápida de perder tiempo es empezar a cambiar banderas de Docker antes de saber qué recurso está limitado. Comienza con evidencia, aísla un cuello de botella, cambia una cosa y mide de nuevo.

Comienza con Triage, No con Ajustes

docker stats te da una vista rápida en vivo:

docker stats
docker stats --no-stream

Úsalo para responder preguntas básicas:

• ¿La CPU es alta y sostenida?
• ¿La memoria está cerca del límite configurado?
• ¿La E/S de bloque aumenta durante solicitudes lentas?
• ¿El recuento de procesos es inesperadamente alto?
• ¿La E/S de red está alineada con la carga de trabajo?

Luego verifica el estado del contenedor y los registros:

docker logs --tail 100 <nombre_o_id_del_contenedor>
docker inspect <nombre_o_id_del_contenedor> --format 'OOM={{.State.OOMKilled}} Exit={{.State.ExitCode}} Restarting={{.State.Restarting}}'

También revisa el host. Un contenedor puede parecer inocente mientras el host está haciendo swapping o el disco está saturado:

top
free -m
vmstat 1
iostat -xz 1

iostat puede requerir el paquete sysstat. Si estás en Docker Desktop, recuerda que hay una máquina virtual entre tu sistema operativo host y los contenedores Linux, lo que cambia el comportamiento de archivos y red.

Cuellos de Botella de CPU

Una CPU alta puede significar que la aplicación está ocupada, mal aprovisionada o limitada. Esos son problemas diferentes.

Verifica la configuración de CPU:

docker inspect <contenedor> --format '{{json .HostConfig.NanoCpus}} {{json .HostConfig.CpuQuota}} {{json .HostConfig.CpuPeriod}}'

Si el contenedor está demasiado limitado, las solicitudes pueden acumularse incluso si el host aún tiene CPU inactiva. Prueba un aumento controlado:

docker run -d --name api --cpus="2" my-api:latest

Si la CPU sigue alta después de aumentar el límite, perfila la aplicación. Por ejemplo, un servicio Node podría estar atascado en serialización JSON, un trabajador Python podría estar limitado por CPU bajo el GIL y un servicio Java podría estar gastando tiempo en recolección de basura. Docker no puede solucionar eso por sí solo.

Presión de Memoria y Muertes por OOM

Los problemas de memoria a menudo se manifiestan como reinicios, picos de latencia o la desaparición del proceso bajo carga.

Verifica si Docker detectó una muerte por OOM:

docker inspect <contenedor> --format '{{.State.OOMKilled}}'

Si la memoria sube lentamente y nunca baja, busca una fuga o un caché sin límites. Si la memoria aumenta durante solicitudes específicas, reproduce ese camino bajo carga. Si un runtime de lenguaje tiene su propio límite de heap, alinéalo con el contenedor. Una JVM que no entiende el presupuesto real del contenedor puede comportarse mal; las JVM modernas son conscientes del contenedor, pero la configuración del heap aún merece revisión.

Los límites de memoria deben dejar margen. Un contenedor que usa 950 MB de un límite de 1 GB durante tráfico normal no es saludable. La recolección de basura, los búferes temporales, TLS, la compresión y los picos de solicitudes necesitan espacio.

Resolución de Problemas de Rendimiento de Entrada/Salida (E/S)

El acceso lento al disco afecta a bases de datos, colas, motores de búsqueda, calentamiento de caché y registro detallado. Primero averigua si las escrituras van a la capa de escritura del contenedor, un volumen nombrado o un montaje bind.

docker inspect <contenedor> --format '{{json .Mounts}}'
docker info --format 'StorageDriver={{.Driver}}'

En instalaciones modernas de Docker en Linux, overlay2 es el controlador de almacenamiento predeterminado común. Generalmente es una buena opción, pero escribir datos mutables pesados en la capa del contenedor sigue siendo un mal patrón.

Usa volúmenes nombrados para datos persistentes de la aplicación:

docker volume create app-data
docker run -d --name app -v app-data:/var/lib/app my-image

Usa montajes bind cuando necesites una ruta específica del host, pero pruébalos. Los montajes bind de Docker Desktop en macOS y Windows pueden ser mucho más lentos que el acceso nativo al sistema de archivos de Linux porque las operaciones de archivos cruzan un límite de virtualización.

Para archivos temporales de alta velocidad, /dev/shm puede ayudar, pero está respaldado por memoria y es limitado:

docker run --shm-size=512m my-image

Esto es común para navegadores, ejecutores de pruebas y aplicaciones que necesitan memoria compartida. No es un reemplazo para el almacenamiento real.

Optimización del Tamaño de la Imagen y el Rendimiento de la Compilación

El tamaño de la imagen afecta principalmente el tiempo de compilación, extracción, escaneo e implementación. Generalmente no hace que el manejo de solicitudes sea más rápido una vez que el contenedor está en ejecución, pero sigue siendo importante operativamente.

Usa compilaciones de múltiples etapas para que los compiladores, cachés de paquetes y herramientas de prueba no terminen en la imagen de runtime:

FROM golang:1.22-alpine AS builder
WORKDIR /app
COPY go.mod go.sum ./
RUN go mod download
COPY . .
RUN CGO_ENABLED=0 GOOS=linux go build -o app

FROM alpine:3.20
COPY --from=builder /app/app /app
CMD ["/app"]

Ordena las instrucciones del Dockerfile para reutilización de caché:

FROM node:18-alpine
WORKDIR /app
COPY package*.json ./
RUN npm ci
COPY . .
RUN npm run build

Cambiar el código fuente no debería forzar la descarga de dependencias a menos que los archivos de dependencias hayan cambiado.

Consideraciones de Rendimiento de Red

Las ralentizaciones de red a menudo parecen ralentizaciones de la aplicación. Prueba desde dentro del contenedor:

docker exec -it <contenedor> sh
time getent hosts api.example.com
time wget -qO- https://api.example.com/health

Si la resolución DNS es lenta o inestable, inspecciona /etc/resolv.conf en el contenedor y compáralo con el host. Puedes proporcionar servidores DNS en tiempo de ejecución:

docker run -d --name web --dns 1.1.1.1 my-image

Haz esto como diagnóstico o elección de política, no como una solución aleatoria. En redes corporativas, puede ser necesario el DNS interno.

La red puente predeterminada de Docker agrega NAT y procesamiento de iptables. Para la mayoría de las aplicaciones web, la sobrecarga es aceptable. La red de host puede reducir la sobrecarga en Linux:

docker run --network host my-image

También elimina el aislamiento del espacio de nombres de red y cambia el manejo de puertos. Úsala cuando hayas medido una necesidad real.

Lista de Verificación de Campo

Cuando un contenedor es lento, trabaja a través de esta lista:

1. Reproduce la ralentización con una solicitud, trabajo o carga de trabajo específica.
2. Captura docker stats --no-stream, registros y salida de inspección del contenedor.
3. Verifica CPU, memoria, swap, E/S de disco y red del host.
4. Identifica el recurso limitado antes de cambiar los límites.
5. Mueve escrituras persistentes o pesadas a volúmenes.
6. Compara el comportamiento del montaje bind en Linux versus Docker Desktop si el desarrollo local es el único lugar lento.
7. Perfila la aplicación cuando las métricas del contenedor no explican la ralentización.
8. Cambia una configuración y mide de nuevo.

La mentalidad útil es simple: Docker te da aislamiento y empaquetado, pero no elimina el trabajo normal de sistemas. CPU, memoria, disco y red aún deciden qué tan rápido se siente el servicio.