Cuánta memoria y cuántos núcleos necesita una web

Si la web aún no está en marcha y no sabes cuánto contratar, empieza con 2 GB de memoria y uno o dos núcleos. Es suficiente para un blog, la web de una empresa y una tienda pequeña en WordPress, y en la mayoría de los proveedores luego puedes ampliar el plan sin reinstalar. Si la web ya funciona, no hace falta adivinar: en cinco minutos puedes ver cuánta memoria ocupa y elegir un plan con un margen de alrededor del 30 %.

El error más habitual va siempre en la misma dirección: contratar cuatro núcleos y 1 GB de memoria, porque los núcleos suenan más serios. Para una web es una mala combinación. PHP y la base de datos se comen un gigabyte en minutos, el servidor empieza a pasar memoria al disco y las páginas tardan varios segundos en abrirse, aunque el procesador esté casi libre.

Qué te dan por ese dinero

Tomé unos 27 700 planes VPS de 2200 proveedores del catálogo de accsly a 27 de octubre de 2026, los ordené por precio mensual y en cada tramo busqué la mediana de memoria, núcleos y disco. Los importes están convertidos de rublos y redondeados.

La proporción habitual en el mercado es un núcleo por cada 2 GB de memoria. Los planes de 2 GB se reparten casi a partes iguales: la mitad trae un núcleo y la otra mitad, dos. Con 4 GB, el 61 % de los planes trae dos núcleos; con 8 GB, el 57 % trae cuatro.

La mediana de un servidor de 4 GB en todos los países ronda los 20 USD al mes (unos 18 EUR); en mercados con muchos planes baratos, como Rusia o Turquía, baja a unos 14–15 USD. Selecciones por memoria: VPS con 2 GB, VPS con 4 GB, VPS con 8 GB.

En qué se va la memoria de un servidor con una web

Una web en PHP con base de datos reparte la memoria entre cuatro consumidores. Si conoces lo que gasta cada uno, la cantidad necesaria se calcula en una servilleta.

• El propio sistema. Un Ubuntu o Debian recién instalado ocupa 150–300 MB después de arrancar.
• El servidor web nginx: decenas de megabytes, puedes no contarlo.
• PHP-FPM. Cada proceso de trabajo de PHP ocupa 40–100 MB, y con un WordPress con una decena de plugins, PrestaShop o Magento puede ser más. Hay tantos procesos como peticiones atiende la web a la vez.
• MySQL o MariaDB. El consumidor principal. La base de datos mantiene en memoria su búfer con datos e índices, más unos pocos megabytes por cada conexión.

Un panel de control como ispmanager, FastPanel o Plesk añade otros 200–500 MB, y Redis para caché, desde 50 MB hasta el tamaño de lo que guardes en él.

Supongamos que tienes una tienda en WooCommerce con 5000 productos y una base de datos de 800 MB. El sistema ocupará 300 MB; el búfer de la base para todos los datos con margen, 1 GB; la base en sí, otros 300 MB por encima; 15 procesos de PHP de 80 MB, 1,2 GB; Redis, 100 MB. En total, unos 3 GB. En un servidor de 4 GB queda un gigabyte que Linux usa como caché de archivos, y eso es bueno. Con 2 GB la tienda también arrancará, pero habrá que reducir a la mitad el búfer de la base y el número de procesos de PHP, y en las horas de rebajas las páginas del catálogo irán más lentas.

¿Y cuántos núcleos hacen falta?

Menos de los que parece. Un núcleo ejecuta en cada momento una petición de PHP. Si una página se genera en 200 ms, un núcleo sirve cinco páginas así por segundo, y dos núcleos, diez.

Pasémoslo a visitantes. Una web con 10 000 visitantes al día muestra unas 30 000 páginas. En la hora de más tráfico llega aproximadamente la décima parte, 3000 páginas, es decir, menos de una por segundo. Un núcleo se las arregla con eso. El segundo sirve para que el panel de administración, la importación de productos, las copias de seguridad y los robots de los buscadores no ralenticen la web para los visitantes. Y si tienes activada la caché de páginas, la mayoría de las peticiones ni siquiera llegan a PHP.

Los núcleos hacen falta cuando hay muchas páginas que no se pueden cachear: filtros del catálogo, búsqueda, carrito, área de cliente. También los consumen las tareas pesadas en segundo plano, como el procesamiento de imágenes, la exportación a marketplaces o la importación de listas de precios. Y varias webs en un mismo servidor.

Pagar núcleos por si acaso sale caro. Con 4 GB de memoria, un plan con cuatro núcleos cuesta en la mediana del mercado unos 27 USD, y uno con dos, unos 19 USD: 8 USD de diferencia al mes. Con 8 GB, la diferencia entre dos y cuatro núcleos es de solo unos 3 USD, así que con esa memoria los cuatro núcleos salen casi gratis. Para PHP también importa la frecuencia: una página se genera en un solo núcleo, y a 4,5 GHz estará lista bastante antes que a 2,2 GHz. Estos planes están en la selección VPS con procesador de alta frecuencia.

Qué contratar para las webs típicas

• Landing, web estática o tarjeta de visita sin base de datos: 1 GB y un núcleo. Son los planes más baratos, y aquí no hay nada por lo que pagar de más: VPS con 1 GB.
• Blog o web de empresa en WordPress con caché: 2 GB y uno o dos núcleos: VPS para WordPress.
• Tienda con miles de productos en WooCommerce, OpenCart o PrestaShop: 4 GB y dos núcleos: VPS para tienda online.
• Tienda con un catálogo grande, de decenas de miles de productos, o en Magento: desde 4 GB, y mejor 8 GB y cuatro núcleos.
• Aplicación en Laravel con colas y Redis: 2–4 GB, porque cada worker de la cola mantiene en memoria su propio proceso de PHP. Selección: VPS para Laravel.
• Varias webs y un panel de control: suma lo que necesita cada web y añade 0,5–1 GB para el panel.

Cuánta memoria gasta la web de verdad

Entra en el servidor por SSH y ejecuta:

free -m

La salida será más o menos así:

               total        used        free      shared  buff/cache   available
Mem:            3915        1720         240          60        1955        1890
Swap:           1023          12        1011

No te asustes por el número pequeño de la columna free. Linux usa la memoria libre como caché de archivos, que es la columna buff/cache, y se la devuelve a los programas en cuanto la piden. Lo que hay que mirar es available: aquí el servidor tiene 1,9 GB que los programas pueden tomar ahora mismo. Si en las horas punta available baja del 10 % de total, la memoria se queda corta.

La segunda comprobación es si el servidor usa el swap:

vmstat 1 10

El comando imprime diez veces, con un segundo de intervalo, una línea de cifras. Fíjate en las columnas si y so: cuántos datos lee el servidor del swap por segundo y cuántos escribe en él. Si son ceros, todo va bien, aunque en la línea Swap de free haya algo ocupado. Si ves constantemente cientos o miles, el servidor está pasando memoria al disco, y eso ralentiza la web más que cualquier otro problema.

La tercera: si el sistema ha matado procesos por falta de memoria. Cuando la memoria se agota del todo, el kernel de Linux elige el proceso más grande, a menudo MySQL, y lo termina. Para los visitantes se ve como el error «Error establishing a database connection» o un 502.

journalctl -k | grep -i -E 'out of memory|killed process'

Si el comando encuentra algo, la memoria se ha quedado corta al menos una vez. Contrata un plan mayor o reduce lo que consumen PHP y la base de datos, como se explica más abajo.

Quién se ha comido la memoria: htop y ps

Ejecuta htop (en Ubuntu y Debian se instala con apt install htop) y pulsa M para ordenar los procesos por memoria. La columna RES muestra cuánta memoria RAM ocupa cada proceso. Arriba suelen estar mysqld o mariadbd y una larga cola de procesos php-fpm.

Cuánta memoria se va en PHP en total y por proceso se calcula con una sola línea:

ps -eo rss,comm | awk '/php-fpm/ {s+=$1; n++} END {printf "%d procesos, %.0f MB en total, %.0f MB por proceso\n", n, s/1024, s/n/1024}'

El total sale algo inflado, porque los procesos de PHP comparten parte de la memoria. Para una estimación es suficiente. Lanza el comando de día, cuando la web tiene visitantes: por la noche los procesos están dormidos y parecen más pequeños.

El tamaño medio de un proceso te dice cuántos procesos de PHP puedes permitir. Decide cuánta memoria das a PHP y divídela entre el tamaño de un proceso. Por ejemplo, 1200 MB con 80 MB por proceso dan 15 procesos. Ese número va en el parámetro pm.max_children del archivo del pool; en Ubuntu y Debian es /etc/php/8.3/fpm/pool.d/www.conf, donde 8.3 es tu versión de PHP. Si pones más, ante una avalancha de visitantes PHP ocupará toda la memoria y el sistema empezará a matar procesos. Si pones menos, las peticiones que sobren esperarán en cola, pero el servidor seguirá vivo.

El búfer de MySQL: el mayor consumidor y la mayor palanca

La base de datos va rápida mientras sus datos e índices caben en el búfer en memoria. Cuánto pesan las tablas se averigua con esta consulta en la consola de mysql:

SELECT ROUND(SUM(data_length + index_length) / 1024 / 1024) AS mb
FROM information_schema.tables WHERE engine = 'InnoDB';

Tamaño actual del búfer:

SHOW VARIABLES LIKE 'innodb_buffer_pool_size';

Tras la instalación suele ser de 128 MB. Para una tienda con una base de datos de 800 MB es demasiado poco: cada filtro del catálogo leerá del disco. Si el búfer es suficiente te lo dicen dos contadores:

SHOW GLOBAL STATUS LIKE 'Innodb_buffer_pool_read%';

Divide Innodb_buffer_pool_reads entre Innodb_buffer_pool_read_requests. El primer número es cuántas veces la base de datos tuvo que ir al disco; el segundo, cuántas lecturas hubo en total. Si el cociente es menor que 0,01, es decir, menos del 1 % de las lecturas van al disco, el búfer basta. Mira estas cifras cuando el servidor lleve funcionando al menos un día.

Conviene que el búfer sea igual al tamaño de los datos más un 10–20 % para el crecimiento, pero en un servidor donde también funciona PHP, no más de la mitad de toda la memoria. El valor se fija con la línea innodb_buffer_pool_size = 1G en la sección [mysqld] de la configuración (en Ubuntu es /etc/mysql/mysql.conf.d/mysqld.cnf; en MariaDB, un archivo en /etc/mysql/mariadb.conf.d/), y después hay que reiniciar la base de datos. Si la base no cabe ni en la mitad de la memoria, es un motivo legítimo para contratar un plan mayor. En esa situación un disco rápido también ayuda; de eso trata el artículo NVMe o SSD para una web.

Cuándo añadir memoria y cuándo núcleos

Falta memoria si available baja del 10 % en el pico, si en vmstat no hay ceros en si y so o si en el registro hay procesos matados. Añadir núcleos aquí no sirve de nada.

Faltan núcleos si la memoria está libre y aun así la web va lenta bajo carga. Compruébalo con uptime: los tres números al final de la línea muestran la carga media de 1, 5 y 15 minutos. Compáralos con el número de núcleos que da nproc. Si en las horas punta la carga supera durante mucho rato el número de núcleos y en htop el procesador está ocupado por procesos php-fpm, necesitas más núcleos o una caché de páginas, que a menudo sale más barata.

Hay dos casos en los que un plan nuevo en el mismo proveedor no ayuda. Si en top, en la línea %Cpu(s), el valor st es alto, al menos un 10 %, los vecinos del servidor físico te están quitando procesador. Solo ayuda otro proveedor o un plan con núcleos dedicados. Si el valor alto es wa, el procesador está esperando al disco, y lo que hay que resolver es el disco, no los núcleos.

Si dudas entre dos tamaños, elige el menor en un proveedor donde puedas ampliar el plan desde el panel en un par de minutos. Antes de comprar, mira en la descripción si se puede cambiar de plan sin reinstalar. Y si quieres probar la web en varias configuraciones, viene bien el pago por horas: un servidor para una tarde cuesta menos de un dólar. El resto de parámetros del plan se explica en el artículo cómo elegir un VPS.