¿Cuánta RAM necesita un VPS? La regla, uso por uso

La regla: sumar lo que permanece en memoria

Un servidor no consume memoria «en general»: cada programa en ejecución reserva una parte mientras funciona. El cálculo parte, por tanto, de la lista de procesos presentes de forma permanente, y después añade el pico y un margen:

Memoria que prever = (sistema + servicios permanentes + pico de las tareas puntuales) × 1,25

• El sistema: una distribución Linux mínima (Debian, Ubuntu) ocupa del orden de 150 a 300 MB una vez arrancada, con el acceso SSH y los registros incluidos.
• Los servicios permanentes: servidor web, procesos de la aplicación, base de datos, caché, cola de tareas. Su consumo depende de la tecnología, como detalla la sección siguiente.
• El pico: lo que se suma en ciertos momentos, como la compilación de una aplicación, una copia de seguridad, una importación o una tarea programada pesada. Un servidor dimensionado según su media cae precisamente en esos momentos.
• El margen: un 25 % por encima del total, para el crecimiento de los datos y del tráfico. Y trabaja desde el primer día: Linux usa la memoria libre como caché de archivos, lo que acelera la base de datos.

Lo que consume cada componente

Los órdenes de magnitud siguientes valen para una aplicación de tamaño habitual, medida en producción. Son un punto de partida; la medición sobre su propia aplicación, descrita más abajo, tiene siempre la última palabra.

Hay un pico que se repite a menudo con las aplicaciones JavaScript: la compilación. npm run build en un proyecto Next.js, Nuxt o Angular pide habitualmente de 1 a 2 GB por sí solo, durante unos minutos, además de lo que ya está en marcha. Compilar en el servidor obliga a dimensionar para ese pico; compilar en su equipo o en su integración continua y subir solo el resultado lo evita.

El mismo razonamiento vale para los contenedores Docker: cada contenedor es un conjunto de procesos como los demás, y el demonio de Docker añade su propio consumo. docker stats muestra lo que ocupa cada uno.

Perfiles tipo

Estos perfiles suman los componentes anteriores, pico y margen incluidos. Suponen una aplicación de tamaño habitual y el tráfico de un lanzamiento; una base de datos voluminosa o un tráfico sostenido desplazan la cifra hacia arriba.

Una aplicación que llama a un modelo de IA por API (OpenAI, Anthropic, Mistral) se dimensiona como cualquier aplicación web: el modelo se ejecuta en la infraestructura de su proveedor, y su servidor espera la respuesta. Es la ejecución del modelo en el propio servidor lo que cambia la escala.

Medir en un servidor en funcionamiento

En un servidor en servicio, la medición sustituye a la estimación. Tres comandos le dicen en qué punto está:

free -h
ps aux --sort=-rss | head -n 15
vmstat 5 5

• free -h: lea la columna available, la memoria realmente disponible para lanzar nuevos programas. La columna free casi siempre está baja, y es normal: Linux llena la memoria no utilizada con la caché de archivos (buff/cache), que libera en cuanto un programa la necesita.
• ps aux --sort=-rss: los procesos ordenados por la memoria que ocupan (columna RSS, en kilobytes). Aquí se ve lo que pesa cada worker de PHP o de Node.js.
• vmstat 5 5: cinco lecturas a cinco segundos de intervalo. Valores distintos de cero en las columnas si y so, lectura tras lectura, indican un servidor que recurre al swap: le falta memoria.

Mida en el momento de más carga del día y durante las tareas puntuales: compilación, copia de seguridad, importación. Lo que cuenta es el pico.

Cuando falta memoria

Un servidor sin memoria no se ralentiza de forma progresiva. Cuando ya no queda nada que liberar, el kernel de Linux activa el OOM killer (out of memory): elige un proceso, en general el que más memoria ocupa, y lo detiene en seco. En un servidor de aplicaciones, suele ser la base de datos.

Los síntomas: errores 502 o 503 intermitentes, un servicio que se reinicia sin motivo aparente, una compilación que se interrumpe con Killed. Los registros del sistema lo confirman:

journalctl -k | grep -i "out of memory"
systemctl status nombre-del-servicio

En la salida de systemctl status, la mención Failed with result 'oom-kill' señala un servicio detenido por falta de memoria.

El swap, cuando el servidor dispone de él, retrasa ese momento trasladando a disco la memoria menos utilizada. Sirve de red de seguridad, no de capacidad: un servidor que se apoya en el swap de forma continua responde varias veces más lento, incluso sobre un SSD NVMe.

Los remedios, del más sencillo al más duradero: reducir el número de procesos de la aplicación (pm.max_children, workers de Gunicorn), compilar fuera del servidor, limitar la memoria de la base de datos y, después, pasar a un tamaño superior.

Elegir el tamaño y prever lo que viene

1. Enumere lo que se ejecutará: servidor web, aplicación y número de procesos, base de datos, caché, tareas programadas.
2. Sume con la tabla de componentes, añada el pico más pesado (a menudo la compilación) y, después, un 25 % de margen.
3. Quédese con el tamaño que cubre ese total. Entre dos tamaños contiguos, el más pequeño es suficiente siempre que el paso al tamaño superior se haga sin reinstalar.
4. Mida tras la puesta en línea, en el pico del día, y después en cada etapa de crecimiento de la aplicación.

La memoria no es el único recurso: el procesador cuenta para todo lo que calcula (compilación, tratamiento de imágenes, ejecución de un modelo de IA), y el disco para la base de datos y los archivos. Aun así, en una aplicación web es casi siempre la memoria la que fija el tamaño.