Dimensionar un VPS para el sitio de un cliente: RAM y CPU

Un cliente pregunta "¿qué VPS necesita mi sitio?" y la respuesta, demasiadas veces, es una intuición. De ahí salen dos errores. El primero es contratar el plan superior "por precaución": en una cartera de veinte clientes, ese margen muerto se paga cada mes y se come el margen de la agencia. El segundo es quedarse corto: el primer pico de tráfico, una copia de seguridad o una importación de catálogo tumba el sitio, y el cliente se entera antes que usted.

La objeción habitual es "no hay tiempo para medir". Sin embargo, la medición cabe en una hora de observación activa, con herramientas que ya están en cualquier distribución Linux. Y la primera elección no es definitiva: un VPS se redimensiona en vertical, es decir, se pasa a un plan mayor sin reconstruir la arquitectura. Lo importante no es acertar a la primera, sino elegir con cifras y un margen escrito que pueda defender ante el cliente.

El razonamiento vale también para el profesional que gestiona su propio sitio, por ejemplo una tienda en línea: el coste de un plan demasiado grande se ve en la factura mensual, el de uno demasiado ajustado en las ventas perdidas durante un pico de pedidos. Las mismas lecturas permiten entonces decidir con conocimiento de causa, sin intermediarios.

Esta guía trata la medición previa a la compra y la elección del plan. Para decidir entre VPS y alojamiento compartido, lea antes VPS o alojamiento compartido para un sitio cliente. Para la alerta continua una vez el VPS está en producción, vea alertas de disco y RAM en un VPS.

La medición se hace en el servidor actual del cliente, el que soporta la carga real, y no en una copia vacía. Necesita acceso SSH de lectura, permisos para ejecutar ps, free y df y, si es posible, poder instalar el paquete sysstat, que aporta sar y conserva un historial de la carga.

En cuanto a la duración, cuente con al menos una semana de historial si sysstat ya está activo; si no, una ventana de observación de al menos una hora que incluya a propósito un momento cargado: un pico de tráfico conocido, la copia nocturna, una tarea programada o una importación. Medir un martes a las 3 de la madrugada no dice nada del día de rebajas. Anote por último el contexto: aplicación (WordPress, tienda, aplicación a medida), presencia de contenedores, base de datos en la misma máquina o no.

Un servidor que muestra un 25 % de CPU de media en 24 horas puede estar saturado diez minutos cada noche. La media borra justo lo que tumba un sitio. Para dimensionar, conserve el valor máximo observado en la ventana y compruebe que incluye el peor momento conocido: pico de tráfico, copia de seguridad, cron pesado, importación.

Si el cliente no sabe cuándo están sus picos, cruce los datos con los registros de acceso del servidor web y con las fechas de campañas de correo o promociones. Una semana de historial sar cubre un ciclo completo, fin de semana incluido. Cuando el sitio ya va lento, una lectura tomada durante la lentitud vale más que diez lecturas en calma.

La regla siguiente es editorial, no una norma ni una promesa del catálogo: memoria necesaria = consumo en el pico, más un margen del 30 %. La cifra del 30 % es la hipótesis de este artículo; cubre el crecimiento a corto plazo y los picos que su ventana no vio. Para el disco, cuente el espacio usado, más el crecimiento previsto a seis meses, más al menos un 20 % libre.

Para un sitio con PHP-FPM, calcule la memoria de los procesos en vez de leerla globalmente: memoria PHP = RAM medida por proceso multiplicada por pm.max_children. Mida la RAM por proceso con ps -eo rss,args | awk '/[p]hp-fpm: pool/ {s+=$1; n++} END {print s/n/1024 " MB"}'. El resultado sobreestima un poco, porque parte de la memoria se comparte entre procesos.

Ejemplo numérico ficticio: 600 MB para el sistema, el servidor web y la base de datos, más 20 procesos de 60 MB, es decir 1.200 MB, dan 1.800 MB en el pico. Con un 30 % de margen hacen falta unos 2,4 GB: se elige el plan cuya RAM sea inmediatamente superior.

Con el sitio ya en producción, unas pocas señales indican que el plan se queda corto. Cada una deja un rastro preciso que puede buscar sin esperar la queja del cliente.

Antes de subir de plan, compruebe que el problema es realmente de recursos. Una consulta SQL lenta satura la CPU sea cual sea el plan: el índice que falta se corrige, no se compensa. La ausencia de caché de objetos obliga a PHP a recalcular las mismas páginas en cada visita. Una imagen de 8 MB servida tal cual consume ancho de banda y tiempo de proceso. Y subir pm.max_children sin subir la RAM provoca exactamente la muerte por el kernel que quería evitar.

El enfoque sano es corregir primero esos puntos, repetir la lectura y dimensionar con el resultado. Así evita facturar al cliente un plan mayor que solo oculta un defecto de configuración.

Con la necesidad cifrada, compárela con la gama. El plan VPS Start ofrece 2 vCPU, 4 GB de RAM y 50 GB SSD de almacenamiento; el plan VPS Power ofrece 4 vCPU, 8 GB y 100 GB SSD; el plan VPS Business ofrece 8 vCPU, 16 GB y 200 GB SSD. Precio de entrada de la gama: 99 DH/mes.

Elija el plan más pequeño que cubra su necesidad con el margen escrito y deje que la escalabilidad vertical haga el resto: si la siguiente lectura muestra que el margen se agota, pasa al plan superior sin cambiar de arquitectura. Para no esperar a esa lectura, configure alertas continuas y, para saber si el sitio responde desde fuera, una sonda de disponibilidad: vea el seguimiento de disponibilidad de los sitios cliente.