Este truco de Linux detiene los bloqueos de Next.js.

Ejecutas `next build` en un nuevo droplet de Ubuntu y todo parece funcionar bien durante unos 10 segundos. Luego, la carga media se dispara, la CPU alcanza el 100% y tu sesión SSH comienza a perder caracteres como en una mala llamada de Zoom. Un minuto después, el terminal se recupera con una sola palabra, frustrante: “Muerto.”

Sin traza de pila, sin un código de error ordenado, solo un build muerto. Vuelve a ejecutarlo y obtienes el mismo patrón: los ventiladores se encienden, la parte superior muestra Node y un enjambre de trabajadores consumiendo CPU, luego silencio. Si revisas las gráficas de tu proveedor después, ves un aumento brusco en CPU y memoria, seguido de un precipicio donde tu proceso desapareció.

Este modo de fallo afecta más a los asientos baratos de la nube. Esas instancias de 1 GB RAM de $5 a $7 al mes de DigitalOcean, Vultr, Linode o Lightsail son perfectas para una aplicación básica de Node—hasta que les pides que ejecuten una construcción moderna de Next.js. Durante ese tiempo de construcción, tu "pequeño pero poderoso" droplet de repente se comporta como una Raspberry Pi tratando de compilar Chrome.

Los desarrolladores suelen enfrentar esto con el reflejo más costoso en la computación en la nube: suponer que el hardware es el problema. La historia sigue el mismo camino cada vez. La construcción falla, el servidor se siente congelado, y la reacción instintiva es: “Esta caja simplemente no puede manejar Next.js. Necesito 2 GB, tal vez 4 GB.”

Los paneles de control en la nube incluso te empujan a ello. Ves la memoria al límite, la CPU al máximo, y un evento rojo de "fuera de memoria" en los registros. El botón de actualización está a un clic, prometiendo que un nivel de instancia más grande hará que el problema desaparezca. Para muchos equipos, ese clic se convierte en parte del manual de implementación.

La realidad es menos glamorosa y mucho más barata. Esos fallos generalmente no significan que tu aplicación necesite una máquina permanentemente más grande; significan que tu paso de compilación necesita brevemente más memoria de la que tu droplet tiene disponible. Y en una imagen de Ubuntu por defecto con swap desactivado, el núcleo solo tiene una forma confiable de lidiar con ese pico: matar tu compilación.

Next.js parece un único proceso de `node` en `htop`, pero `next build` se comporta más como un pequeño sistema distribuido metido en un solo binario. En el fondo, Next.js orquesta múltiples trabajadores de Node, una cadena de herramientas de TypeScript, un empaquetador y tuberías de activos, todos compitiendo por el mismo limitado 1 GB de RAM.

Comienza con Node en sí. El proceso principal lanza varios hilos de trabajo o procesos secundarios para paralelizar la compilación de páginas. Cada trabajador carga su propio fragmento del grafo de dependencias, montones de V8 y metadatos de construcción. En lugar de un solo proceso de 200 a 300 MB, temporalmente obtienes varios, y sus picos se apilan.

A continuación, la historia de TypeScript. Cuando ejecutas `next build` en un proyecto de TypeScript, la cadena de herramientas carga el compilador de TypeScript, analiza toda tu base de código y realiza la verificación de tipos. Eso significa múltiples AST grandes, tablas de símbolos y cachés viviendo en memoria al mismo tiempo, lo que a menudo provoca picos de cientos de megabytes en proyectos de tamaño mediano.

Además, Next.js invoca un empaquetador (Webpack o Turbopack) para generar tanto los paquetes del cliente como los del servidor. Cada destino necesita su propio grafo de dependencias, pasadas de optimización y mapas de origen. Las grandes bibliotecas de componentes, los marcos de UI y los sistemas de diseño agrandan estos grafos, por lo que un proyecto que funciona bien con 300–400 MB en producción puede alcanzar 800–900 MB o más durante una construcción.

Luego vienen las imágenes y los activos estáticos. Cuando habilitas next/image o procesas medios grandes, el pipeline de construcción decodifica, redimensiona y recomprime los archivos. Las operaciones con imágenes consumen mucha memoria: unas pocas imágenes hero en 4K o hojas de sprites pueden ocupar brevemente decenas o cientos de megabytes por trabajador antes de ser escritas de nuevo en el disco.

Todo esto ocurre en un breve lapso de unos pocos segundos a unos minutos. Imagina una cafetería de 20 asientos que de repente alberga a una multitud de 60 personas. El tráfico normal funciona bien, pero ese corto y caótico estallido bloquea las puertas, abruma al personal y deja a los clientes habituales atrapados afuera. `next build` crea exactamente ese tipo de sobrecarga temporal en un droplet de 1 GB.

En un servidor Ubuntu de 1 GB sin swap, esa multitud flash eleva el uso de memoria más allá del límite físico. El kernel comienza a recuperar de manera agresiva, las cachés desaparecen y, cuando aún no puede encontrar suficiente RAM, el OOM killer interviene y termina los procesos más pesados. Tu `next build` muere con una inscripción de una sola palabra: `Killed`.

El OOM killer suena dramático porque lo es. Cuando un sistema Linux se queda sin RAM física, el matador de memoria (OOM killer) del núcleo interviene como una válvula de seguridad de último recurso, escaneando cada proceso en ejecución y decidiendo cuál sacrificar para que toda la máquina no se bloquee. Sin él, un droplet de Ubuntu de 1 GB bajo presión de memoria simplemente se congelaría, cerrando sesiones SSH y dejándote con un terminal inactivo y un reinicio forzado.

Las compilaciones de Next.js son objetivos perfectos. Durante `next build`, Node genera múltiples procesos en segundo plano, carga compiladores como TypeScript, procesa paquetes y a veces maneja imágenes, aumentando fácilmente el uso de memoria cientos de megabytes por encima de la línea base en un corto pico. Para el núcleo, eso se parece a un proceso grande, reciente y no esencial que puede ser terminado con un impacto “sistemático” mínimo.

Linux utiliza una heurística llamada oom_score (y oom_score_adj) para clasificar a las víctimas. Los procesos grandes que recently han allocated mucha memoria, no se ejecutan como root y no pertenecen a servicios centrales del sistema, suben a la cima. Un build de Next.js en un droplet de 1 GB, ya al lado de nginx, sshd y tal vez una pequeña base de datos, a menudo se convierte en lo más pesado y desechable en la RAM.

Ningun intercambio cambia las apuestas por completo. Cuando la RAM alcanza el 100% y no hay ningún intercambio configurado, el núcleo solo tiene dos opciones: detenerse mientras intenta recuperar páginas desesperadamente, o invocar al OOM killer. Esa elección binaria explica por qué tu terminal se queda congelada un momento y luego muestra una sola palabra—“Asesinado”—sin traza de pila, sin error de Next.js, y sin ninguna pista útil de Node.

Esa línea de "Killed" no es npm siendo grosero; es la firma del núcleo. La verás en las ejecuciones fallidas de `pnpm install`, `npm install`, o `next build` cuando el OOM killer termina el proceso en pleno vuelo. Los registros del sistema (`dmesg` o `journalctl -k`) generalmente revelan la prueba contundente con entradas como “Sin memoria: Mata el proceso 1234 (node) puntuación 900 o sacrifica al niño.”

El swap le da al kernel otro movimiento. Con incluso un archivo de swap de 1 a 2 GB, el sistema puede enviar páginas frías—demonios inactivos, páginas de caché, bibliotecas poco utilizadas—al disco, liberando RAM para que la compilación pueda finalizar en lugar de ser eliminada. Para una guía paso a paso, recursos como Cómo crear un archivo de swap para desplegar una aplicación NextJS y Docker en un VPS de Ubuntu explican un proceso adecuado para producción.

El espacio de intercambio actúa como una válvula de presión para la memoria de tu pequeño servidor. En lugar de finalizar inmediatamente `next build` cuando la RAM alcanza el 100%, el kernel de Linux puede volcar datos excesivos en un trozo dedicado del disco y seguir adelante. Ese trozo es tu archivo de intercambio.

Piensa en el intercambio como "RAM de desbordamiento" que reside en el almacenamiento en lugar de en el silicio. Linux reserva un archivo o una partición en el disco y lo trata como una extensión de la memoria física, medida en las mismas páginas de 4 KB que utiliza la RAM regular.

Cuando tu droplet de 1 GB se queda sin RAM durante una construcción de Next.js, el núcleo comienza el proceso de evaluación. Las páginas que pertenecen a demonios inactivos, cachés antiguos o servicios en segundo plano se trasladan de la RAM al archivo de swap, liberando memoria real para las rutas de código caliente de la construcción.

El núcleo hace esto automáticamente a través de su administrador de memoria virtual. No necesitas reescribir tu aplicación ni modificar las banderas de Node; una vez que el intercambio existe y está activo, el sistema reacomoda silenciosamente las páginas menos utilizadas y reserva la memoria más rápida para la tarea que está realizando la mayor cantidad de trabajo.

El disco es más lento en comparación con la RAM: milisegundos en lugar de nanosegundos, por lo que utilizar swap siempre añade latencia. Sin embargo, para una construcción de corta duración, la estabilidad supera a la velocidad: un `next build` que termina en 90 segundos en un servidor que intercambia es mucho mejor que uno que muere después de 20 segundos con una única palabra: “Terminado”.

En un servidor con intercambio configurado, ese mismo pico brutal de memoria parece aburrido. La CPU sigue subiendo, los ventiladores siguen funcionando, pero tu sesión SSH se mantiene receptiva, `top` muestra el uso del intercambio aumentando, y la compilación avanza en lugar de hacer estallar la tabla de procesos.

En un servidor sin swap, el kernel no tiene salida. Una vez que la RAM se llena, o se detiene mientras busca páginas recuperables o invoca al OOM killer, terminando con Node, tu gestor de paquetes o cualquier otra cosa que parezca prescindible solo para seguir funcionando.

Ese contraste es marcado: con swap, las construcciones se sienten pesadas pero fiables; sin él, la misma carga de trabajo puede congelar tu shell, arruinar tu despliegue y obligarte a cuidar de un droplet reiniciado.

Comienza confirmando si tu caja de Ubuntu ya tiene swap. Ejecuta `sudo swapon --show`. Un resultado vacío significa que no hay dispositivos de swap activos. Luego, usa `free -h` para ver la RAM total y el swap actual, y después `df -h` para verificar el uso del disco. En un droplet típico de 25 GB, generalmente verás menos del 20% utilizado, lo que deja suficiente espacio para un archivo de swap de 2 GB.

Con el espacio en disco confirmado, asigna el archivo de intercambio. Para un servidor con 1 GB de RAM, un archivo de 2 GB ofrece espacio real para las compilaciones de Next.js sin sobrecargar el disco. Usa `sudo fallocate -l 2G /swapfile`. Esto reserva 2 GB al instante sin escribir ceros realmente. Verifícalo con `ls -lh /swapfile` y deberías ver `2.0G` en la columna de tamaño.

En este momento, `/swapfile` es solo un archivo normal al que cualquiera podría acceder. Restringelo para que solo root pueda leerlo o escribir en él. Ejecuta `sudo chmod 600 /swapfile`. Verifica los permisos nuevamente con `ls -lh /swapfile` y deberías ver `-rw-------` al comienzo de la línea, lo que confirma que el archivo es privado para root.

A continuación, convierte ese archivo simple en un verdadero espacio de intercambio. Usa `sudo mkswap /swapfile`. Ubuntu responderá con algo como `configurando espacio de intercambio versión 1, tamaño = 2 GiB`. Ese mensaje significa que el kernel ahora reconoce `/swapfile` como un área de intercambio válida, pero todavía está inactiva hasta que la actives explícitamente.

Activa el intercambio con un solo comando: `sudo swapon /swapfile`. Ejecuta `sudo swapon --show` nuevamente y ahora deberías ver una tabla que enumera `/swapfile`, su tamaño (aproximadamente `2G`), y su prioridad. `free -h` también mostrará `Swap: 2.0Gi` en el resumen, confirmando que el kernel ahora puede descargar páginas de memoria cuando se producen picos en las construcciones de Next.js.

En este momento, esta configuración sobrevive a los reinicios solo si la haces permanente. Edita `/etc/fstab` con `sudo nano /etc/fstab` y agrega una línea al final:

- `/swapfile none swap sw 0 0`

Guarda, sal y habrás terminado. En el próximo reinicio, Ubuntu habilitará automáticamente `/swapfile`, de modo que tus compilaciones de Next.js sigan funcionando incluso después de actualizaciones del kernel, reinicios o bloqueos inesperados.

El swap que acabas de crear solo sobrevive mientras dure el arranque actual. El comando `swapon /swapfile` activa un interruptor en tiempo de ejecución; tan pronto como el kernel se reinicie, ese estado desaparece y tus compilaciones de Next.js vuelven a morir con `Killed`.

Para mantener el intercambio en línea a través de reinicios, debes registrarlo en `/etc/fstab`, la tabla de sistemas de archivos que Linux lee al iniciar. Ese archivo le indica al núcleo qué discos, particiones y áreas de intercambio montar automáticamente.

Antes de tocarlo, haz una copia de seguridad. Un `/etc/fstab` roto puede impedir que el servidor arranque por completo, dejándote buscando una consola de recuperación en el panel de control de tu nube.

Correr:

- `sudo cp /etc/fstab /etc/fstab.bak`

Ahora abre el archivo con un editor que tenga capacidades de root, por ejemplo:

- `sudo nano /etc/fstab`

Desplázate hacia abajo y agrega esta línea exacta:

- `/swapfile none cambio sw 0 0`

Cada campo importa. `/swapfile` es la ruta a su archivo de intercambio. `none` representa un punto de montaje, porque el intercambio no se monta en el árbol de directorios.

`swap` declara el tipo de sistema de archivos, que le indica al núcleo que esta entrada es memoria virtual, no ext4 o xfs. `sw` es la opción de montaje establecida, abreviatura de "tratar esto como swap con el comportamiento predeterminado."

Los últimos dos ceros controlan el comportamiento de `dump` y `fsck`. `0 0` significa que el sistema no intentará realizar un volcado ni ejecutar comprobaciones de sistema de archivos en este archivo, que es exactamente lo que deseas para la memoria de intercambio.

Después de guardar, valida la sintaxis con:

- `sudo mount -a`

Sin salida generalmente significa éxito. Reinicie con `sudo reboot`, luego confirme la persistencia usando `free -h` o `swapon --show`. Para una afinación más profunda y antecedentes sobre el rendimiento de intercambio, consulte Potencie su sistema Linux con espacio de intercambio - Kite Metric.

Swap se comporta como una válvula de presión para la memoria, no como una mejora de rendimiento gratuita. Usado con cuidado, mantiene una pequeña gota de 1 GB activa el tiempo suficiente para que las compilaciones de Next.js terminen. Usado de manera imprudente, puede destruir una aplicación de producción.

Cuándo usar swap: picos de memoria cortos y agudos. Un `next build` que se ejecute durante 2–5 minutos, empujando brevemente el uso de 700–800 MB a 1.3–1.5 GB, es perfecto. El kernel puede expulsar páginas frías al disco, liberar unos pocos cientos de megabytes, y tu build finaliza en lugar de ser "Asesinado".

Las mismas reglas se aplican a otras tareas con ráfagas que se ejecutan rara vez y no sirven tráfico en vivo. Buenas candidatas incluyen: - `npm install`, `pnpm install` o `yarn install` - Migraciones de bases de datos o importaciones de datos puntuales - Scripts ocasionales de administración o mantenimiento - Pasos en el momento de la implementación en contenedores o agentes de CI

En estos casos, tu aplicación utiliza muy por debajo de la RAM física—digamos entre 300 y 500 MB en un servidor de 1 GB—y solo necesita un poco más de espacio durante las compilaciones o instalaciones. Intercambias un poco de velocidad por fiabilidad: una compilación puede ejecutarse entre un 20 y un 40% más lenta al utilizar swap, pero en realidad se completa. Para muchos equipos, permanecer en un droplet más pequeño compensa ese costo de inmediato.

Cuándo no usar intercambio: presión de memoria en estado estable de tu aplicación principal. Si tu servidor de Next.js y la base de datos juntos requieren 1.4 GB en una instancia de 1 GB todo el día, el núcleo traslada constantemente páginas de memoria entre la RAM y el disco. Ese intercambio excesivo destruye el rendimiento porque el disco, incluso el SSD, es mucho más lento que la RAM.

Puedes identificar el intercambio perjudicial con algunos síntomas concretos: - Alto I/O de disco (`iostat`, `iotop`) incluso con un bajo volumen de solicitudes - Respuestas HTTP lentas o tiempos de espera con solo un puñado de usuarios - `free -h` mostrando cientos de megabytes de swap utilizados y apenas disminuyendo en estado de reposo - Picos en la carga promedio mientras el uso de CPU se mantiene extrañamente modesto

Si aparecen esas banderas rojas, el swap se comporta como un curita en una herida de bala. La verdadera solución es más RAM o presupuestos de memoria más ajustados: reduce los trabajos de Node, disminuye los tamaños de caché, separa los servicios o mueve la base de datos fuera del servidor. El swap debería captar picos raros, no soportar tu aplicación las 24 horas, los 7 días de la semana.

Swap te ofrece un respiro, pero un saboteador silencioso más aún puede derribar tu construcción: Node.js en sí. Si Node decide que "necesita" 8 GB de memoria caché en un servidor de 1 GB, ninguna cantidad de trucos con swap te salvará del OOM killer. Es ahí donde una sola y oscura bandera lo cambia todo.

La bandera `--max-old-space-size` de Node controla cuánta memoria puede usar el motor V8 para su heap principal de JavaScript, medido en megabytes. Cuando este límite está demasiado alto, Node reserva agresivamente memoria que tu máquina simplemente no tiene, y el kernel responde terminando el proceso una vez que la RAM y el swap se agotan.

Los proyectos de Next.js a menudo ocultan esta trampa en `package.json`. Enterrado en la sección de `scripts`, podrías ver un comando de construcción como: - `"build": "NODE_OPTIONS='--max-old-space-size=8192' next build"`

En un droplet de 1 GB, ese objetivo de 8192 MB de heap es una fantasía. Node intentará llegar allí sin problemas, pero tus 1 GB de RAM y quizás 1–2 GB de swap se evaporarán, y tu construcción terminará con el mismo mensaje contundente de `Killed` con el que empezaste.

Primer paso: abre el `package.json` de tu proyecto e inspecciona cada script relacionado con build. Busca cualquier cosa que configure `NODE_OPTIONS` o que pase directamente `--max-old-space-size` a `node` o `next`, por ejemplo: - `"build": "NODE_OPTIONS='--max-old-space-size=4096' next build"` - `"build": "node --max-old-space-size=6144 node_modules/next/dist/bin/next build"`

Luego, alinea ese número con tu presupuesto real: RAM física + swap, menos el overhead del sistema operativo, la base de datos y los servicios en segundo plano. En un servidor de 1 GB con un archivo de swap de 2 GB (aproximadamente 3 GB en total), un límite de `--max-old-space-size=2048` suele tener sentido y deja espacio para todo lo demás.

Actualiza el script, reinstala o vuelve a desplegar, y ejecuta `next build` nuevamente. Con el intercambio habilitado y el límite de memoria de Node ajustado a algo realista, tus compilaciones dejan de pretender que se ejecutan en una estación de trabajo de 64 GB y comienzan a comportarse como si vivieran en un pequeño y económico droplet.

Swap silenciosamente soluciona más que las compilaciones problemáticas de Next.js. Cualquier carga de trabajo que ocasionalmente eleve el uso de memoria en un pequeño VPS o caja de desarrollo se beneficia de contar con algunos gigabytes adicionales de memoria virtual a los que recurrir en lugar de caer de cara en el OOM killer.

Los gestores de paquetes son reincidentes en este aspecto. Un solo `npm install`, `pnpm install` o `yarn install` en un monorepo moderno puede activar docenas de trabajadores de Node, descomprimir miles de tarballs y calcular árboles de dependencias en memoria. En un servidor de 1 GB, eso puede fácilmente llevar el uso de RAM a más del 90–100% durante varios minutos.

Los scripts de importación de datos y migración pesados se comportan de la misma manera. Los trabajos de ETL que cargan unos pocos cientos de megabytes de JSON o CSV en la memoria, las migraciones de Prisma o TypeORM que hidratan grandes esquemas, o los scripts administrativos ad-hoc que procesan en batch registros de usuarios, todos generan picos de memoria breves y brutales. Con el intercambio habilitado, esos picos se desaceleran en lugar de hacer estallar tu sesión SSH.

Las herramientas de base de datos también dependen de la RAM. Ejecutar `pg_restore` en un volcado de PostgreSQL de varios gigabytes, importar un instantáneo de MySQL o realizar la reindexación de Elasticsearch puede asignar brevemente cientos de megabytes de buffers y cachés. Un archivo de intercambio de 1 a 2 GB le da al kernel espacio para aparcar páginas inactivas mientras que los caminos de código activos permanecen en RAM real.

Los entornos en contenedores añaden otra capa de fragilidad. Un contenedor Docker que construye una aplicación Next.js, compila módulos nativos o ejecuta pruebas podría alcanzar su límite de memoria cgroup mucho antes que el host. El espacio de intercambio a nivel del host a menudo actúa como el último buffer que evita que el kernel finalice el contenedor durante la construcción.

El desarrollo local tampoco es inmune. Ejecutar `next dev`, Storybook, una base de datos y un navegador lleno de pestañas en un portátil de 8 GB puede consumir rápidamente la memoria. Combinar un pequeño archivo de intercambio con las prácticas de Cómo optimizar tu entorno de desarrollo local - Next.js mantiene tu máquina receptiva mientras todo se compila.

Los problemas de memoria en servidores pequeños rara vez necesitan una tarjeta de crédito más grande. Necesitan un diagnóstico. Antes de pasar de un droplet de 1 GB por $5/mes a una instancia de $20/mes, verifica si las compilaciones de Next.js están explotando debido a un uso de memoria corto y puntual o a una pérdida lenta y constante.

Un sencillo diagrama de flujo mental te mantiene honesto:

- ¿El fallo solo ocurre durante tareas cortas e infrecuentes (compilaciones de Next.js, `npm install`, migraciones)? → Agrega swap primero y luego vuelve a ejecutar la tarea. - ¿El servidor se siente lento durante el tráfico normal, con alto uso de swap y latencia elevada? → Perfila la memoria, optimiza las consultas y cachés, o amplía la RAM. - ¿El uso de swap se mantiene alto incluso cuando la aplicación está "inactiva"? → Estás enmascarando un problema real de capacidad, no lo estás resolviendo.

Para cargas de trabajo intermitentes, un archivo de intercambio de 1 a 2 GB en una máquina con 1 GB de RAM a menudo evita que el OOM killer destruya tu compilación. Intercambias unos segundos o minutos extra de tiempo de compilación por una compilación que realmente se completa. Eso es un buen trato cuando los despliegues ocurren unas pocas veces al día, y no miles de veces por segundo.

Las matemáticas de costos hacen que el argumento sea brutal y claro. Permanecer en una instancia de $5/mes en lugar de saltar a $15 ahorra $10 cada mes, o $120 por año, por servidor. Escala eso a través de 5 servicios pequeños y mantendrás $600/año en tu bolsillo por el precio de un `fallocate` único y una línea en `/etc/fstab`.

La escalabilidad inteligente significa apilar herramientas, no comprar cajas más grandes de forma reflexiva. Usa swap para manejar picos raros, ajusta las banderas de memoria de Node.js cuando las construcciones sigan comportándose mal, y solo entonces pasa a un nivel superior cuando tu uso en estado estable demuestre que realmente lo necesitas.

Terminas con una infraestructura que entiendes en lugar de una infraestructura que temes. Cuando una construcción termina con "Asesinado", sabes que debes revisar la memoria, el intercambio y los límites de Node.js antes de abrir la página de precios de tu proveedor de nube. Ese conocimiento convierte la escalabilidad de un movimiento de pánico en una elección deliberada y rentable.

¿Por qué las compilaciones de Next.js utilizan tanta memoria?

Las compilaciones de Next.js son intensivas en memoria porque generan múltiples procesos de trabajo para compilar TypeScript, empaquetar el código del cliente y del servidor, y procesar activos como imágenes simultáneamente. Este breve pero intenso estallido de actividad puede fácilmente abrumar a servidores con RAM limitada, como los droplets en la nube de 1GB.

¿Es malo para el rendimiento utilizar un archivo de intercambio (swap) en Linux?

El swap es significativamente más lento que la RAM, por lo que puede perjudicar el rendimiento si tu aplicación depende de él de manera constante para las operaciones diarias. Sin embargo, para picos de memoria breves e infrecuentes, como un proceso de compilación, la ligera desaceleración es un intercambio valioso por estabilidad, ya que permite que la compilación se complete con éxito en lugar de fallar.

¿Cuánto espacio de intercambio debería añadir para una compilación de Next.js?

Una buena regla general para un servidor pequeño (1-2 GB de RAM) es agregar espacio de intercambio igual o el doble de la cantidad de RAM física. Para un droplet de 1 GB, crear un archivo de intercambio de 1-2 GB suele ser suficiente para manejar los picos de memoria durante una construcción de Next.js.

¿Puedo usar intercambio en lugar de actualizar la RAM de mi servidor?

Puedes utilizar el intercambio para evitar la actualización si tus problemas de memoria son causados por picos temporales (como compilaciones o instalaciones de paquetes). Si el uso diario de memoria de tu aplicación supera consistentemente la RAM de tu servidor, deberías actualizar tu RAM, ya que depender del intercambio para el tráfico de producción llevará a un rendimiento deficiente.