Pico de tráfico: doscientos procesos PHP-FPM activos, cada uno abre una nueva conexión a la base de datos. PostgreSQL alcanza su límite de cien conexiones: demasiadas conexiones. Pánico: elevamos el límite a quinientos. La memoria de la base de datos explota, el sistema cambia al disco y el rendimiento empeora.
Llega PgBouncer: doscientos clientes de aplicaciones, treinta conexiones PostgreSQL reales. La crisis parecía resuelta, hasta que treinta solicitudes lentas simultáneas bloquearon todo el grupo durante treinta segundos. La solicitud caduca en masa. El grupo ha ocultado el límite de conexión, no la capacidad de procesamiento concurrente de la base de datos.
La agrupación de conexiones resuelve el costo abierto. No resuelve escaneos completos de tablas. Mal ajustado, añade una cola invisible frente a una base ya asfixiada.
Dónde colocar la piscina en la pila
Dependiendo de su entorno, la herramienta cambia; el principio sigue siendo el mismo: una capa entre los procesos de solicitud y la base.
| Pila | Herramienta común |
|---|---|
| PHP/Python/Nodo → PostgreSQL | PgBouncer por delante de PostgreSQL |
| MySQL | ProxySQL, MariaDB MaxScale o grupo de aplicaciones |
| Funciones sin servidor | Agrupador obligatorio (proxy administrado) |
| PHP sin agrupador | Conexiones persistentes: riesgo de conexiones zombis |
Arquitectura típica:
[PHP-FPM × N] → [PgBouncer:6432] → [PostgreSQL:5432]
No haga un doble pool de la aplicación y PgBouncer sin comprender la cadena: los pools anidados crean latencia y interbloqueos.
Dimensionamiento: empezar desde la base, no desde la aplicación
Para PostgreSQL, la cantidad óptima de conexiones activas se mide bajo carga real, no en una hoja de cálculo teórica. En la práctica, un default_pool_size entre veinte y cincuenta suele ser suficiente para una PYME; max_client_conn debe cubrir la suma de los procesos de la aplicación.
| Síntoma | Causa probable |
|---|---|
| Tiempo de espera del grupo de archivos | Grupo demasiado pequeño o consultas demasiado largas |
| Procesador base bajo, tiempos de espera de aplicaciones | Consultas bloqueadas por candados |
| “Demasiadas conexiones” | Bypass de piscina o mala configuración |
Modo de transacción: ventajas y desventajas
La agrupación de transacciones recicla la conexión PostgreSQL después de la validación. No utilice este modo con consultas preparadas vinculadas a una sesión, variables de sesión persistentes o funciones como escucha y notificación. El modo de sesión es más seguro para migrar; modo de transacción después de auditar su capa de acceso a datos.
En el alojamiento compartido MySQL, las conexiones suelen estar limitadas a diez o treinta: un grupo de aplicaciones es obligatorio. En PostgreSQL administrado, a veces se incluye un pooler: verifique los límites de su oferta y mida la cola antes de ampliar el hardware.
En la práctica, la mayoría de los incidentes del "grupo" desaparecen después de la optimización de consultas lentas: índices faltantes, uniones sin filtrar, transacciones demasiado largas. La piscina se convierte entonces en un útil amortiguador en lugar de un techo de cristal.
La cumbre: la piscina cambia la saturación
Orden de corrección: consultas lentas → grupo → escala base. Invertir el orden significa pagar cola y hardware adicionales por el mismo resultado.
Decide y avanza sin puntos ciegos
Mida la cantidad de conexiones PostgreSQL o MySQL en el pico actual antes de cualquier cambio. Implemente PgBouncer o ProxySQL si los procesos de su aplicación exceden significativamente un max_connections seguro. Establezca pool_size según la capacidad real de la base de datos, no la cantidad de trabajadores. Monitorear los clientes en espera y el tiempo promedio de espera. Analice las consultas más pesadas en paralelo: consulte EXPLICAR PostgreSQL y Saturación PHP-FPM.
Preguntas frecuentes
¿Por qué agrupar PostgreSQL?
Cada conexión consume memoria; el grupo multiplexa cientos de procesos de aplicaciones en menos conexiones de servidor.
¿Sesión versus modo de transacción PgBouncer?
El modo de transacción es más eficiente; El modo de sesión sigue siendo más compatible con las herramientas de mapeo relacional de objetos.
¿Cómo dimensionar el tamaño del grupo?
Comience desde la capacidad del procesador base, mida bajo carga real, no la cantidad de trabajadores de la aplicación.
¿El grupo anula el índice SQL?
No, las consultas lentas siguen siendo lentas una vez conectadas. Optimice las consultas primero.
El grupo de conexiones se encarga de la apertura, no de la consulta que bloquea la base de datos una vez conectada.