¿Cuánto servidor necesitas realmente? Cómo dimensionar CPU, RAM y almacenamiento según la carga de trabajo

Primero la respuesta: el método

Dimensionar es multiplicar tres números entre sí, no adivinar:

1. Línea base: lo que consume la carga de trabajo bajo carga normal. Mídela si la carga de trabajo ya existe en algún sitio hoy (un VPS, una máquina de staging, tu portátil bajo pruebas de carga); estímala con las reglas prácticas de más abajo si no es así.
2. Margen: multiplica por 1.5–2×. El margen absorbe los picos de tráfico, las tareas en segundo plano y el precipicio de rendimiento que sufre todo sistema cerca de la saturación (una base de datos al 90% de RAM se comporta mucho peor que una al 60%, no solo un 30% peor).
3. Crecimiento: proyecta sobre todo el plazo del compromiso, no sobre la primera semana tras el lanzamiento. Si los datos crecen 10 GB/mes, un año necesitará 120 GB más que hoy.

Y una regla general que evita la categoría de error más cara: dimensiona la RAM y el almacenamiento con generosidad, la CPU con moderación. Una CPU infradimensionada hace que las cosas vayan más lentas; una RAM insuficiente o los discos llenos hacen que las cosas fallen. La CPU es además el recurso que las cargas de trabajo más sobrestiman (la mayoría de los servidores están inactivos la mayor parte del tiempo), mientras que la RAM es el que más suelen subestimar.

Si solo quieres valores por defecto, aquí tienes puntos de partida honestos; el resto del artículo es el razonamiento para ajustarlos:

CPU: núcleos frente a frecuencia

La carrera armamentística por el número de núcleos oculta la pregunta que realmente importa: ¿tu carga de trabajo es paralela o secuencial?

• Las cargas de trabajo paralelas (virtualización, CI, codificación de vídeo, APIs con mucho tráfico de peticiones) escalan con el número de núcleos. Compra núcleos.
• Las cargas de trabajo secuenciales (ticks de servidor de juego, bucles de aplicación single-thread, muchas rutas de consulta de base de datos) están limitadas por la velocidad de un solo núcleo. Compra frecuencia (y microarquitectura más nueva), no núcleos; sesenta y cuatro núcleos lentos pierden contra ocho rápidos, y este es el error de dimensionamiento más común en servidores de juego.
• Realidad mixta: un stack web es paralelo entre peticiones, pero cada petición en sí es secuencial, así que un número medio de núcleos con buen rendimiento por núcleo es lo que mejor encaja, y por eso es el punto óptimo en el que aterrizan la mayoría de las cargas de trabajo web.

Notas prácticas: los hyperthreads no son núcleos (cuéntalos como ~+20–30% de throughput, no como ×2); los hosts de virtualización pueden sobreasignar CPU de forma significativa (los guests raramente alcanzan el pico a la vez, de ahí el ×0.7 de la tabla), pero nunca deben sobreasignar RAM.

RAM: el recurso en el que lamentarás haber escatimado

Reglas prácticas que se sostienen:

• Bases de datos: el working set (los datos que realmente se tocan con regularidad) debe caber en la RAM, con margen de sobra. La palanca de rendimiento más importante de una base de datos no es el ajuste de consultas, sino si las lecturas vienen de memoria o de disco. Estima el conjunto activo (a menudo el 10–30% de los datos totales), añade los índices, multiplica por 1.5.
• Virtualización: la RAM es la restricción determinante para la densidad de VM en casi cualquier despliegue real. A los hosts se les acaba la memoria mucho antes que la CPU. Suma las asignaciones de tus guests, añade 4–8 GB para el host (más si usas ZFS: su caché consumirá con gusto y de forma útil todo lo que sobre).
• Web/app: procesos de la aplicación × huella por proceso, más las cachés de opcode/objetos, más la caché de archivos del sistema operativo (por eso la RAM «no usada» acelera tus lecturas de disco: Linux usa cada gigabyte inactivo como caché).
• El modo de fallo que hay que evitar es el swap bajo carga: cuando la RAM se agota, el rendimiento no se degrada con suavidad, se desploma mientras el disco sufre thrashing. Si la monitorización muestra cualquier actividad de swap sostenida bajo carga normal, el servidor ya está infradimensionado hoy, no dentro de poco.

Almacenamiento: la capacidad es la mitad fácil

• Capacidad: datos actuales × crecimiento durante el plazo + 30% de margen (los discos llenos corrompen bases de datos y bloquean despliegues en los peores momentos). Aplica después el overhead del RAID. La capacidad utilizable no es la capacidad en bruto, y esa diferencia es el tema de nuestra guía de niveles RAID: los espejos la reducen a la mitad, la paridad cuesta un disco.
• Rendimiento: para todo lo sensible a la latencia (bases de datos, almacenes de VM, aplicaciones web muy concurridas) la respuesta en 2026 es NVMe, sin discusión: la brecha de I/O aleatoria frente a los SSD SATA es grande, y frente a los HDD es categórica. Los discos mecánicos conservan exactamente un papel: capacidad masiva barata para medios, archivos y destinos de backup, idealmente detrás de una capa de NVMe para la ruta activa.
• Endurance: las cargas de trabajo con muchas escrituras (bases de datos con mucho churn, scratch de CI, ingesta de vídeo) consumen la resistencia de escritura de los SSD. Rara vez es un problema a intensidades habituales, pero si esperas reescribir varios TB al día, menciónalo al especificar: existen discos de nivel datacenter con valores de endurance más altos justo para esto.

Ancho de banda: aritmética, no intuición

Convierte entre volumen mensual y tasa sostenida con un solo factor: 1 TB/mes ≈ 3 Mbit/s de media sostenida. Así que un puerto de 1 Gbit/s, saturado a tope, mueve ~330 TB/mes, lo que indica de inmediato que la mayoría de las cargas de trabajo no están ni de lejos limitadas por el puerto en volumen. Lo que de verdad decide la especificación de red:

• Picos, no medias. El tráfico llega a ráfagas; un sitio que promedia 30 Mbit/s puede dispararse a varios cientos durante un lanzamiento. La velocidad del puerto compra absorción de ráfagas.
• El tráfico este-oeste (replicación, backups, sincronización de almacenamiento entre tus propios servidores) es donde el 10 Gbit/s se amortiza mucho antes que el tráfico público. (Aritmética de la ventana de backup: restaurar 4 TB por 1 Gbit/s tarda ~9 horas; por 10 Gbit/s, menos de una. Dimensiona el puerto para la restauración que algún día tendrás que sufrir.)
• La latencia es una propiedad de la ubicación y la red, no de la velocidad del puerto; los servidores de juego y las apps en tiempo real deben elegir primero la proximidad al datacenter y la calidad de red (aquí pesa más ejecutar sobre el propio ASN bien conectado de un proveedor que la cifra del puerto).

¿Escalado vertical o escalado horizontal?

Cuando te quedas corto con un servidor, hay dos direcciones posibles, y la correcta depende de la forma de la carga de trabajo:

Escalar verticalmente (un servidor más grande) mientras puedas: es operativamente gratis (sin cambios de código, sin el peaje de los sistemas distribuidos), y el hardware dedicado aguanta muchísimo antes de tocar techo. Las bases de datos prefieren especialmente este camino; las bases de datos distribuidas son un último recurso, no un plan de crecimiento.

Escalar horizontalmente (más servidores) cuando la carga de trabajo se divide de forma natural: niveles web/app sin estado detrás de un balanceador de carga (también tu historia de redundancia: dos servidores medianos ganan a uno grande el día en que uno de ellos necesita un reinicio), instancias de servidor de juego por región, runners de CI por cola. La primera división clásica es mover la base de datos a su propia máquina: una migración, y ambos niveles obtienen un perfil de recursos dedicado ajustado a lo que realmente necesitan (los núcleos para el nivel web, la RAM y el NVMe para la base de datos).

Preguntas frecuentes

¿Cuánta RAM necesita realmente mi base de datos?

Parte del conjunto de datos activo, no del total: una base de datos de 500 GB cuyas consultas tocan a diario 50 GB de filas e índices funciona de maravilla con 96 GB de RAM y fatal con 16 GB, mientras que un archivo de 2 TB consultado en raras ocasiones puede vivir tranquilamente con mucho menos de lo que su tamaño sugiere. Determina el conjunto activo de forma empírica cuando sea posible (ratios de acierto de caché en las métricas de pg_stat/InnoDB de tu sistema actual), añade los índices y un 50% de margen, y revísalo cada año. Los conjuntos activos crecen.

¿Necesito un puerto de 10 Gbit/s?

Para tráfico público, probablemente no: 1 Gbit/s mueve, a plena saturación, ~330 TB/mes, muy por encima de lo que necesita la mayoría de los sitios. Las cargas de trabajo que realmente quieren 10 GbE son las que van entre servidores: replicación de bases de datos, migración de VM, almacenamiento distribuido y, sobre todo, ventanas de backup/restauración (una restauración de varios TB por 1 Gbit/s es un incidente que dura todo el día; por 10 Gbit/s es una pausa para el café). Si tu arquitectura incluye algún trasiego de datos permanente entre máquinas, especifícalo así; si no, invierte la diferencia en RAM.

¿Debería sobreaprovisionar ahora o actualizar más adelante?

Sobreaprovisiona lo que resulta disruptivo cambiar (RAM y almacenamiento, donde una actualización implica downtime y una ventana de mantenimiento), y compra CPU más ajustada a la necesidad medida, ya que es el componente que menos se agota en la práctica. La regla de margen de 1.5–2× ya incorpora un año de crecimiento cómodo para una carga de trabajo típica; más allá de eso, valora con honestidad lo doloroso que sería una migración para este sistema. ¿Nivel sin estado? Barato de mover, compra ajustado. ¿Base de datos con estado? Caro de mover, compra holgado.

¿Cuándo necesito realmente un servidor dedicado en lugar de un VPS?

En cuanto se cumpla alguna de estas condiciones: carga sostenida de CPU o I/O que las plataformas compartidas limitan o cobran de forma punitiva; una necesidad de RAM (64 GB+) en la que el precio dedicado supera a niveles de VPS equivalentes; sensibilidad a la latencia que no tolera vecinos ruidosos; o la necesidad de control total del hardware: hipervisores, kernels personalizados, NVMe en crudo. Las cargas de trabajo irregulares y mayormente inactivas siguen siendo el terreno natural del VPS; las estables y sensibles al rendimiento cruzan la frontera sorprendentemente pronto. La sección sobre bare metal de nuestra guía de distribuciones profundiza en esta frontera.

Desplegar en Serverside

El método se traslada directamente a nuestro configurador de servidores dedicados: elige CPUs rápidas por núcleo o con muchos núcleos según la forma de tu carga de trabajo, dimensiona la RAM y el NVMe con la regla del margen, y observa la aritmética de capacidad utilizable del RAID aplicada en vivo mientras eliges los discos. Cada configuración se despliega en nuestra propia red con ASN 55285 (bien conectada, con mitigación DDoS permanente) y se aprovisiona en menos de un minuto, lo que además hace que la estrategia de «empezar de forma razonable y redimensionar redesplegando» sea realmente práctica.

Una vez pedido: la checklist de hardening de la primera hora, y si el plan incluye trocear el servidor en VMs, nuestras guías de Proxmox continúan desde ahí.