Decisión: dimensionamiento del servidor
Un dimensionamiento correcto parte del perfil de carga (OLTP, data warehouse, mixto) y exige encontrar el verdadero cuello de botella (CPU, E/S o RAM). Regla de oro: el conjunto de datos de acceso frecuente (working set) debe caber en la RAM; mida primero, luego escale y deje margen para cargas repentinas. Este árbol le ayuda a identificar la carga y a elegir el recurso y la dirección de escalado (vertical/horizontal) según el cuello de botella.
¿Cuál es su perfil de carga?
El dimensionamiento empieza por la carga, porque las cargas OLTP y analíticas requieren perfiles de recursos completamente distintos. ¿Cuál es el trabajo predominante del sistema: muchas transacciones pequeñas y rápidas (OLTP), informes/analítica con grandes escaneos y agregaciones (DWH), o una mezcla de ambos? Si no está seguro, primero tiene que medir.
- OLTP: muchas transacciones pequeñas y cortas (web/aplicación)
- Analítica / data warehouse (DWH): grandes escaneos y agregaciones
- Carga mixta, o no estoy seguro
- Conozco el cuello de botella; ¿debo escalar vertical u horizontalmente?
¿Dónde está el cuello de botella: RAM, E/S o CPU?
En OLTP, busque el verdadero cuello de botella en lugar de añadir recursos a ciegas. Mire sus métricas: ¿los datos de acceso frecuente no caben en la RAM y hay muchas lecturas de disco (RAM/E/S), la latencia/IOPS del disco es insuficiente (E/S), o los datos ya están en memoria pero la CPU está saturada (CPU)? Escalar el recurso equivocado desperdicia dinero y tiempo.
- Los datos de acceso frecuente no caben en la RAM; las lecturas de disco son altas
- Los datos están en memoria, pero la latencia/IOPS del disco es insuficiente (escritura intensiva)
- Los datos están en memoria y el disco está bien, pero la CPU está saturada de forma constante
Recomendación: mida primero y luego dimensione
Comprar hardware a partir de suposiciones casi siempre produce un tamaño equivocado. El perfil de carga y el cuello de botella surgen de métricas reales. El dimensionamiento no es una suposición, sino una iteración guiada por mediciones.
Recomendación: añada RAM; el working set debe caber en memoria
La regla OLTP más crítica: los datos y los índices de acceso frecuente (el working set) deben caber en memoria (buffer/caché). Si no caben, cada consulta va al disco, la latencia se dispara y la E/S se convierte en el cuello de botella. La RAM suele ser la inversión de mayor retorno.
Recomendación: refuerce la capa de E/S (IOPS/latencia)
Aunque los datos estén en memoria, la velocidad del disco es decisiva con una carga de escritura intensiva (commit, WAL/redo/binlog, checkpoint). Aquí el problema no es la capacidad, sino las IOPS y la latencia. Una clase de disco equivocada pone el sistema de rodillas pese a tener CPU/RAM rápidas.
Recomendación: resuelva el cuello de botella de CPU (primero las consultas, luego los núcleos)
Si la CPU está saturada mientras los datos están en memoria y el disco está bien, la causa raíz suele ser consultas ineficientes (planes malos, índices ausentes, muchas consultas pequeñas) o una concurrencia excesiva. Reducir la carga antes de añadir núcleos suele ser más barato y eficaz.
Recomendación: analítica/DWH: throughput, paralelismo y escala horizontal
Una carga de data warehouse consiste en un pequeño número de consultas pesadas que recorren y agregan tablas grandes. Aquí la prioridad no es la baja latencia, sino un alto throughput de escaneo, el paralelismo y, por lo general, una arquitectura escalable horizontalmente.
Principio general: vertical vs horizontal + margen + medir primero
Cómo escala importa tanto como qué recurso escala. El escalado vertical (una máquina más grande) es sencillo, pero tiene un techo y un punto único de fallo; el horizontal (más máquinas) escala, pero añade complejidad. En todos los casos, deje margen para cargas repentinas y valide la decisión con mediciones.