Cuánta RAM necesita mi VPS: 1 GB, 2 GB, 4 GB, 8 GB o más

Respuesta rápida por tamaño

Son referencias iniciales, no garantías. Mide tu carga y conserva margen.

Qué consume la memoria

El kernel, los servicios base y SSH usan una parte. Nginx suele ser ligero; PHP-FPM multiplica memoria por proceso; MySQL y PostgreSQL reservan caché; Node.js tiene su heap; Docker añade poco por sí mismo, pero cada contenedor ejecuta aplicaciones reales.

Linux también utiliza RAM libre como caché de archivos. Por eso la columna free puede verse pequeña sin que exista un problema. Observa available:

free -h

VPS con 1 GB

Un gigabyte sirve para WireGuard, un proxy, una web estática o pruebas. Una instalación mínima sin panel puede funcionar bien. Al añadir base de datos, antivirus, panel y varios contenedores el margen desaparece rápidamente.

Configura una swap pequeña como red de seguridad y monitorea. No uses 1 GB para una tienda en producción solo porque el sistema arranca.

VPS con 2 GB

Dos gigabytes permiten una web pequeña, una API ligera o WordPress de bajo tráfico con configuración ajustada. Limita los workers de PHP, evita paneles pesados y no ejecutes demasiados servicios simultáneos.

Es un buen entorno de desarrollo y una entrada económica, pero conviene revisar el consumo durante actualizaciones, importaciones y backups.

VPS con 4 GB

Cuatro gigabytes son un punto de partida cómodo para muchos proyectos: WordPress con base de datos, una aplicación Laravel o Node.js, n8n pequeño o varios contenedores. Permiten caché y margen operativo sin sobredimensionar demasiado.

El tráfico no es el único factor. Un workflow de n8n que procesa un archivo grande puede consumir más RAM que cientos de visitas a páginas cacheadas.

VPS con 8 GB

Ocho gigabytes encajan en WooCommerce activo, múltiples aplicaciones, workers de colas o una base de datos con un conjunto de datos mayor. La memoria adicional permite mantener más datos en caché y reducir lecturas de disco.

No asignes toda la RAM a la base de datos. Reserva capacidad para el sistema, el servidor web, despliegues y picos.

Cuándo necesitas 16 GB o más

Varias tiendas, procesamiento de datos, compilaciones, buscadores, muchos workers o bases grandes pueden justificar 16, 32 o 64 GB. A partir de aquí conviene medir por servicio, establecer límites y considerar separar base de datos y aplicación.

Cálculo práctico

Suma el consumo base, la memoria máxima de cada proceso simultáneo, cachés y tareas periódicas. Después añade un margen de 20–30 % para picos razonables. Por ejemplo:

Sistema y agentes            500 MB
Nginx                        100 MB
6 procesos PHP de 120 MB     720 MB
Base de datos              1.200 MB
Redis                        150 MB
Margen y tareas            1.000 MB
Total aproximado           3.670 MB

Ese escenario pide 4 GB como mínimo y posiblemente más si los picos crecen.

Señales de falta de RAM

Busca swap constante, aplicaciones terminadas por el OOM killer, respuestas lentas durante picos y reinicios de contenedores:

free -h
vmstat 1
journalctl -k | grep -i -E 'out of memory|killed process'
ps aux --sort=-%mem | head

La guía qué hacer cuando un VPS se queda sin RAM explica el diagnóstico completo.

RAM, swap y almacenamiento

La swap proporciona tiempo para reaccionar y puede contener páginas poco utilizadas, pero acceder al disco es más lento. Configura swap como protección, no como excusa para mantener un servidor insuficiente.

En los planes VPS de Terranode puedes comparar configuraciones desde 1 GB hasta capacidades mayores. Elige según la aplicación, prueba con tráfico real y escala cuando las métricas lo indiquen.

No calcules la RAM por visitas mensuales

Dos sitios con cien mil visitas al mes pueden necesitar cantidades de memoria muy distintas. Un blog que entrega páginas completas desde caché apenas despierta PHP y la base de datos; una tienda con clientes autenticados, búsquedas, filtros y pagos ejecuta código en casi cada solicitud. La cifra mensual tampoco revela concurrencia: cien visitas repartidas durante una hora son más fáciles que cien personas entrando en el mismo minuto después de una campaña.

Para dimensionar, describe primero las operaciones que no pueden salir de caché. Incluye inicios de sesión, consultas al catálogo, generación de documentos, webhooks, tareas de cola, importaciones y paneles administrativos. Después estima cuántas pueden coincidir. Esa lista explica mejor la memoria necesaria que cualquier calculadora basada únicamente en páginas vistas.

También separa la carga permanente de los picos. MySQL, Nginx y los agentes de monitoreo viven siempre en memoria; una copia de seguridad, una compilación o una importación aparece durante unos minutos. El plan debe sostener ambas sin que una tarea auxiliar expulse al proceso principal. Si el pico es programable, puedes moverlo a una hora tranquila; si proviene de clientes, necesitas margen real.

Presupuesto de memoria para una aplicación web

Un presupuesto útil asigna memoria por función, no por nombre del producto. Empieza con el sistema y sus servicios básicos. Añade el máximo razonable del servidor de aplicaciones: número de workers multiplicado por el consumo de cada uno. Reserva luego el buffer de la base de datos, la caché, los procesos de cola y un margen para tareas temporales. No sumes los valores en reposo; captura cada componente mientras atiende una carga representativa.

En PHP-FPM, por ejemplo, diez procesos de 100 MB pueden ocupar cerca de 1 GB cuando todos trabajan, aunque después vuelvan a un estado más ligero. En Node.js un único proceso puede mantener un heap grande, y varios procesos de PM2 multiplican ese límite. PostgreSQL combina memoria compartida con memoria por operación; una consulta compleja puede utilizar más de lo que sugiere el proceso principal.

El resultado no tiene que ser exacto al megabyte. Su propósito es descubrir incompatibilidades: una base configurada con un buffer de 2 GB, ocho workers potenciales y un sistema de 500 MB no caben de forma segura en un VPS de 2 GB. Cuando el presupuesto supera el 70–80 % de la memoria disponible durante una carga normal, el margen para una actualización o un pico es demasiado pequeño.

Cómo medir el consumo real durante una semana

Una fotografía con free -h sirve para saber cómo está el servidor ahora, pero no muestra lo que ocurrió anoche. Registra memoria disponible, swap utilizada y carga cada pocos minutos durante al menos un ciclo completo de negocio. Debe incluir días laborales, tareas programadas y, si existe, el periodo de mayor venta o tráfico.

Puedes empezar con herramientas del sistema y revisar el historial que ya conserva systemd. Para una observación interactiva, combina procesos y memoria por servicio:

ps -eo pid,user,comm,rss,%mem --sort=-rss | head -20
systemd-cgtop
docker stats --no-stream

RSS aproxima la memoria residente de cada proceso, pero no conviene sumar esa columna sin criterio porque algunas páginas pueden ser compartidas. En contenedores, docker stats ayuda a localizar al consumidor, aunque una cifra baja en un instante no descarta un pico anterior. Los reinicios, el código de salida 137 y los mensajes del kernel completan la historia.

Anota qué estaba haciendo el sistema cuando subió el consumo. Un gráfico sin eventos solo dice que algo pasó. Relacionar el pico con “importación de catálogo”, “backup”, “envío masivo” o “despliegue” permite corregir la causa o reprogramarla.

Dimensionar PHP-FPM sin llenar la memoria

La directiva más importante de PHP-FPM es pm.max_children: define cuántas peticiones PHP pueden ejecutarse simultáneamente. Subirla indiscriminadamente no hace que el sitio atienda más; permite que más procesos compitan por la misma CPU y RAM. Si cada proceso alcanza 120 MB y autorizas veinte, PHP puede reclamar 2,4 GB antes de contar la base, el sistema o Redis.

Mide varios procesos bajo carga y usa un percentil alto, no el más pequeño. Después asigna a PHP solo la parte del presupuesto que le corresponde. Si dispones de 4 GB y reservas 1,5 GB para base de datos, 600 MB para sistema y 300 MB para caché y agentes, quedan aproximadamente 1,6 GB para PHP y picos. Con procesos de 120 MB, diez o doce workers son un punto inicial más prudente que treinta.

Si la cola de peticiones crece con CPU al máximo, hacen falta optimización o más CPU. Si hay CPU libre pero todos los workers están ocupados y queda RAM, puedes aumentar gradualmente. Si falta memoria, añadir workers empeora el incidente. El registro lento de PHP ayuda a encontrar las solicitudes que retienen un proceso demasiado tiempo.

Base de datos: reservar caché sin expulsar al resto

MySQL y PostgreSQL aprovechan la RAM para evitar lecturas repetidas del disco. Darles demasiado poco produce más entrada/salida; darles casi toda la máquina deja sin espacio a la aplicación. En un VPS donde todo convive, la configuración debe reconocer que la base no está sola.

No copies valores de un servidor dedicado de 64 GB. Revisa el tamaño de los datos activos y las consultas lentas antes de aumentar buffers. En MySQL, el buffer principal de InnoDB es global, pero otros espacios se asignan por conexión u operación. En PostgreSQL, parámetros como work_mem pueden utilizarse varias veces dentro de una consulta y por muchas conexiones a la vez. Multiplicar el valor por el máximo de conexiones ofrece una advertencia, aunque no todas lo consuman simultáneamente.

Un pool de conexiones evita que cada petición abra una sesión nueva y permite imponer concurrencia. Si la base crece hasta competir constantemente con la aplicación, separar ambos servicios puede ser mejor que duplicar RAM sin entender el patrón. Esa separación añade red y operación, por lo que debe responder a métricas, no a una receta universal.

Docker: el límite que no existe hasta que lo declaras

Un contenedor no trae una reserva mágica de memoria. Si no declaras límites, un proceso dentro de Docker puede utilizar la memoria disponible del host y provocar que el kernel termine otro servicio. Tampoco conviene repartir el 100 % entre contenedores: el sistema, Docker, el proxy y la caché de archivos necesitan espacio.

Revisa el consumo individual y los reinicios. En Compose puedes definir límites compatibles con tu modo de ejecución, pero primero debes conocer el pico legítimo de cada servicio. Un límite inferior a ese pico convierte la protección en una fuente de caídas. Un límite demasiado alto no protege al resto.

Para aplicaciones con workers, controla también la concurrencia desde la propia herramienta. Cuatro contenedores que ejecutan diez trabajos simultáneos cada uno representan cuarenta cargas, aunque el panel muestre solo cuatro servicios. Reducir concurrencia suele recuperar estabilidad con menos impacto que ampliar el servidor de emergencia.

Picos por backups, actualizaciones e importaciones

Las tareas de mantenimiento consumen memoria además de CPU y disco. Comprimir una copia, volcar una base grande, generar miniaturas o instalar dependencias puede coincidir con el horario de clientes. El servidor parece bien dimensionado durante el día y falla siempre a la misma hora de la madrugada: esa regularidad es una pista, no una casualidad.

Escalona tareas para que no empiecen juntas. Si el backup de archivos, el volcado de la base y la rotación de logs arrancan a medianoche, distribúyelos. Limita la concurrencia de importaciones y procesa archivos en fragmentos en lugar de cargarlos completos en memoria. En despliegues, conserva espacio para ejecutar temporalmente la versión nueva y la anterior si la estrategia hace un cambio gradual.

No elimines el backup para “resolver” el pico. Ajusta su método, horario o destino. Una máquina que solo permanece estable cuando deja de proteger sus datos está subdimensionada o mal programada.

Cuándo optimizar y cuándo subir de plan

Optimiza primero cuando un proceso crece sin relación con la carga, existe una consulta evidentemente ineficiente, hay workers o conexiones sin límite, o una tarea puede procesarse por lotes. Añadir RAM a una fuga solo demora el siguiente fallo. También corrige cachés duplicadas y servicios que ya no se utilizan.

Escala cuando el consumo corresponde a trabajo legítimo, la configuración ya impone límites razonables y la memoria disponible cae de forma repetida durante picos reales. Si el negocio creció, ampliar no es un fracaso técnico: es capacidad necesaria. El cambio debe dejar margen, no mover el servidor de 98 % a 92 %.

Después de ampliar, repite la misma medición. Comprueba que disminuyeron el intercambio, los cierres OOM y la latencia durante el evento que motivó el cambio. Si nada mejora, la RAM no era el cuello de botella y conviene revisar CPU, almacenamiento o dependencias externas.

Ejemplos de elección con contexto

Un blog corporativo cacheado, con pocas ediciones y base pequeña, puede trabajar cómodamente con 2 GB si no acumula plugins ni tareas pesadas. El mismo WordPress con un constructor visual, escáner de seguridad y copias locales puede necesitar 4 GB aunque reciba las mismas visitas.

Una API Node.js con una base externa puede empezar con 2 GB, pero cuatro procesos de PM2 y trabajos que transforman archivos cambian el cálculo. Una instancia pequeña de n8n suele agradecer 4 GB porque comparte la máquina con PostgreSQL y Docker; los flujos que manejan documentos o navegador pueden exigir 8 GB. Una tienda WooCommerce debe dimensionarse por compradores simultáneos y tareas de pedidos, no por catálogo.

En todos los casos, el plan inicial es una hipótesis. Documenta qué componentes incluye, qué carga se probó y qué señal activará el siguiente aumento. Así la conversación futura no empieza otra vez con “parece que falta RAM”.

Validación antes de dar el tamaño por correcto

Ejecuta el flujo más exigente que sea razonable: compra de prueba, importación, generación de informe o lote de automatizaciones. Mientras corre, observa memoria disponible, swap, latencia y errores. Luego deja que coincida con una tarea programada controlada si eso representa la operación real.

El tamaño es aceptable cuando el servicio completa el flujo, conserva memoria disponible, no registra OOM, no intercambia de forma sostenida y recupera su nivel normal después del pico. Repite la prueba tras cambios grandes de plugins, workers, base de datos o versión del runtime. La capacidad no es una propiedad permanente del VPS; depende del software que vive dentro.

Un método de revisión trimestral de capacidad

La memoria necesaria cambia aunque el plan siga igual. Crecen la base, el catálogo y los usuarios; aparecen plugins, integraciones y tareas; las nuevas versiones del runtime modifican su consumo. Una revisión trimestral evita que el primer aviso sea un cierre OOM durante una campaña.

Compara cuatro periodos: hora normal, hora pico, ventana de backup y despliegue. Para cada uno registra memoria disponible mínima, swap máxima, proceso principal, duración y errores. Añade el tamaño de la base y el número de workers o contenedores. Esa serie permite ver tendencia: pasar de 1,8 GB disponibles a 700 MB durante tres trimestres es más informativo que una alarma aislada.

Revisa además los cambios previstos. Si el siguiente trimestre incorpora importaciones, campañas o nuevos clientes, prueba antes con datos representativos. La capacidad debe llegar antes del tráfico. Mantén por escrito una acción para cada umbral: optimizar una consulta, limitar una cola, mover una tarea o ampliar el plan.

No trates el 100 % de uso como único límite. La degradación puede empezar antes por intercambio, recolección de basura o pérdida de caché. El objetivo de la revisión es conservar rendimiento y recuperación, no demostrar que el servidor puede vivir permanentemente al borde.

Separar servicios cuando ampliar deja de ser suficiente

En una primera etapa es razonable alojar proxy, aplicación y base en el mismo VPS: menos red, menos coste y una operación simple. La separación tiene sentido cuando un componente domina recursos, exige una política distinta o pone en riesgo a los demás. Una importación que expulsa constantemente la caché de la base, o varios proyectos donde uno provoca OOM al resto, son señales concretas.

Mover la base a otra máquina libera memoria, pero añade latencia, firewall, credenciales, backups y monitoreo. Mover workers permite escalar tareas sin multiplicar el servidor web, aunque obliga a operar una cola. No separes solo para dibujar una arquitectura más sofisticada; hazlo cuando el límite y el beneficio puedan medirse.

Antes del cambio captura la línea base y define una prueba. Coloca los servicios en una red privada, restringe puertos y prepara restauración. Después compara tiempos, memoria y comportamiento ante fallo. Si la complejidad creció y la métrica principal no mejoró, la separación no resolvió el cuello de botella.

Qué información enviar al soporte técnico

“Mi VPS usa toda la RAM” no permite distinguir caché normal, fuga o carga. Envía fecha y zona horaria, síntomas, cambio reciente, salida de free -h, procesos principales, eventos OOM y descripción del flujo que estaba corriendo. Oculta secretos, tokens e IP internas cuando no sean necesarios.

Indica si el problema desaparece al detener un servicio y cuánto tarda en volver. Para contenedores, incluye estado, reinicios y límites; para PHP, workers y memoria aproximada; para base, conexiones y consultas activas. Un gráfico de varias horas es mejor que una captura posterior al reinicio.

El soporte del proveedor puede revisar nodo e infraestructura; la evidencia de la aplicación sigue siendo esencial. Una descripción precisa reduce pruebas destructivas y ayuda a decidir si toca ajustar software, ampliar o investigar almacenamiento. Conserva la respuesta junto al inventario: el siguiente incidente debe empezar desde lo aprendido, no desde cero.

Como cierre de la revisión, anota también la versión y fecha de cada medición. Comparar datos obtenidos antes y después de una actualización evita atribuir a la RAM un cambio que vino del software.