Docker
CPU, memoria, PIDs, OOM y planificación de capacidad.
Los cgroups permiten contabilizar, priorizar y limitar recursos consumidos por procesos. Docker traduce opciones de runtime a controles del kernel.
container processes
→ cgroup
→ CPU, memory, PIDs, I/O
→ límites y métricasUn límite protege el host y otros workloads, pero no garantiza rendimiento. Un valor demasiado bajo puede crear OOM, throttling y latencia; uno demasiado alto permite interferencia.
Un container puede competir por la capacidad disponible del host.
Riesgos:
Containers no reciben automáticamente una “porción segura” solo por estar aislados.
docker run \
--memory 512m \
--cpus 1.5 \
--pids-limit 200 \
my-apiVerifica:
docker stats --no-stream
docker inspect container --format '{{json .HostConfig}}'docker run --memory 512m my-apiSi el cgroup supera el límite y no puede recuperar memoria, el kernel puede matar procesos.
Inspección:
docker inspect api --format '{{.State.OOMKilled}}'
docker inspect api --format '{{.State.ExitCode}}'Un exit 137 puede ser SIGKILL por OOM, stop timeout o acción manual. Correlaciona OOMKilled, events y logs.
No solo heap:
En Node.js, configurar heap igual al límite total deja cero margen para memoria nativa. Reserva espacio.
Opciones de swap dependen de host, cgroup version y configuración.
Trade-offs:
No asumas que swap está disponible o que un flag aceptado funciona igual en Docker Desktop, rootless y Linux nativo.
Algunas configuraciones permiten preferencias o soft limits bajo contención. No son garantía de memoria reservada.
En planificación, diferencia:
Docker Engine single-host no es un scheduler completo de reservas.
El kernel decide qué proceso terminar según cgroup y puntuación. Un container puede quedar running si mata un hijo, o salir si mata PID 1.
La app debe:
Aumentar memory sin corregir leak aplaza el incidente.
docker run --cpus 1.5 my-apiRepresenta una cuota equivalente de tiempo de CPU. No fija un core físico ni reserva capacidad constante.
Bajo contención, el proceso puede ser throttled. Síntomas:
Permiten prioridad relativa cuando varios cgroups compiten. Si sobra CPU, un proceso puede usar más; bajo presión, recibe una proporción.
No confundas peso relativo con hard limit.
Puede fijar CPUs específicas:
docker run --cpuset-cpus 0,1 my-appUsos especializados:
Costes:
docker run --pids-limit 200 my-apiLimita procesos y threads contabilizados según kernel.
Protege contra:
Un límite demasiado bajo rompe runtimes con muchos threads, browsers headless o process pools. Mide pico real.
Docker puede configurar pesos o límites para devices según plataforma.
Un container de database puede saturar disco aunque CPU/memory estén limitados.
Observa:
La efectividad de límites depende de storage driver, device, filesystem y cgroup version.
/dev/shm puede tener un tamaño predeterminado pequeño.
Workloads afectados:
docker run --shm-size 256m my-browser-testsAumenta con evidencia. Shared memory también contribuye al consumo.
Un tmpfs sin límite puede consumir memoria:
docker run --tmpfs /tmp:size=64m my-apiDiseña tamaño según archivos temporales y límite total.
La interfaz y semántica del kernel varían. Docker abstrae opciones comunes, pero métricas, controladores y rootless support pueden cambiar.
Revisa:
docker info
stat -fc %T /sys/fs/cgroupNo construyas scripts dependientes de paths internos sin soportar la versión objetivo.
CPU, memoria y disco pueden estar limitados primero por la VM de Desktop y luego por el container.
laptop 32 GB
→ Desktop VM 8 GB
→ container limit 4 GBLa app no puede usar los 32 GB. Diagnostica ambas fronteras.
No basta con asignar límites individualmente.
Ejemplo:
host 16 GB
10 containers × memory limit 4 GB
→ 40 GB de límites potencialesEs overcommit. Puede ser válido si picos no coinciden, pero requiere:
Reserva capacidad para:
Aunque Docker Engine usa límites, piensa en dos valores:
Relaciona con SLO:
Un límite correcto mantiene servicio y protege host bajo carga prevista.
Supón:
Prueba con carga real. Observa:
No uses solo un request sintético pequeño.
Los límites deben acompañarse de control de carga:
Sin backpressure, el container puede alcanzar memory limit repetidamente y reiniciar.
services:
api:
image: my-api
mem_limit: 512m
cpus: 1.5
pids_limit: 200Campos y semántica pueden variar entre Compose local y deploy de orquestadores. Verifica que el backend aplique realmente los límites:
docker inspect project-api-1No asumas que una sección ignorada protege el workload.
docker inspect api --format '{{json .State}}'
docker events --since 30m
docker stats --no-stream apiCorrelaciona container metrics con latency y cgroup stats. Un 100 % puede representar su cuota, no todo el host.
Errores como resource temporarily unavailable pueden aparecer. Revisa procesos/threads y límite.
Suma consumo de todos los workloads, builds, disk y logging.
En laboratorio, genera carga gradual y observa cuándo:
Mata una dependencia o reduce resources para validar:
No hagas stress destructivo en producción sin un plan.
Puede ser SIGKILL externo.
Native memory, buffers o children.
Cgroup/rootless/host configuration.
El host entra en presión antes de que cada container alcance su máximo.
CPU/memory limits no protegen storage.
Un workload domina el host.
Producen OOM o desperdicio.
Solo retrasa la falla.
Bajo contención no garantiza latency.
Un bug afecta todo el host.
La configuración puede no aplicarse al backend.
Logs y observabilidad, donde los containers reemplazables necesitan telemetría durable y correlacionada.