Noções Básicas de Pooling

Cada backend do PostgreSQL é um processo com sobrecarga de memória. Aumentar max_connections sem pooling aumenta a troca de contexto e a degradação do cache; o PgBouncer multiplexa clientes para menos backends de servidor no PostgreSQL 18.4.

Receita

Cartão de receita de referência rápida - pronto para copiar e colar.

SHOW max_connections;
SELECT count(*) AS active_backends FROM pg_stat_activity WHERE backend_type = 'client backend';
 
-- heurística de dimensionamento (OLTP): pool_size ~= (núcleos de CPU * 2) + effective_spindle_count
-- validar com latência p95, não com contagem de instâncias de aplicativo

Quando usar isso: A contagem de conexões se aproxima de max_connections, ou a CPU está ociosa enquanto as consultas entram na fila de espera do pool.

Exemplo de Trabalho

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;

Combine com SHOW POOLS do PgBouncer (console de administração) para ver cl_active, cl_waiting e sv_active.

O que isso demonstra:

• Espaço livre de conexão do servidor vs. conexões do aplicativo
• Detalhamento de backends ociosos vs. ativos
• Por que o tempo de espera do pool é mais importante do que a contagem bruta de conexões

Mergulho Profundo

Como Funciona

• Servidores de aplicativos abrem muitas conexões TCP; o pooler reutiliza menos backends do PostgreSQL.
• Cada backend aloca potencial de work_mem por consulta e caches privados.
• A troca de contexto aumenta quando centenas de backends competem por CPU.
• O pool fica entre os aplicativos e o Postgres: aplicativos -> PgBouncer -> PostgreSQL.

Sinais de Dimensionamento

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;

Armadilhas

• max_connections = instâncias de aplicativo * tamanho do pool - Esgota RAM e CPU. Correção: Pooler centralizado; dimensionar o pool do servidor a partir dos núcleos.
• Sem pooler para explosão serverless - Cada lambda abre conexões. Correção: Pool externo (RDS Proxy, PgBouncer, Supavisor).
• Ignorar ociosidade em transação - Mantém a conexão do servidor fora do pool. Correção: idle_in_transaction_session_timeout.
• Um pool gigante para batch e OLTP - Varreduras de BI prejudicam consultas curtas. Correção: Pools e funções separadas.
• Aumentar max_connections em vez de pooling - Crescimento linear de memória. Correção: Use pool primeiro, escale as conexões modestamente.

Alternativas

FAQs

Relacionado

• Modos PgBouncer - Semântica de pooling
• Melhores Práticas de Pooling - Checklist de dimensionamento
• Matemática de Conexão - Fórmulas de capacidade
• Função e Tempo Limite por Pool - Separação de carga de trabalho

Versões da Pilha: Esta página foi escrita para PostgreSQL 18.4 (estável 18, manutenção 17), pgvector 0.8+, PgBouncer 1.x, Patroni 3.x e PostGIS 3.5+.