Si usas PgBouncer delante de PostgreSQL (y más aún si usas Odoo), SHOW POOLS; es el comando que te responde en 10 segundos:
¿hay cola?
¿cuántas conexiones reales están ocupadas?
¿estoy limitado por pool_size o por una DB lenta/lockeada?
¿qué pool exacto (db/user) está sufriendo?
PgBouncer lo define así: se crea una entrada de pool por cada par (database, user). PgBouncer
1) Cómo acceder (por si te falta el “contexto admin”)
Te conectas a la “base virtual” pgbouncer y ahí ejecutas los SHOW .... PgBouncer+1
psql "host=PGBOUNCER_HOST port=6432 dbname=pgbouncer user=tu_admin"
2) Ejemplo típico de salida
pgbouncer=# SHOW POOLS; database | user | cl_active | cl_waiting | sv_active | sv_idle | sv_used | sv_tested | sv_login | maxwait | pool_mode ---------+--------+-----------+------------+----------+---------+---------+----------+---------+---------+---------- odoo | odoo | 35 | 4 | 30 | 10 | 0 | 0 | 0 | 2 | transaction
Cada fila es un pool (una combinación database + user). PgBouncer
3) Qué significa cada columna (en cristiano)
Identidad del pool
database: nombre de la base (o entrada de [databases]). PgBouncer
user: usuario que se conecta. PgBouncer
Si tienes multi-tenant (varias DBs) o varios usuarios, vas a ver muchas filas.
4) Lado cliente (Odoo/tu app → PgBouncer)
cl_active
Clientes activos o “OK”: o bien están enlazados a un server, o están idle sin queries esperando. PgBouncer
Lectura práctica: esto no significa “están ejecutando SQL ahora mismo”; significa “no están esperando conexión”.
cl_waiting
Clientes que ya enviaron queries pero todavía no recibieron una conexión server. PgBouncer
Este es el número que más te importa. GitLab lo resume perfecto: cl_waiting indica clientes intentando ejecutar una transacción pero PgBouncer no pudo asignarles un server connection inmediatamente. Runbooks
cl_active_cancel_req / cl_waiting_cancel_req
Son clientes relacionados con cancelaciones de query:
cl_active_cancel_req: ya mandaron cancel al server y esperan respuesta. PgBouncer
cl_waiting_cancel_req: aún no pudieron reenviar el cancel. PgBouncer
Si ves números aquí de forma sostenida, suele ser señal de:
timeouts,
queries colgadas,
usuarios cancelando mucho,
o backend saturado.
5) Lado servidor (PgBouncer → PostgreSQL)
sv_active
Conexiones a PostgreSQL enlazadas a un cliente (o sea: realmente en uso). PgBouncer
sv_idle
Conexiones libres y reutilizables ya (listas para asignar). PgBouncer
Si tienes cl_waiting > 0 y sv_idle es 0, normalmente estás “seco” de conexiones libres.
sv_used
Conexiones que estaban idle “demasiado tiempo” y ahora requieren correr server_check_query antes de reutilizarse (depende de server_check_delay). PgBouncer
sv_tested
Conexiones ejecutando server_reset_query o server_check_query. PgBouncer
Lectura práctica: si se dispara mucho, revisa tus valores de reset/check y si hay churn de conexiones.
sv_login
Conexiones “en proceso de logueo” (abriéndose). PgBouncer
Lectura práctica: si sv_login sube en picos, puede ser:
latencia de red hacia Postgres,
Postgres lento en auth,
o pool creciendo y tardando en abrir conexiones.
6) La métrica de “cola real” (la que se entiende sola)
maxwait (+ maxwait_us)
Cuánto esperó (en segundos) el cliente más antiguo en la cola. PgBouncer
PgBouncer lo dice explícito: si maxwait empieza a subir, el pool actual no está procesando requests lo suficientemente rápido, ya sea por servidor sobrecargado o por pool_size demasiado chico. PgBouncer
7) pool_mode (por qué cambia la lectura)
pool_mode te muestra el modo efectivo del pool. PgBouncer
En Odoo normalmente usas transaction, donde la conexión server se asigna solo durante la transacción y se devuelve al pool cuando termina. PgBouncer
Esto importa porque con transacciones largas:
las conexiones quedan “secuestradas”
sube cl_waiting
sube maxwait
aunque la CPU no esté al 100%.
8) Patrones típicos (cómo interpretar sin adivinar)
Patrón A — Pool chico (o picos): “cola pero DB ok”
cl_waiting > 0
sv_active cerca del límite
sv_idle ~ 0
Postgres no está saturado
➡️ Acción: subir pool_size/default_pool_size o usar reserve_pool_size para burst (y validar con métricas).
Patrón B — Transacciones largas / locks: “cola aunque no hay tanta CPU”
cl_waiting sube
sv_active estable pero “pegado”
maxwait sube sostenido
GitLab menciona una causa típica: conexiones “hogged” por queries/transactions largas. Runbooks
➡️ Acción: mirar pg_stat_activity / locks; cortar transacciones largas; batch en crons; timeouts.
Patrón C — Backend caído o login lento
sv_login alto
errores de conexión backend
➡️ Acción: revisar red, Postgres, TLS, auth, DNS, etc.
9) Qué comandos correr justo después de SHOW POOLS;
1) Ver conexiones exactas “ocupando” backend
SHOW SERVERS;
2) Ver clientes que están esperando
SHOW CLIENTS;
Y en PostgreSQL:
SELECT pid, usename, state, xact_start, wait_event_type, wait_event, query FROM pg_stat_activity ORDER BY xact_start NULLS LAST;
Cierre
SHOW POOLS; no es “un numerito”: es el panel que te dice si estás:
limitado por el pool (config de PgBouncer),
limitado por la DB (queries/locks),
o limitado por transacciones largas (muy común con Odoo + crons).