VPS para WordPress: cuánta RAM y CPU necesitas

Punto de partida

Estas referencias suponen Linux, Nginx/Apache, PHP-FPM y base de datos en el mismo VPS. Mide antes de escalar.

Qué consume recursos

Cada worker PHP usa memoria y CPU. MySQL/MariaDB mantiene buffers; Redis guarda caché; backups, cron e importaciones crean picos. Una página cacheada casi no ejecuta PHP, mientras checkout o búsqueda sí.

Configuración recomendada

Usa una versión vigente de PHP, OPcache, caché de página, Redis cuando aporte, CDN para estáticos y HTTPS. Limita workers según RAM; demasiados no aumentan capacidad si la CPU ya está saturada.

Cómo medir

Observa CPU, memoria available, OOM, consultas lentas, tiempo PHP y hit ratio de caché. Prueba con concurrencia realista y revisa Core Web Vitals de usuarios, no solo una prueba vacía.

La guía WordPress en VPS con Nginx y MariaDB cubre instalación. Para una tienda consulta VPS para WooCommerce. Los VPS NVMe de Terranode permiten empezar con un tamaño y ampliar cuando las métricas lo pidan.

Visitas mensuales no equivalen a carga

Un millón de páginas servidas desde caché puede exigir menos que unas pocas sesiones simultáneas en un sitio dinámico. Para dimensionar WordPress, observa cuántas peticiones llegan a PHP al mismo tiempo, qué hacen los plugins y cuánto tarda cada una. El promedio mensual es útil para negocio, no para asignar workers.

Separa visitantes anónimos, usuarios autenticados, búsquedas, formularios y administración. La caché de página puede resolver el primer grupo; los demás ejecutan PHP y base. Un pico por campaña concentra trabajo aunque el total del mes no cambie.

Construye el plan con la hora más exigente y una reserva. Si solo mides una portada vacía, dimensionas el escenario más fácil.

El presupuesto de memoria del stack

La RAM se reparte entre Linux, Nginx o Apache, PHP-FPM, MariaDB, caché, agentes y tareas. Cada worker PHP puede crecer según tema y plugins. Multiplica un consumo alto observado por los procesos simultáneos, no por una cifra copiada.

Reserva memoria para la base y el sistema. Dar todo a PHP provoca que MySQL lea del disco o que el kernel active OOM. En 4 GB, el reparto exacto depende del sitio, pero debe dejar margen para cron, backup y actualización.

Mide durante carga:

free -h
ps -C php-fpm -o pid,rss,etime,cmd --sort=-rss
mysqladmin status

Adapta el nombre de proceso a tu versión. Registra los picos y revisa eventos OOM antes de ampliar.

CPU y workers de PHP-FPM

pm.max_children limita solicitudes PHP concurrentes. Un valor enorme no crea capacidad: si la CPU ya está ocupada, más workers compiten y aumentan latencia. Un valor muy bajo deja cola aunque haya recursos libres.

Calcula primero por memoria y luego valida CPU. Activa el slow log para encontrar rutas que retienen procesos. Constructores, búsquedas, exportaciones y plugins de seguridad pueden convertir una petición en segundos de trabajo.

Si los workers están llenos, CPU alta y memoria disponible, optimiza código o añade CPU. Si queda CPU y RAM, un aumento pequeño puede ayudar. Cambia una variable por vez y prueba de nuevo.

Caché de página: la mejora con mayor impacto

Una página cacheada evita ejecutar WordPress para cada visita. Puede servirse desde Nginx, un plugin o una capa externa. El beneficio depende de una tasa real de aciertos y de excluir contenido personalizado.

Configura purga al publicar y verifica como visitante. No caches panel, login, vistas previas ni respuestas con sesión. Una caché incorrecta puede mostrar contenido privado; una caché que nunca acierta solo añade complejidad.

Con buen caché, un VPS pequeño soporta mejor tráfico público. Las operaciones dinámicas siguen necesitando PHP y base, por lo que no dimensionas únicamente con la portada.

OPcache y caché de objetos

OPcache guarda bytecode PHP compilado y evita repetir ese trabajo. Debe tener espacio suficiente para código y mostrar pocos reinicios por falta de memoria. No almacena páginas ni consultas; cumple otra función.

Redis puede conservar objetos y resultados usados por WordPress, reduciendo consultas. Aporta más en sitios dinámicos, pero consume RAM y requiere un plugin compatible. Comprueba tasa de aciertos y evita exponer el puerto.

No instales tres capas con el mismo propósito. Documenta qué cachea cada una, cómo se purga y qué ocurre al desactivarla. La simplicidad ayuda durante incidentes.

MariaDB y consultas lentas

La base se beneficia de RAM para su conjunto activo. Ajusta el buffer de InnoDB sin ocupar toda la máquina y limita conexiones. Activa temporalmente el registro lento para identificar consultas que realmente cuestan.

Revisa tablas options con autoload excesivo, transients, revisiones y tablas abandonadas por plugins. No borres por nombre sin backup y staging. Un índice correcto puede ahorrar más que cambiar de plan.

El disco NVMe reduce espera cuando hay entrada/salida, pero no corrige una consulta que examina filas innecesarias. Mide antes y después con el mismo flujo.

Plugins y temas como parte de la capacidad

Cada plugin puede añadir hooks, consultas, cron, peticiones externas y assets. El número no basta: uno pesado cuesta más que diez simples. Usa perfiles y logs para descubrir quién consume tiempo y memoria.

Elimina extensiones inactivas y reemplaza funciones duplicadas. Prueba cambios en staging; quitar un plugin de caché o seguridad sin plan puede afectar disponibilidad. Mantén temas y plugins actualizados desde fuentes legítimas.

Cuando una nueva función entra en producción, repite la prueba. El tamaño que era correcto antes de añadir membresía, multidioma o búsqueda avanzada puede dejar de serlo.

WP-Cron y trabajos en segundo plano

WP-Cron se dispara con visitas y puede ejecutarse en momentos impredecibles. En sitios activos, programa cron del sistema y deshabilita el disparo por petición cuando la configuración esté verificada. Evita que varios trabajos pesados comiencen juntos.

Observa publicaciones, correos, backups, importaciones y limpieza. Una tarea atascada puede repetirse y consumir workers. Registra duración y resultado, no solo que existe una entrada.

Distribuye horarios y procesa lotes. Mantén backups, pero no los comprimas durante el pico si compiten con clientes.

CDN y ubicación del servidor

Una CDN descarga imágenes, CSS y JavaScript, reduce transferencia y acerca contenido. No acelera directamente PHP ni consultas dinámicas. Optimiza tamaños y cabeceras para que los objetos sean cacheables.

La región del VPS afecta latencia al origen. Coloca aplicación y base juntas; separarlas por países añade viajes a cada consulta. Para público distribuido, combina una región razonable con CDN y mide TTFB desde mercados reales.

No atribuyas a CPU un problema de red ni compres RAM para una imagen de varios megabytes. Las métricas deben separar capas.

WordPress multisitio y varios sitios

Varios WordPress comparten RAM, CPU y disco aunque cada uno tenga poco tráfico. Sus tareas pueden coincidir y un sitio comprometido afecta la capacidad del host. Suma picos, no promedios individuales.

Aísla usuarios, pools o contenedores cuando corresponda y define límites. Un único PHP-FPM para todo simplifica, pero dificulta saber quién consume. La separación también facilita mantenimiento y responsabilidad.

Si una instalación domina recursos o requiere otra versión, moverla a otro VPS puede ser más claro que seguir ampliando una máquina común.

Cómo ejecutar una prueba representativa

Clona en staging, anonimiza datos y calienta cachés. Prueba portada, artículo, búsqueda, formulario, login y operación administrativa. Aumenta concurrencia gradualmente; no ataques producción sin autorización.

Observa tiempo total, errores, CPU, memoria, workers, consultas y tasa de caché. Compara percentiles, porque el promedio oculta usuarios lentos. Incluye un periodo con cron.

El objetivo es conocer el punto donde la latencia crece, no presumir una cifra de visitas. Conserva el guion para repetir tras cambios.

Elegir entre 2, 4 y 8 GB

Dos gigabytes encajan en un sitio pequeño, cacheado y con pocos servicios. Cuatro permiten más plugins, base y picos, y son un punto equilibrado para muchos sitios. Ocho sirven para varios WordPress, tráfico dinámico o tareas más pesadas.

Estas cifras son hipótesis. Si un plugin filtra memoria, 8 GB solo demora la caída. Si todo sale de caché, 2 GB pueden sobrar. El plan correcto sostiene la carga, actualizaciones y backups conservando margen.

Antes de escalar, elimina cuellos evidentes. Escala cuando el trabajo legítimo utiliza recursos de forma repetida.

Backups y restauración

Respalda base, wp-content, configuración y secretos. El núcleo y plugins pueden reinstalarse, pero los uploads y contenido no. Guarda copia fuera del VPS y define frecuencia según cambios.

Restaura en otra instancia. Verifica URL, usuarios, medios, formularios y cron. Una copia presente no garantiza que importe ni que incluya la última venta.

Antes de actualizar plugins o PHP, toma un respaldo y prepara reversión. No dejes todas las copias en el mismo disco que puede fallar.

Señales de que toca escalar

Escala RAM cuando available cae, hay intercambio sostenido u OOM bajo carga legítima. Escala CPU cuando los núcleos permanecen ocupados y las colas crecen. Amplía disco antes de que logs, uploads y backups consuman el margen.

Si el tiempo está en consultas, arregla índices; si está en APIs, revisa esas dependencias. Después del cambio repite la prueba y comprueba que mejoró la métrica objetivo.

Registra el umbral siguiente. La capacidad es un proceso, no una compra única.

Calcular pm.max_children con memoria medida

PHP-FPM atiende solicitudes dinámicas mediante workers. pm.max_children fija cuántas pueden ejecutarse al mismo tiempo; un valor demasiado bajo crea cola y uno demasiado alto permite que PHP agote la RAM. La cifra debe salir del consumo por worker en tu sitio, no de una plantilla para “WordPress en 4 GB”.

Genera tráfico sobre páginas dinámicas y consulta el RSS de los procesos:

ps --no-headers -o rss,cmd -C php-fpm8.3
ps --no-headers -o rss,cmd -C php-fpm8.3 | awk '{sum+=$1; n++} END {if(n) print "Promedio MB:",sum/n/1024}'
free -h

Sustituye el nombre del proceso por el de tu versión. El promedio orienta, pero conserva también el worker más grande: una importación o página del administrador puede usar mucho más que una entrada cacheada. Reserva primero memoria para sistema, Nginx, MariaDB, Redis y OPcache. Divide solo el resto entre el consumo alto razonable de un worker y deja margen para tareas de mantenimiento.

Por ejemplo, si después de reservar otros servicios quedan 1.200 MB y un worker dinámico llega a 120 MB, el límite teórico sería diez. No configures diez automáticamente: backups, cron y variación también consumen. Empieza por debajo, activa el status de FPM únicamente en una ubicación local o protegida y observa cola, procesos activos e inactivos durante el pico.

El modo de gestión importa. dynamic conserva un conjunto de workers preparados y responde bien a tráfico continuo; ondemand crea procesos cuando llegan solicitudes y puede ahorrar memoria en sitios con largos periodos sin uso, a cambio de latencia al arrancarlos. Cambiar el modo no reduce el costo de cada solicitud: si un plugin usa 300 MB, seguirá usándolos.

Proteger CPU frente a bots, búsquedas y XML-RPC

Un sitio pequeño puede saturarse sin ganar visitantes humanos. Bots recorren combinaciones de filtros, buscan rutas inexistentes, golpean el login o llaman XML-RPC. Cada fallo que llega a PHP consume un worker; miles de respuestas cacheadas por Nginx cuestan mucho menos que miles de arranques completos de WordPress.

Revisa primero los logs por IP, ruta, estado y agente. No bloquees una dirección por una sola solicitud: identifica frecuencia y patrón, y comprueba que no pertenece a un monitor, buscador legítimo o integración. Limita en el proxy las rutas sensibles según el producto, usa una CDN o WAF cuando la audiencia es pública y aplica rate limiting a login y búsquedas costosas.

XML-RPC no debe deshabilitarse a ciegas. Algunas aplicaciones móviles, Jetpack o integraciones pueden necesitarlo. Si no existe dependencia, bloquéalo antes de PHP; si se usa, restringe métodos o frecuencia conforme a la integración. Lo mismo ocurre con REST API: WordPress y el editor dependen de ella, por lo que cerrarla globalmente para “mejorar seguridad” rompe funciones legítimas.

Las páginas de búsqueda y archivos con muchas combinaciones merecen límites propios. Un parámetro que evita la caché puede obligar a ejecutar consultas distintas indefinidamente. Canonicaliza URLs, rechaza parámetros desconocidos cuando sea seguro y no permitas que una caché almacene millones de variantes inútiles. El objetivo es preservar CPU para solicitudes válidas, no ocultar una consulta lenta bajo bloqueos indiscriminados.

Picos de memoria al editar, actualizar y procesar imágenes

El consumo del visitante no representa el del administrador. Subir una imagen grande obliga a decodificarla y crear varios tamaños; importar contenido construye estructuras amplias; actualizar plugins descomprime archivos y puede ejecutar migraciones. Un VPS estable frente a lectores puede quedarse sin memoria cuando alguien edita una galería.

El límite de memoria de PHP controla cuánto puede usar una solicitud, no cuánto usan todos los workers. Subirlo de forma global permite que más procesos crezcan simultáneamente. Si una tarea administrativa legítima requiere más, confirma primero dimensiones, formato, plugin implicado y memoria real. Reduce imágenes antes de subir, limita tamaños aceptados y evita generar variantes que el tema nunca utiliza.

Programa actualizaciones y regeneración de miniaturas fuera del pico. Ejecuta tareas largas con WP-CLI dentro de tmux o como un trabajo supervisado, y observa memoria y disco. No lances varias regeneraciones en paralelo para terminarlas antes: bibliotecas de imagen y lectura del almacenamiento pueden competir hasta degradar todo el sitio.

Durante una actualización, el disco también necesita margen para el paquete descargado, la copia temporal y los archivos reemplazados. Comprueba inodos además de gigabytes. Un fallo a mitad por falta de espacio puede dejar modo de mantenimiento o un plugin incompleto aunque RAM y CPU parezcan normales.

Caché de objetos: comprobar aciertos y evitar datos obsoletos

Redis o Memcached conserva resultados de consultas y objetos entre solicitudes. Ayuda cuando el mismo dato se consulta repetidamente, pero no reemplaza la caché de página: una página pública servida sin ejecutar PHP ahorra mucho más trabajo. Instalar Redis en un sitio casi estático con pocas consultas puede añadir otro servicio que mantener sin una mejora visible.

Mide tasa de aciertos, memoria, claves expulsadas y latencia. Una caché llena con expulsiones continuas puede funcionar, pero si se pierden objetos caros justo antes de cada solicitud el beneficio cae. Separa prefijos cuando varias instalaciones comparten Redis y configura credenciales y red; el puerto no debe estar expuesto a Internet.

Los datos cacheados deben poder descartarse. Plugins que guardan en la caché información que actúa como fuente primaria crean recuperaciones frágiles. Después de vaciarla en staging, el sitio debe reconstruir contenido desde la base sin perder pedidos, usuarios ni configuración. Prueba también actualización y rollback: objetos serializados por una versión pueden ser incompatibles con otra hasta que se purgue el grupo correcto.

No programes un vaciado completo frecuente “por si acaso”. Cada purga provoca estampida: muchas solicitudes intentan regenerar simultáneamente los mismos objetos y páginas. Usa invalidación ligada a cambios, precalentamiento gradual para rutas importantes y protección de concurrencia cuando el plugin la ofrezca.

Separar tráfico público, administración y tareas de fondo

Aunque todo corra en el mismo VPS, puedes medir y limitar tres cargas. El tráfico público necesita baja latencia; /wp-admin necesita capacidad para edición; cron, backups e importaciones pueden esperar o ejecutarse en ventanas. Si comparten un único pool sin observación, una exportación de madrugada puede consumir todos los workers y hacer parecer que la web cayó.

Registra las rutas lentas por grupo. Para público, observa porcentaje servido por caché y tiempo de origen. Para administración, mide guardar entradas, buscar medios y abrir listados. Para tareas, registra duración, memoria máxima y si se solapan. Esa separación permite decidir si necesitas más RAM, corregir un plugin o mover solo una tarea a otro proceso.

WP-Cron se dispara con visitas y puede ejecutar trabajo en una solicitud de usuario. Al reemplazarlo por cron del sistema, desactiva el disparador por página y llama el mecanismo de WordPress con una frecuencia definida. Evita múltiples ejecutores y aplica bloqueo si una corrida puede superar el intervalo. Comprueba acciones atrasadas, no solo que cron se inició.

Los backups deben leer base y archivos con consistencia y salir del VPS. Si comprimen todo localmente durante el pico, consumen CPU, memoria y disco. Limita prioridad, programa fuera de horas críticas y alerta por duración anormal: un backup que tarda cada día más puede anticipar crecimiento de datos o almacenamiento degradado.

Una hoja de decisión basada en cuellos de botella

Antes de ampliar el plan, asocia cada síntoma a una señal:

Amplía cuando el trabajo legítimo rebasa capacidad después de corregir desperdicio. Si CPU se satura pero sobra RAM, más memoria por sí sola no ayuda; necesitas más vCPU, caché o consultas más baratas. Si OOM mata procesos con CPU moderada, revisa workers y memoria antes de añadir núcleos. Un plan mayor es efectivo cuando responde al recurso realmente agotado.

Comprobar el origen sin que la caché esconda el límite

Una prueba servida íntegramente por CDN puede mostrar excelente latencia mientras PHP está saturado. Ejecuta también una ruta dinámica autorizada o una solicitud de staging que omita caché, y compara el encabezado que identifica HIT o MISS. No añadas parámetros aleatorios en producción: podrías crear variantes infinitas.

La aceptación necesita ambos caminos. La página pública cacheada debe resistir volumen con poco trabajo de origen; login, búsqueda y administración deben mantener una cola controlada. Si solo falla el segundo grupo, ampliar CDN no resolverá PHP o base. Si el origen está sano y usuarios remotos siguen lentos, revisa red, peso de recursos y ubicación antes de comprar más CPU.