.jpg)
Cuando se administran múltiples aplicaciones Node.js en una sola instancia de Google Compute Engine e2-medium (2 vCPU, 4?GB de RAM), la planificación de la memoria se convierte en un factor crítico de estabilidad. Un error frecuente consiste en asignar límites de heap (--max-old-space-size) sin considerar el consumo real del sistema operativo, bases de datos u otros procesos concurrentes. En este artículo analizamos un caso real donde la suma de los topes de heap superaba la RAM disponible, explicamos por qué el servicio no falló de inmediato y detallamos una metodología para recalcular los límites de forma segura. Todo ello desde una perspectiva técnica y empresarial que puede aplicarse en entornos productivos.
El escenario parte de tres aplicaciones Next.js ejecutadas bajo PM2 en modo cluster: dos con dos instancias cada una y una con una instancia. Los topes de heap se habían configurado en 896?MB para las primeras y 512?MB para la tercera, sumando 4096?MB, mientras que la RAM real de la máquina era de 3924?MB. Además, en el mismo servidor convivían PostgreSQL (~400?MB), Gunicorn con cuatro workers (~600?MB), el sistema operativo (~400?MB) y ocasionalmente Playwright (~300?MB). El total de heap superaba la RAM en 172?MB, lo que constituía una bomba de tiempo latente.
La razón por la que el sistema no colapsó inmediatamente es que --max-old-space-size representa un techo, no una asignación fija. En condiciones normales, cada proceso consumía alrededor de 100?MB de heap, muy por debajo del límite. El peligro surge en momentos de pico: si varios procesos sufren fugas de memoria o reciben solicitudes grandes de renderizado simultáneas, cada uno intenta crecer hasta su tope (896?MB), superando la RAM física. Entonces el OOM killer de Linux termina procesos aleatoriamente, provocando caídas de servicio. Esta situación ejemplifica por qué “no falla ahora, luego está bien” es una de las decisiones más peligrosas en la administración de servidores.
Para evitar ese riesgo, es necesario separar el presupuesto de memoria dedicado a Node.js del resto de componentes. Restando el consumo estimado de PostgreSQL, Gunicorn, sistema operativo y Playwright, quedan aproximadamente 2200?MB disponibles para los procesos Node. Con esa capacidad, se redistribuyen los límites según el peso de cada aplicación: la app de blog y administración (la más pesada) recibe dos instancias de 512?MB cada una; la de chat, dos instancias de 384?MB; y la aplicación secreta, una instancia de 384?MB. El total suma 2176?MB, inferior a los 2200?MB disponibles, dejando un margen de seguridad.
Además, se configura max_memory_restart de PM2 ligeramente por encima del tope de heap, porque el RSS (Resident Set Size) incluye heap más memoria no heap. Con un heap de 512?MB, se reinicia el proceso al alcanzar 640?MB, antes de que el OOM killer intervenga. Otro detalle clave: cambiar --max-old-space-size no se consigue con pm2 reload; ese comando solo regenera workers sin aplicar nuevos argumentos al intérprete. Es necesario hacer pm2 delete y luego pm2 start para que los nuevos valores surtan efecto, y posteriormente pm2 save para persistirlos tras reinicios.
Estas prácticas son esenciales cuando se despliegan arquitecturas modernas con agentes IA, aplicaciones a medida o servicios inteligencia de negocio. En Q2BSTUDIO, al desarrollar software a medida, integramos estas consideraciones de capacidad y estabilidad desde la fase de diseño. Nuestro equipo aplica análisis de memoria en entornos de producción y sabe que la gestión de recursos es tan importante como el código mismo. Por ejemplo, cuando implementamos ia para empresas, evaluamos el consumo de cada microservicio para evitar cuellos de botella. Asimismo, en proyectos de ciberseguridad, una configuración incorrecta de memoria puede exponer vulnerabilidades de denegación de servicio.
La lección principal es clara: el total de límites de heap (instancias × techo) debe ser siempre inferior a la RAM física disponible, descontando otros procesos. No basta con mirar un solo proceso; hay que sumar todos los que comparten el servidor. El techo no es una asignación; es un riesgo potencial. Por eso, en Q2BSTUDIO recomendamos monitorizar el heap real con herramientas como PM2 y ajustar los límites de forma conservadora. Si tu empresa necesita desplegar aplicaciones Next.js, servicios cloud aws y azure o cualquier sistema crítico, podemos ayudarte a dimensionar infraestructuras robustas. Contáctanos para una consultoría gratuita.
