Calculadora de pool de conexiones

Dimensionar un pool de conexiones para el despliegue, no para la media

Los pools de conexiones rara vez fallan con carga estable. Fallan durante un despliegue, cuando los pods viejos aún no se han apagado y los nuevos ya han abierto sus pools, y la demanda se duplica brevemente. Esta herramienta multiplica lo que tu flota le pide realmente a la base de datos, en reposo y en ese momento, y compara ambas cifras con el límite que la instancia aplica.

Cómo funciona

• Multiplica las instancias de aplicación por el tamaño del pool: ese es el número que ve la base de datos, no el tamaño que configuraste.
• Resta las conexiones reservadas para replicación y monitorización, para que compares con lo realmente disponible.
• Duplica la demanda para modelar un despliegue progresivo, cuando instancias viejas y nuevas sostienen pools a la vez.
• Señala tres estados: por encima del límite, tan ajustado que un despliegue lo rompería, y holgado.

utilizables    = max_connections - reservadas
régimen_estable = instancias x pool_por_instancia
durante_despliegue = régimen_estable x 2

seguro cuando durante_despliegue <= utilizables

Ejemplo resuelto

Un servicio en 40 pods, cada uno con un pool de 20, frente a una instancia de 500 conexiones que reserva 15.

1. utilizables = 500 - 15 = 485
2. régimen estable = 40 x 20 = 800 — ya es el 165% del límite
3. margen = 485 - 800 = -315, así que ya se están rechazando conexiones
4. reducir el pool a la mitad, a 10: régimen estable = 400, o sea 82% — en reposo encaja
5. pero durante un despliegue: 400 x 2 = 800, sigue siendo 165%, así que los despliegues siguen rompiéndose
6. pool de 6: régimen estable = 240 (49%), despliegue = 480 frente a 485 — encaja por poco

El pool que sobrevive a un despliegue es un tercio del que solo sobrevive a la media. Entre el paso dos y el seis nada cambió en el tráfico: solo el ajuste del pool y la disposición a dimensionarlo para el peor momento en vez del habitual.

Cómo leer el resultado

• Un pool de 6 por pod suena pequeño, y no lo es. La propia guía de HikariCP sostiene que los pools pequeños rinden más que los grandes: a un pool le bastan las conexiones necesarias para mantener ocupados los núcleos de la base, y esperar un instante en la aplicación sale más barato que esperar dentro de la base. El objetivo son unas pocas conexiones por núcleo en toda la flota.
• Multiplica por cada proceso que abre un pool, no solo por la capa web. Los workers en segundo plano, las tareas programadas, las migraciones, las consolas de administración y tu propia sesión de psql beben del mismo techo, y son las conexiones que nadie cuenta hasta que el techo se alcanza.
• La duplicación que se asume aquí es el caso común de un despliegue progresivo con sonda de disponibilidad. Un despliegue que sustituye todo a la vez puede picar más alto; uno que sustituye un pod cada vez apenas pica. Ajusta el número de instancias si tu estrategia difiere.
• Las cargas serverless y con autoescalado rompen esta aritmética por completo, porque el número de instancias no lo decides tú. Ese es el caso que un proxy — RDS Proxy, PgBouncer, Cloud SQL Auth Proxy — resuelve de verdad, multiplexando muchas conexiones de cliente sobre pocas de base de datos.
• Las conexiones inactivas no son gratis. En PostgreSQL cada una es un proceso que retiene memoria; en MySQL cada una lleva búferes por hilo. Un pool generoso que pasa el rato inactivo te cuesta igualmente la memoria que reservó.

Preguntas frecuentes

¿Por qué duplicar la demanda para un despliegue?

Porque un despliegue progresivo se solapa a propósito. La instancia nueva debe arrancar, abrir su pool y pasar la sonda antes de que se drene la vieja, así que durante esa ventana ambas sostienen pools completos. Si tu plataforma sustituye las instancias de una en una el solape es menor, pero el modo de fallo es el mismo y conviene comprobarlo.

Mi pool está muy por debajo del límite y aun así veo errores de conexión. ¿Por qué?

Normalmente algo ajeno al pool. Busca workers, tareas programadas y scripts puntuales que abren sus propias conexiones, una migración corriendo durante el despliegue y conexiones filtradas por código que no las devuelve. El pool solo es la parte de la demanda que configuraste.

¿Un pool más grande es más rápido?

Pasado cierto punto, no: es más lento. Cuando todos los núcleos de la base están ocupados, más conexiones simultáneas añaden cambios de contexto y contención de bloqueos, no rendimiento. El efecto medible de un pool sobredimensionado suele ser peor latencia de cola, no mejor rendimiento.

¿Dónde encaja un pooler como PgBouncer?

Entre las dos cifras. Permite que un número grande y variable de conexiones de cliente comparta un número pequeño y fijo de conexiones de base de datos, justo lo que esta herramienta te muestra necesitando cuando las instancias son muchas o impredecibles. En modo de pooling por transacción además libera conexiones entre sentencias en vez de retenerlas toda la sesión.