Paso a paso: cómo elegir el tamaño de VPS adecuado para tu proyecto

Hospedagem & VPS · Por · Publicado el · Actualizado el · 9 min de lectura

Racks de servidores iluminados con LEDs azules en un data center
Rack de servidores en data center, representando infraestructura para VPS y hospedaje Foto: panumas nikhomkhai / Pexels

Elegir el tamaño correcto de VPS para tu proyecto implica traducir métricas reales en necesidades de CPU, RAM, disco y red. En este tutorial práctico seguirás un proceso para medir, probar y validar la capacidad necesaria, evitando tanto el subdimensionamiento como el desperdicio, con comprobaciones sencillas y criterios objetivos para tomar la decisión con seguridad.

Pre requisitos

Antes de empezar, asegúrate de contar con algunos elementos que hacen el dimensionamiento objetivo. Algunos pasos requieren acceso root y generarán carga sintética para las pruebas.

Ten un entorno que represente producción, datos de uso reales y permiso para ejecutar herramientas de medición. Define metas de rendimiento simples: latencia objetivo, tasa de errores y ventanas de pico.

  • Acceso SSH al servidor actual o al entorno de pruebas
  • Permiso para instalar utilitarios (sysstat, iostat, ab)
  • Una ventana para recopilar métricas en horario de pico
  • URLs de endpoints de prueba y una base de datos representativa
  • SLOs básicos: latencia p95, tasa de errores, throughput

1) Define objetivo y perfil de carga del proyecto

Mapea cómo la aplicación consume recursos. Clasifica componentes por tipo de carga: CPU, memoria, disco o red.

Las aplicaciones web y APIs suelen estar limitadas por CPU y red. Las bases de datos sufren por I/O. Jobs de procesamiento son intensivos en CPU o memoria.

Lista endpoints críticos, colas y jobs. Contar con correlación y logs ayuda a identificar cuellos de botella con precisión. Consulta la guía de logs estructurados.

  • Web/API síncrona: CPU y conexiones simultáneas
  • BD/informes: I/O y memoria para caches
  • Cola/procesamiento: CPU y disco temporal
  • Streaming/uploads: red y disco para buffering

2) Mide CPU, memoria y disco en el entorno actual

Recopila métricas reales durante varios minutos en un horario representativo. Activa la telemetría con cuidado en producción.

Observa: uso de CPU por modo, run queue, steal time, consumo de memoria y swap, iowait e IOPS del disco. Esto revela el recurso limitante.

# Ubuntu/Debian: instalar utilitários de medição
sudo apt-get update && sudo apt-get install -y sysstat apache2-utils

# Habilitar coleta do sysstat (sar)
if [ -f /etc/default/sysstat ]; then
  sudo sed -i 's/ENABLED=\"false\"/ENABLED=\"true\"/' /etc/default/sysstat
  sudo systemctl enable --now sysstat
fi

# CPU: uso por modo e run queue por 60s
sar -u 1 60
# Memória: livres, cache, swap por 60s
sar -r 1 60
# Disco: latência, IOPS, iowait por 10s
iostat -xz 1 10
# Visão rápida do sistema
vmstat 1 10

3) Estima concurrencia y throughput esperados

Traduce el tráfico del negocio en concurrencia técnica. Usa picos previstos, campañas y horarios de mayor uso. Calcula la relación entre peticiones por segundo y el tiempo medio de respuesta para estimar conexiones simultáneas.

Para jobs asíncronos, estima ítems por minuto y tiempo medio por ítem para inferir cuántos workers simultáneos serán necesarios.

Tipo de carga Cómo estimar concurrencia Métrica base
Web/API Req/s x tiempo medio de respuesta ≈ conexiones activas Latencia p95 y tasa de pico
Cola/Jobs Ítems/min x tiempo medio por ítem ≈ workers activos Duración media por job
BD/Informes Consultas concurrentes y tiempo por consulta Tiempo p95 de query
Uploads/Streaming Tasa de conexiones y bitrate medio Ancho de banda por sesión

4) Convierte señales en vCPU, RAM, disco y red

Usa la lectura de métricas para guiar el tamaño mínimo seguro. Combina ajustes de código y dimensionamiento para alcanzar un punto de coste/beneficio adecuado.

Evita números fijos. Comienza pequeño con una holgura razonable y valida en una prueba de carga representativa. Para cuellos de botella en API y SQL, consulta recursos sobre cómo reducir la latencia de APIs REST y optimización de queries.

Señal observada Interpretación Ajuste recomendado en la VPS
CPU user > 70% sostenido; run queue > vCPU CPU es cuello de botella Aumentar vCPU u optimizar endpoints más calientes
Steal time > 5% Host sobrecargado/CPU compartida Preferir vCPU dedicada u otro host
Memoria > 80% con swap activo Memoria es cuello de botella Más RAM o reducir caches/footprint
iowait > 10% o latencia alta del disco I/O es cuello de botella Usar SSD/NVMe más rápidos; aumentar IOPS; separar volúmenes
Red cerca del límite contratado Red es cuello de botella Más ancho de banda, optimizar payloads, compresión, CDN

5) Elige almacenamiento y red adecuados

El disco correcto cambia el juego en bases de datos y colas. La red adecuada evita colas en el kernel y timeouts bajo pico.

Combina rendimiento con durabilidad y coste. Los cambios de disco pueden requerir parada planificada.

  • SSD SATA: buen coste. NVMe: baja latencia e IOPS elevados.
  • Volumen local: rápido, pero menos resiliente. Bloque gestionado: snapshots e IOPS configurables.
  • Separar SO, datos y logs reduce la contención.
  • Red medida en Mbps o TB de tráfico; verifica límites de burst y política de egress.

6) Haz un smoke test de carga antes de la compra definitiva

Valida el tamaño candidato con una prueba simple. Esto genera tráfico; ejecútalo en staging o fuera del horario de pico.

Mide latencia p95, tasa de errores y uso de CPU/RAM durante la prueba. Ajusta y repite hasta quedar dentro de los SLOs.

# Exemplo com ApacheBench (ab): 2000 requisições, 50 concorrentes
# Substitua pela sua URL de teste
ab -n 2000 -c 50 https://seu-dominio.test/health

# Dica: rode em uma máquina fora da VPS alvo para evitar viés
# Colete métricas em paralelo (em outro terminal)
sar -u 1 60 &
sar -r 1 60 &
iostat -xz 1 60 &
wait

7) Planifica margen de holgura y estrategias de escala

Reserva holgura para picos y jitter de tráfico. La holgura evita colas largas de latencia y degradación por GC, warmups y bursts.

Define el criterio de escala: vertical para simplicidad; horizontal para resiliencia. Los contenedores pueden facilitar la orquestación sobre VMs. Consulta comparativos Docker vs máquinas virtuales para alta disponibilidad.

  • Automatiza alertas por CPU, memoria y latencia p95.
  • Escala vertical: ajustar vCPU/RAM cuando la métrica supere el umbral.
  • Escala horizontal: balanceador y múltiples VMs más pequeñas.
  • Evita el overprovision: revisa mensualmente tu uso medio y picos.

8) Revisa costos y confirma con la calculadora del proveedor

El precio varía por vCPU, RAM, disco, tráfico y región. Consulta la calculadora del proveedor antes de cerrar. No asumas valores estáticos.

Prueba modelos de facturación: por hora, paquete mensual, IOPS provisionado y egress de red. Compara regiones y tipos de disco. Para ideas adicionales de optimización, revisa recursos sobre cómo reducir costes en la nube.

  • Compara variación por región y por tipo de almacenamiento.
  • Evalúa si vCPU dedicada compensa en cargas estables.
  • Comienza más pequeño, valida y luego ajusta el plan.
  • Revisa optimizaciones de coste periódicamente.

Cómo confirmar que funcionó y solución de problemas comunes

Tras definir el tamaño de la VPS, valida en producción con telemetría ligera. Si aparece inestabilidad, verifica las señales siguientes y ajusta.

Errores comunes: alto steal de CPU, swap continuo, iowait elevado y colas largas de conexión. Trata la causa raíz antes de simplemente aumentar recursos. Para APIs lentas, consulta consejos sobre reducción de latencia y optimización SQL.

  • CPU steal alto: migra a un host menos concurrido o vCPU dedicada.
  • Swap constante: aumenta RAM y revisa caches y límites de procesos.
  • iowait alto: cambia a NVMe, aumenta IOPS, separa volúmenes de datos/logs.
  • Picos de latencia p95: activa compresión, cache y revisa N+1 en queries.
# Verificações rápidas pós-go-live
# CPU: uso por modo e steal time por 30s
mpstat 1 30
# Memória e swap
free -h && vmstat 1 10
# Fila de execução e iowait
sar -q 1 10 && iostat -xz 1 10

Preguntas frecuentes

¿Cuál es la diferencia entre vCPU compartida y dedicada?

La vCPU compartida reparte la CPU física entre varias VMs y puede sufrir contendencia que se refleja como steal time; esto causa variaciones de rendimiento. La vCPU dedicada ofrece ciclos más previsibles y puede estabilizar cargas sensibles a latencia. Si tus métricas muestran variaciones inexplicables o alto steal, probar una opción dedicada o migrar de host puede mejorar la estabilidad.

¿Cuánta holgura debo mantener al dimensionar la VPS?

La holgura depende del perfil de carga y de la tolerancia a picos: reserva margen suficiente para absorber variaciones, jitter y eventos inesperados sin degradar los SLOs. Valida esa holgura con pruebas de carga representativas y revisa los datos reales tras la primera semana y después de eventos estacionales para ajustar el margen según observaciones.

¿Se recomienda usar swap en producción?

El swap puede evitar OOM puntuales actuando como protección, pero si se usa de forma continua degrada la latencia y el rendimiento. Úsalo con tamaño moderado como respaldo temporal; si observas uso habitual de swap, la solución adecuada es reducir consumo de memoria o aumentar RAM, no depender de mayor swap como parche permanente.

¿Qué es el CPU steal time y por qué importa?

El CPU steal time es el periodo en que la VM necesita CPU pero el hypervisor no la entrega debido a contendencia en el host; valores altos provocan lentitud impredecible. Es una señal de que el recurso físico está sobrecargado; ante steal recurrente considera vCPU dedicada, cambiar a otra familia de host o migrar la carga a una máquina con menos contendencia.

¿Cómo decidir entre SSD SATA y NVMe para la base de datos?

Si la base de datos muestra iowait elevado, colas de I/O o latencias inaceptables, NVMe aporta menor latencia y más IOPS, mejorando el rendimiento. Si la carga I/O es ligera y no es el cuello de botella, un SSD SATA puede ser suficiente y más económico. Siempre valida la elección con pruebas de carga y monitorización real.

¿Quieres validar tu dimensionamiento con una prueba guiada?

Puedo ayudarte a transformar tus métricas en una especificación de VPS objetiva y probada, con plan de evolución sin desperdicio.

Hablar sobre tu proyecto

Ver también