Conceptos básicos de pooling

Cada backend de PostgreSQL es un proceso con sobrecarga de memoria. Aumentar max_connections sin pooling incrementa el cambio de contexto y la rotación de caché; PgBouncer multiplexa clientes a menos backends de servidor en PostgreSQL 18.4.

Receta

Tarjeta de referencia rápida - lista para copiar y pegar.

SHOW max_connections;
SELECT count(*) AS active_backends FROM pg_stat_activity WHERE backend_type = 'client backend';
 
-- heurística de dimensionamiento (OLTP): pool_size ~= (núcleos de CPU * 2) + effective_spindle_count
-- validar con latencia p95, no con el número de instancias de aplicación

Cuándo recurrir a esto: El número de conexiones se acerca a max_connections, o la CPU está inactiva mientras las consultas se ponen en cola en la espera del pool.

Ejemplo de trabajo

SELECT
  setting::int AS max_connections,
  (SELECT count(*) FROM pg_stat_activity WHERE backend_type = 'client backend') AS current,
  setting::int - (SELECT count(*) FROM pg_stat_activity WHERE backend_type = 'client backend') AS headroom
FROM pg_settings
WHERE name = 'max_connections';
 
SELECT state, count(*)
FROM pg_stat_activity
WHERE backend_type = 'client backend'
GROUP BY state
ORDER BY count DESC;

Emparejar con SHOW POOLS de PgBouncer (consola de administración) para ver cl_active, cl_waiting y sv_active.

Lo que esto demuestra:

• Espacio libre de conexiones del servidor frente a conexiones de la aplicación
• Desglose de backends inactivos frente a activos
• Por qué el tiempo de espera del pool es más importante que el número bruto de conexiones

Análisis en profundidad

Cómo funciona

• Los servidores de aplicaciones abren muchas conexiones TCP; el pooler reutiliza menos backends de PostgreSQL.
• Cada backend asigna work_mem potencial por consulta y cachés privados.
• El cambio de contexto aumenta cuando cientos de backends compiten por la CPU.
• El pool se sitúa entre las aplicaciones y Postgres: aplicaciones -> PgBouncer -> PostgreSQL.

Señales de dimensionamiento

Notas SQL

SELECT usename, application_name, state, wait_event_type, query_start
FROM pg_stat_activity
WHERE backend_type = 'client backend'
ORDER BY query_start NULLS LAST
LIMIT 20;

Trampas

• max_connections = instancias de aplicación * tamaño del pool - Agota la RAM y la CPU. Solución: Pool centralizado; dimensionar el pool del servidor a partir de los núcleos.
• Sin pooler para ráfagas sin servidor - Cada lambda abre conexiones. Solución: Pool externo (RDS Proxy, PgBouncer, Supavisor).
• Ignorar idle in transaction - Mantiene la conexión del servidor del pool. Solución: idle_in_transaction_session_timeout.
• Un pool gigante para batch y OLTP - Los escaneos de BI dejan sin recursos a las consultas cortas. Solución: Pools y roles separados.
• Aumentar max_connections en lugar de usar pooling - Crecimiento lineal de la memoria. Solución: Usar pooling primero, escalar conexiones modestamente.

Alternativas

Preguntas frecuentes

Relacionado

• Modos de PgBouncer - Semántica de pooling
• Mejores prácticas de pooling - Lista de verificación de dimensionamiento
• Matemáticas de conexiones - Fórmulas de capacidad
• Rol y tiempo de espera por pool - Separación de cargas de trabajo

Versiones de la pila: Esta página se escribió para PostgreSQL 18.4 (estable 18, mantenimiento 17), pgvector 0.8+, PgBouncer 1.x, Patroni 3.x y PostGIS 3.5+.