Tabla de parámetros de instancia

Leer una clase de instancia como un conjunto de valores de parámetros

Una clase de instancia parece un dato de dos columnas — tantas vCPU, tanta memoria — pero en realidad es un conjunto de decisiones ya tomadas por ti. Solo la cifra de memoria fija el techo de conexiones, la caché de búferes y la visión del mundo del planificador. Esta tabla muestra cada instancia junto a los valores de parámetros que implica su memoria, para que puedas leer una clase como la configuración que de verdad es.

Cómo funciona

• Lista cada clase de instancia del catálogo de la nube que elijas, de menor a mayor.
• Muestra la memoria por vCPU, la forma más rápida de distinguir una clase de propósito general de una optimizada para memoria.
• Da max_connections por instancia, calculado con la regla publicada del proveedor y el motor seleccionado.
• Muestra shared_buffers o innodb_buffer_pool_size y effective_cache_size, deducidos de las expresiones por defecto de RDS.

columnas y de dónde sale cada una
  vCPU, memoria    la tabla de clases de instancia del proveedor
  GiB / vCPU       memoria dividida por vCPU
  max_connections  la regla publicada del proveedor para el motor elegido
  shared_buffers        25% de la memoria  (PostgreSQL)
  innodb_buffer_pool    75% de la memoria  (MySQL)
  effective_cache_size  75% de la memoria  (pista para el planificador)

Ejemplo resuelto

Una clase de instancia, db.m5.2xlarge con 8 vCPU y 32 GiB, leída en ambos motores.

1. memoria por vCPU = 32 ÷ 8 = 4 GiB, la proporción de propósito general
2. PostgreSQL: unas 3.324 conexiones, shared_buffers 8 GiB, effective_cache_size 24 GiB
3. MySQL: unas 2.518 conexiones, innodb_buffer_pool_size 24 GiB
4. el mismo hardware, dos motores, y la asignación de búfer difiere en un factor de tres

PostgreSQL se queda el 25% y deja el resto a la caché del sistema operativo; MySQL reclama el 75% para InnoDB porque no se apoya en esa caché. Ninguna de las dos es una decisión de ajuste que tomes a la ligera: ambas son consecuencia de elegir la clase, y son la razón de que la misma instancia se comporte distinto según el motor.

Cómo leer el resultado

• La memoria por vCPU dice para qué sirve una clase. Alrededor de 2 GiB por vCPU es orientado a cómputo, 4 GiB es propósito general, 8 GiB o más es optimizado para memoria: las clases r de AWS, la serie E de Azure. Para una base de datos las proporciones altas suelen ser mejor negocio, porque la memoria compra a la vez caché y margen de conexiones.
• El B1ms de Azure es la única fila que no sigue su propio patrón: 50 conexiones donde la regla por GiB predeciría muchas más. Esta tabla reproduce los valores publicados de Azure en lugar de ajustarles una curva, así que esa anomalía sobrevive en vez de quedar suavizada.
• La clase t de AWS y la serie B de Azure son burstable. Acumulan créditos de CPU en reposo y estrangulan cuando se agotan, lo que las hace excelentes para desarrollo y malas para carga de producción constante: la tabla muestra su forma, no esa advertencia, así que tenla presente.
• Las entradas de Cloud SQL aquí son formas personalizadas comunes, no un catálogo exhaustivo, porque Cloud SQL permite pedir casi cualquier combinación de vCPU y memoria. Toma esa columna como representativa.
• Estos valores son los que trae una instancia por defecto, no límites. Las tres nubes permiten sobrescribirlos mediante un grupo de parámetros o una marca, y las fórmulas de conexiones en particular son solo valores por defecto: consulta la calculadora de conexiones máximas para ver qué cuesta cambiarlos.

Preguntas frecuentes

¿Por qué cambia max_connections al cambiar de motor?

Porque cada motor tiene su propio divisor en la fórmula del proveedor. En AWS, PostgreSQL divide la memoria disponible entre unos 9,5 MB por conexión mientras MySQL divide entre unos 12,6 MB, así que la misma instancia rinde menos conexiones de MySQL. MariaDB desde la 10.5 usa otro divisor distinto.

¿Más memoria por vCPU es siempre mejor para una base de datos?

Normalmente sí, hasta el punto en que el conjunto de trabajo cabe en memoria. Una vez cacheados los datos que tocan las consultas, añadir memoria deja de comprar velocidad y solo compra margen de conexiones. Si tu conjunto es pequeño y tus consultas cargan la CPU — mucha ordenación, agregación o procesado de JSON — una proporción menor con más núcleos puede ser la mejor instancia.

¿Puedo cambiar estos valores después de lanzar?

Sí, mediante un grupo de parámetros en RDS, parámetros de servidor en Azure o marcas de base de datos en Cloud SQL. Algunos surten efecto de inmediato y otros exigen reinicio: shared_buffers e innodb_buffer_pool_size se reservan al arrancar, así que están en el segundo grupo. Los valores por defecto que se muestran aquí son buenos puntos de partida y merecen una razón antes de sobrescribirlos.

Fuentes

• Amazon RDS — clases de instancia de base de datos
• Azure Database for PostgreSQL — límites
• Cloud SQL para PostgreSQL — marcas