Guía para dimensionar un VPS y ajustarlo de forma fiable a tus necesidades

Publicado el 20 de octubre de 2026

Un VPS que parece lento normalmente no carece de todos los recursos. Le falta un recurso en el momento menos oportuno: memoria durante un pico de tráfico, CPU al generar informes, operaciones de E/S de disco durante las copias de seguridad o ancho de banda en plena campaña. Esta guía para dimensionar un VPS te ayuda a identificar la demanda real antes de pagar por una capacidad que no vas a usar o, peor aún, implementar un servidor que empiece a dar problemas el primer lunes de mucho tráfico.

El objetivo no es elegir el plan más grande. Se trata de dar a cada carga de trabajo espacio suficiente para funcionar con normalidad, absorber los picos previstos y recuperarse sin problemas cuando algo tarda más de lo esperado. Un VPS bien dimensionado debería funcionar con tranquilidad con una carga normal y conservar un margen de capacidad cuantificable.

Empieza por la carga de trabajo, no por el plan

El dimensionamiento empieza por determinar qué hará realmente el servidor. Un sitio web corporativo, una tienda WooCommerce, una aplicación SaaS, un entorno de desarrollo y un servidor de agencia que aloja varios sitios de clientes pueden tener un número similar de visitantes y, aun así, necesitar recursos muy distintos.

Primero, identifica los servicios que comparten el VPS. Un servidor web, una base de datos, procesos de PHP, una caché, un repetidor de correo electrónico, tareas en segundo plano, contenedores Docker, agentes de monitorización y tareas de copia de seguridad consumen recursos siguiendo patrones propios. La base de datos puede necesitar memoria y acceso rápido al disco, mientras que un trabajador de cola puede requerir CPU solo durante unos minutos cada hora.

Fíjate también en los momentos más importantes. El uso medio es útil, pero el uso máximo determina si los clientes ven un servicio ágil o una página de tiempo de espera agotado. Una tienda en línea puede estar tranquila durante la noche y recibir de pronto un aluvión de pedidos tras una campaña por correo electrónico. Una plataforma SaaS puede funcionar sin problemas todo el día hasta que empiezan las importaciones programadas a medianoche. Los registros cuentan la misma historia: los promedios pueden ser discretos, pero los picos son más sinceros.

Si vas a sustituir un servidor existente, recopila mediciones de al menos una o dos semanas antes de elegir el nuevo tamaño. Revisa el uso de CPU, la memoria disponible, la actividad de intercambio, el espacio en disco, la espera de E/S de disco, la transferencia de red y el tiempo de respuesta de la aplicación. Cuando sea posible, incluye la actividad empresarial habitual y un período de mucho tráfico conocido.

Los cuatro recursos que determinan el tamaño de un VPS

CPU: potencia para el trabajo activo

Los núcleos de CPU determinan cuánto trabajo activo puede completar tu VPS a la vez. Los sitios dinámicos usan CPU para PHP, Node.js, Python, Java, solicitudes de API, procesamiento de imágenes, indexación de búsquedas, cifrado y tareas programadas. Disponer de más núcleos resulta especialmente útil cuando es necesario ejecutar varias solicitudes o tareas en segundo plano a la vez.

Para un sitio de contenido pequeño con caché, 1 o 2 vCPU pueden ser suficientes. Un sitio con mucho tráfico de WordPress o WooCommerce, una pequeña pila de aplicaciones o varios sitios con poco tráfico suelen funcionar mejor con 2 a 4 vCPU. Las aplicaciones con importaciones habituales, conversión de imágenes, tareas de CI o varios contenedores pueden necesitar 4 o más vCPU incluso con un tráfico moderado.

Presta atención al uso sostenido de CPU, no a los picos breves. Que un servidor alcance el 90 % de uso de CPU durante unos segundos al implementar una versión no significa automáticamente que esté infradimensionado. Un servidor que supera aproximadamente el 70 % durante períodos de actividad normal intensa tiene menos margen para los picos de tráfico, los análisis de seguridad y las tareas de mantenimiento habituales.

El dimensionamiento de CPU también depende del diseño del software. Una caché de páginas agresiva puede reducir considerablemente la demanda de CPU. Las consultas a bases de datos mal optimizadas pueden consumir todos los núcleos disponibles con una determinación admirable. Añadir CPU ayuda, pero no debería sustituir la corrección de un problema evitable en la aplicación.

RAM: el recurso que evita problemas

La memoria suele ser el primer recurso que conviene dimensionar con cuidado. La RAM da soporte al sistema operativo, los procesos web, los búferes de la base de datos, la caché, los contenedores y las herramientas de monitorización. Cuando se agota la memoria física, Linux empieza a usar espacio de intercambio en el disco. El espacio de intercambio sirve como colchón de emergencia, pero su uso frecuente es una señal de alerta, no una estrategia de rendimiento.

Un servidor Linux ligero con una pila web sencilla puede funcionar con 1 o 2 GB de RAM. Para un sitio web de producción que usa una base de datos y caché, 2 a 4 GB son un punto de partida más realista. Las tiendas, las instalaciones grandes de CMS, los sitios de varios clientes y los servidores de aplicaciones suelen necesitar 4 a 8 GB o más, según el número de procesos trabajadores y la actividad de la base de datos.

No calcules la RAM basándote únicamente en la documentación de la aplicación. Ten en cuenta el comportamiento real de los procesos. Por ejemplo, cada proceso trabajador de PHP puede consumir una cantidad considerable de memoria, y un aumento de visitantes simultáneos puede multiplicar rápidamente ese consumo. Los motores de bases de datos también usan memoria para mantener disponibles los datos a los que se accede con frecuencia, sin tener que leerlos repetidamente del disco.

Un objetivo práctico es conservar memoria disponible durante los picos de actividad y evitar el uso sostenido del espacio de intercambio. Si tu servidor tiene RAM libre, pero los tiempos de respuesta siguen siendo malos, investiga la saturación de CPU, las operaciones de E/S de disco, los bloqueos de la base de datos o las demoras de las API externas antes de limitarte a aumentar la memoria.

Almacenamiento: la capacidad es solo la mitad de la cuestión

El dimensionamiento del almacenamiento tiene dos aspectos: cuánto espacio necesitas y con qué rapidez responde el disco. Un VPS puede tener mucho espacio libre en disco y aun así funcionar mal si la carga de trabajo genera más operaciones de disco de las que puede gestionar la capa de almacenamiento.

Calcula la capacidad teniendo en cuenta el sistema operativo, los archivos de la aplicación, las bases de datos, las cargas, los registros, los archivos temporales y la retención local de copias de seguridad. Después, añade margen para el crecimiento. Las bases de datos crecen poco a poco... hasta que dejan de hacerlo. Los archivos de registro pueden crecer muy rápido cuando se produce un error en la aplicación; no es precisamente el mejor momento para descubrir que el disco está lleno.

Para la mayoría de las cargas de trabajo de producción, el almacenamiento SSD o respaldado por NVMe es una opción básica sensata. El almacenamiento rápido es importante para las consultas a bases de datos, las operaciones de pago de WooCommerce, la administración de CMS, las actualizaciones de software y la compresión de copias de seguridad. Si la espera de E/S de disco aumenta durante los períodos de mucha actividad, es posible que el servidor esté esperando al almacenamiento y no que le falte CPU.

Evita guardar tu única copia de seguridad en el mismo VPS que el servicio en producción. Las instantáneas locales pueden acelerar la recuperación, pero las copias de seguridad independientes te protegen frente a una gama más amplia de fallos, incluidos los borrados accidentales y los problemas del servidor.

Ancho de banda y transferencia de red: mide la dirección del tráfico

El ancho de banda es la velocidad de la conexión. La transferencia es la cantidad total de datos movidos durante un período de facturación. Ambos aspectos importan, pero resuelven problemas distintos.

Un sitio con muchos archivos multimedia, un servicio de descarga, una plataforma de API o una tienda con imágenes de productos grandes puede transferir muchos más datos que un sitio web basado en texto con el mismo número de visitantes. El uso de CDN, la optimización de imágenes, la caché del navegador y el almacenamiento de objetos pueden reducir el tráfico que pasa por el VPS. En el caso del tráfico de aplicaciones, ten en cuenta también los datos salientes: las respuestas de API, las copias de seguridad enviadas a ubicaciones externas, la replicación y las exportaciones de monitorización salen del servidor.

La capacidad de red debería admitir los picos previstos, mientras que el límite de transferencia debería cubrir el uso mensual con cierto margen. Si tu equipo de marketing está preparando un lanzamiento, dimensiona el servidor para la campaña antes de que empiece. A los servidores tampoco les gustan las sorpresas.

Una referencia práctica para dimensionar un VPS

Estos valores son puntos de partida, no reglas fijas. El software, los patrones de tráfico, la configuración de la caché y los requisitos de administración pueden cambiar la respuesta.

• Un sitio corporativo pequeño o un servidor de desarrollo suele funcionar con 1 a 2 vCPU, 1 a 2 GB de RAM y 20 a 40 GB de almacenamiento rápido.
• Un sitio web empresarial, una instalación de CMS pequeña o una aplicación de poco volumen suele funcionar cómodamente con 2 vCPU, 2 a 4 GB de RAM y 40 a 80 GB de almacenamiento rápido.
• Un CMS con mucho tráfico, una tienda WooCommerce, un entorno de alojamiento para agencias o un servicio SaaS pequeño suele necesitar 2 a 4 vCPU, 4 a 8 GB de RAM y 80 GB o más de almacenamiento rápido.
• Una aplicación con un uso intensivo de bases de datos, una tienda grande, una pila de contenedores o una carga de trabajo con procesamiento frecuente en segundo plano puede necesitar 4 o más vCPU, 8 GB de RAM o más y almacenamiento elegido específicamente por su rendimiento de E/S.

El tamaño inicial adecuado debería dejar aproximadamente entre un 25 % y un 40 % de margen durante los picos de actividad normales. Ese margen no es un desperdicio. Da al servicio espacio para el crecimiento del tráfico, las copias de seguridad, las actualizaciones de seguridad y esos comportamientos ocasionales de la aplicación que aparecen sin invitación.

Valida el dimensionamiento después de la implementación

El dimensionamiento no es una decisión que se tome una sola vez. Implementa la carga de trabajo, monitorízala y haz ajustes basándote en datos. Las señales más útiles son la carga sostenida de CPU, la presión sobre la memoria, el uso del espacio de intercambio, la espera de E/S de disco, el crecimiento del almacenamiento, el uso de la red y los tiempos reales de respuesta de la aplicación.

Las métricas de Prometheus y Grafana son especialmente útiles para los equipos que quieren relacionar la actividad de la infraestructura con la experiencia de los usuarios. Por ejemplo, un pico en el tiempo de respuesta que coincida con una espera elevada de E/S apunta a una causa distinta de la de uno que coincida con el agotamiento de los procesos trabajadores de PHP. La monitorización convierte el redimensionamiento en una tarea operativa controlada, en lugar de dejarlo a las conjeturas.

El soporte gestionado también cambia los cálculos para muchas empresas. Un equipo con conocimientos técnicos puede preferir ajustar los procesos trabajadores, las cachés, la configuración de la base de datos y los horarios de las copias de seguridad antes de pasar a un VPS más grande. En kodu.cloud, esa revisión operativa forma parte de mantener el servicio funcionando con normalidad, en lugar de tratar cada alerta como una excusa para comprar más servidor.

Planifica el crecimiento sin pagar por espacio vacío

Elige un VPS que pueda gestionar tu carga máxima actual con margen y, después, confirma que ampliar la CPU, la RAM o el almacenamiento será sencillo cuando los datos lo justifiquen. Empezar con un tamaño demasiado pequeño puede obligarte a migrar con urgencia. Empezar con un tamaño mucho mayor del necesario puede ocultar código ineficiente y consumir presupuesto sin mejorar la experiencia del cliente.

Revisa mensualmente las tendencias de uso de recursos, sobre todo después de lanzar funciones nuevas, añadir sitios de clientes, cambiar las políticas de copias de seguridad o realizar una campaña de marketing exitosa. Un servidor debería crecer porque la carga de trabajo ha demostrado que lo necesita, no porque el nombre del plan sonara tranquilizador. Con métricas claras y algo de capacidad de reserva, puedes descansar mientras la infraestructura sigue haciendo su trabajo.

Andres Saar, ingeniero de atención al cliente