O PgBouncer recebe as conexões da aplicação e, no modo transação, as atende com poucas conexões reais no PostgreSQL.
- Compensa quando a maioria das conexões fica parada.
- O modo transação economiza mais, mas não funciona com SET, LISTEN nem PREPARE em SQL.
- O SHOW POOLS mostra se tem cliente esperando.
O PostgreSQL cria um processo para cada conexão, e cada um ocupa memória mesmo parado. Com o pool de cada instância e os workers, o total pode chegar a centenas.
Quando o PgBouncer compensa
Na view pg_stat_activity, compare as conexões idle com as active no pico. Se as paradas são maioria e o total encosta no max_connections, o PgBouncer compensa. Com um processo só e um pool pequeno, ele é só mais uma peça para manter.
Qual modo usar
No modo session, o padrão, a conexão real fica com o cliente até ele desconectar, e quase nada muda para quem mantém conexões abertas. No modo transaction, ela volta ao pool no fim de cada transação, e poucas dezenas de conexões reais podem atender centenas de clientes.
Em troca, esse modo não funciona com SET, LISTEN, PREPARE em SQL, cursores WITH HOLD nem advisory locks de sessão. Prepared statements do driver funcionam a partir da versão 1.21, com max_prepared_statements acima de zero.
Configuração de partida
[databases]
app = host=127.0.0.1 port=5432 dbname=app
[pgbouncer]
listen_addr = 10.0.0.5
listen_port = 6432
auth_type = scram-sha-256
auth_file = /etc/pgbouncer/userlist.txt
pool_mode = transaction
max_client_conn = 500
default_pool_size = 20Troque o listen_addr pelo IP da rede interna e aponte a aplicação para a porta 6432. O max_client_conn é a soma dos pools da aplicação e dos workers, com folga, e o default_pool_size limita as conexões reais por usuário e banco. O userlist.txt leva o hash SCRAM de cada usuário, tirado da pg_authid. O resto está na referência de configuração.
Como medir o tamanho do pool
Rode SHOW POOLS; no banco especial pgbouncer, com um usuário de stats_users. A coluna cl_waiting conta os clientes esperando conexão real, e maxwait, há quantos segundos o primeiro da fila espera.
Se a fila aparece nos picos, procure consultas lentas no pg_stat_statements, que o guia do primeiro dia manda ligar: elas prendem as conexões. Depois, suba o default_pool_size aos poucos. Se o banco fica lento quando o pool cresce, o limite é a máquina: veja quando separar banco, API e workers.
