Recursos del sistema y ajuste

QuoteNode se ejecuta como un pequeño conjunto de contenedores Docker. Los archivos Compose incluyen límites de memoria y CPU ajustados para una VM de 4 GB de RAM, y cada límite se puede sobrescribir con una variable de entorno, de modo que pueda dimensionar la pila según su máquina.

Mínimo y recomendado

Nivel	RAM del host	CPU del host	Notas
Mínimo	4 GB	2 núcleos	Perfil por defecto. Cómodo para un equipo pequeño (≈10 usuarios / ≈1 000 productos).
Recomendado	8 GB	4 núcleos	Margen para importaciones/exportaciones simultáneas y picos de PDF.
Con carga	8–16 GB	4–8 núcleos	≈100 usuarios / ≈20 000 productos con operaciones masivas en paralelo.

La pila es ligera en reposo: en reposo, toda la pila usa unos 1,5 GiB de RAM independientemente de cuántos datos haya en la base de datos (no hay caché de entidades en la JVM — los datos viven en PostgreSQL). La RAM escala con la concurrencia de operaciones masivas (importación/exportación/PDF), no con el número de usuarios o registros.

Cómo funcionan los límites de contenedores

mem_limit es un techo estricto, no una reserva. Un contenedor usa solo lo que realmente toca, hasta el límite; un contenedor que supera su límite es terminado por OOM. Un límite más alto no cuesta memoria — solo eleva el margen de seguridad.

El perfil por defecto suma unos 3 520 MiB de techos, lo que cabe en un host de 4 GB dejando ~575 MiB para el sistema operativo. Como el uso real en reposo es mucho menor (~1,5 GiB), los techos son margen para picos de carga, no el consumo esperado.

cpus también es un techo, pero la CPU es gratuita en reposo — un techo de CPU generoso no cuesta nada en reposo y deja que un servicio use núcleos cuando los necesita. Un valor cpus superior al número de núcleos del host simplemente significa «usar todos los núcleos disponibles», por lo que los valores por defecto son seguros en una VM de 1–2 núcleos.

Límites por defecto por servicio (perfil 4 GB)

Servicio	Memoria	CPU	Función
backend	1536m	4.0	Servidor API/web (el heap de la JVM se dimensiona automáticamente al 70 % de esto)
postgres	512m	4.0	Base de datos
backup-worker	832m	2.0	Copias de seguridad programadas (pg_dump)
gotenberg	448m	2.0	Renderizado de PDF con Chromium
frontend	96m	2.0	Caddy sirviendo el build estático
caddy	96m	2.0	Ingress TLS/proxy inverso — aumente CADDY_MEM_LIMIT con tráfico TLS intenso

Ajustar la RAM

Cada límite es una variable de entorno opcional. Defínala en su .env.prod para sobrescribir el valor por defecto:

# Ejemplo: una máquina de 8 GB con más carga simultánea
BACKEND_MEM_LIMIT=3g
POSTGRES_MEM_LIMIT=1g
GOTENBERG_MEM_LIMIT=768m

El heap de Java del backend se dimensiona automáticamente al 70 % de BACKEND_MEM_LIMIT (mediante MaxRAMPercentage), por lo que subir el límite sube el heap automáticamente — sin flags de JVM que editar. Lo mismo aplica proporcionalmente al backup-worker (que usa el 45 %).

Variables disponibles: BACKEND_MEM_LIMIT, BACKEND_CPUS, POSTGRES_MEM_LIMIT, POSTGRES_CPUS, WORKER_MEM_LIMIT, WORKER_CPUS, GOTENBERG_MEM_LIMIT, GOTENBERG_CPUS, FRONTEND_MEM_LIMIT, FRONTEND_CPUS, CADDY_MEM_LIMIT, CADDY_CPUS.

CPU

Deje los valores de CPU por defecto generosos. El único punto donde la CPU importa en la práctica es el arranque en frío: el backend y el worker basados en JVM arrancan un gran contexto de aplicación, lo cual está limitado por CPU. En un solo núcleo, un arranque en frío puede tardar minutos; con 2 o más núcleos está muy por debajo de un minuto. El período de gracia del healthcheck del worker ya tiene en cuenta los arranques lentos, así que una máquina limitada se recupera por sí sola, sin bucle de reinicios.

Evitar problemas de falta de memoria

• No reduzca WORKER_MEM_LIMIT por debajo de ~768m. Una copia de seguridad (pg_dump + tar + gzip + la JVM) alcanza un pico de unos 607 MiB; con menos margen puede terminarse a mitad de la copia.
• En una VM de 2 GB, el perfil por defecto es demasiado grande — baje los límites (p. ej. BACKEND_MEM_LIMIT=768m, POSTGRES_MEM_LIMIT=384m) para que la suma quede por debajo de la RAM física. El heap del backend sigue el límite automáticamente.
• Vigile el host, no solo los contenedores. Si el host ejecuta otras cargas, cuente también su memoria — Docker solo impone techos por contenedor, no el uso total del host.
• Un contenedor que se reinicia repetidamente con código de salida 137 indica un kill por OOM; aumente el *_MEM_LIMIT de ese servicio.