A donde se va la RAM de un VPS: el demonio de Docker pesa mas que cualquier contenedor
Medi los 36 contenedores de mi servidor esperando encontrar a Laravel comiendose la memoria. Las cinco plataformas juntas gastan 400 MB. El monitoreo gasta 351. Y dockerd, el solo, 404.
Mi servidor tiene 3.5 GB y siempre anda con la lengua de fuera. Antes de comprarle más memoria quise saber en qué se va, porque mi hipótesis —que eran las aplicaciones de Laravel— resultó estar equivocada por completo.
La medición
Primero el panorama:
$ free -m
total used free buff/cache available
Mem: 3613 2701 200 1119 911
Swap: 4095 2272 1823
Después, todos los contenedores ordenados por consumo:
docker stats --no-stream --format '{{.MemUsage}}\t{{.Name}}' | sort -h -r
Los 36 contenedores suman 1478 MB. Pero el total usado es 2701. Faltan 1200 MB que no están en ningún contenedor, y ahí estaba la sorpresa:
$ ps -eo rss,comm --sort=-rss | head -5
413240 dockerd
247910 minio
122778 netdata
100045 MainThread
92364 node
dockerd con 404 MB. El demonio de Docker, él solo, gasta más que cualquier contenedor que administra. Con 36 contenedores es hasta esperable —lleva registro de cada uno, sus redes y sus volúmenes— pero no es un número que nadie mencione cuando recomienda Docker en máquinas chicas.
Lo que de verdad pesa
Agrupando los contenedores por para qué sirven:
| Grupo | RAM |
|---|---|
| Almacenamiento S3 (MinIO) | 256 MB |
| Monitoreo (Netdata + Uptime Kuma) | 351 MB |
| Tres instancias de n8n | 372 MB |
| Las cinco plataformas Laravel completas | ~400 MB |
Léelo otra vez. Veinticinco contenedores de Laravel —aplicaciones, nginx, colas, programadores y cinco Postgres— gastan 400 MB. Las herramientas que existen para vigilar y automatizar esas aplicaciones gastan 979 MB, dos veces y media más.
La aplicación más nueva, completa, con su base y sus cuatro contenedores, pesa 45 MB. Un nginx de stack pesa 2 MB. Un Postgres en reposo, 13.
Mi intuición era que Laravel era pesado. Laravel en producción, con opcache y php-fpm en reposo, no gasta casi nada. Lo que gasta es todo lo que le pusimos alrededor.
El swap cuenta otra historia
for f in /proc/*/status; do
awk '/^Name:/{n=$2} /^VmSwap:/{if($2>0) print $2, n}' $f
done | sort -rn | head -5
262924 MainThread (n8n)
229816 java
164108 MainThread (n8n)
91196 dockerd
53672 minio
229 MB de un servicio en Java que en RAM solo muestra 41. El kernel ya lo mandó casi entero al disco porque nadie lo usa. Eso no es un problema: es el swap haciendo justo lo que debe. Un proceso dormido en disco es memoria libre para el que sí trabaja.
Lo que sí conviene mirar es que los tres n8n suman más de 500 MB entre RAM y swap. Y de los tres, solo uno atiende tráfico real: el número de WhatsApp de pruebas se rota entre bots, así que dos están encendidos sin poder recibir nada.
Qué haría con esto
Por rendimiento, ordenado:
- Apagar los dos n8n que no atienden nada. ~240 MB, reversible con
docker start. - Reconsiderar Netdata. Gasta 245 MB para darme métricas por segundo de una máquina donde lo que necesito saber es si algo se cayó. Uptime Kuma ya me dice eso por 106 MB.
- Reiniciar
dockerden la próxima ventana de mantenimiento. Vuelve a ~100 MB. El costo es que reinicia todos los contenedores, así que no es algo que se haga un martes cualquiera.
Las tres juntas devuelven cerca de 800 MB, sin tocar una sola aplicación.
La conclusión incómoda
El instinto, cuando un servidor va justo, es optimizar la aplicación. En este caso la aplicación era la parte barata. Lo caro era el andamio: el monitoreo, la automatización, el almacenamiento y el propio demonio de contenedores.
Ninguna de esas cuatro cosas sobra. Pero conviene saber lo que cuestan antes de decidir que el problema es tu código — y antes de pagar más memoria.
