PgBouncer vs Pgpool-II

PostgreSQL no ofrece una solución built-in cuando necesitamos un pool que mejore el consumo y gestión de las conexiones, por eso es necesario el uso de otras soluciones.

TL;DR

Si su entorno necesita reducir la carga de la creación de conexiones y reutilizarlas cuando este inactivas las alternativas mas populares para hacer pooling son PgBouncer y Pgpool-II.

PgBouncer es ligero y puede ser configurado a tres niveles (sesión, transacción o sentencia). Ademas puede ser usado con varios clusters simultáneamente. Pgpool-II ademas de connection pooling este orientado a dotar de alta disponibilidad al entorno (replicación, balanceo de carga, gestión de exceso de conexiones.) Las 2 opciones son igual de validas para aumentar el numero de sesiones concurrentes a nuestro cluster.

– Elija PgBouncer cuando quiera aumentar el numero de conexiones y tenga pocos recursos de memoria.

– Elija Pgpool-II cuando ademas necesite añadir alta disponibilidad.

Porque añadir un pool a nuestro cluster

El numero de conexiones a nuestro cluster puede ser un cuello de botella importante cuando la arquitectura de nuestro servicio no se dimensiono correctamente o nuestra capa de aplicación hace un uso intensivo de SQL que no se habíamos previsto.

Un alto numero de conexiones (activas o inactivas) puedo provocar una escasez de memoria en el servidor limitados por los parametros work_mem y max_connections.

Si ademas el numero de conexiones concurrentes (activas en el mismo momento) es continuo su rendimiento esta limitado por el numero de sockets de nuestro servidor, es mas, el numero de sockets debe usarse para calcular el parámetro max_connections.

El uso de un pool de conexiones gestionado por el sysadmin de PostgreSQL es una solución limpia y rápida de implementar sin modificar nuestra aplicación, ademas , el ajuste fino del tamaño del pool suele ser mas acertado que si se realiza a nivel de aplicación (a no ser de que se tenga un APM potente que monitorize el servicio end-to-end).

las alternativas mas populares en la comunidad de PostgreSQL son PgBouncer y Pgpool-II. ambos son igual de validas para ser usadas como connection pool pero muy diferentes en las funcionalidades extras que ofrecen.

PgBouncer

Publico su primera release en Marzo de 2007 y a fecha de hoy va por su release 1.7. Es sencillo seguir la actividad del proyecto consultando su pagina de github.[https://pgbouncer.github.io/]

Existen repositorios disponibles para su instalación en casi todas las distribuciones de Linux (incluso existe versiones para Windows). Durante su configuración no olvide tener en cuenta:

– Las conexiones a PostgreSQL se configuran a nivel de base de datos (host/port/dbname).

– Es necesario crear (y mantener) el fichero users.txt con el listado de usuarios autorizados a conectar.

– Compruebe que su DNS funciona correctamente y es compatible.

– Existen 3 niveles de “pooling”.

– Sesión: a cada conexión se la asigna un proceso que se mantiene hasta que el cliente desconecta.

– Transacción: el proceso queda asignado al cliente hasta que finaliza la transacción.

– Sentencia: el mas agresivo, el proceso vuelve al pool al finalizar cada sentencia SQL (es necesario comprobar si su aplicación puede funcionar en esta modalidad).

Pgpool-II

Lanzado en 2003 este proyecto es liderado por Tatsuo Ishii, se mantiene en constante evolución y mejora (ver su changelog [https://git.postgresql.org/gitweb/?p=pgpool2.git;a=shortlog]). Aunque su puesta en marcha es bastante compleja dado al amplio numero de alternativas de configuración, puede ajustarse a cualquier entorno con PostgreSQL que necesita pooling y alta disponibilidad.

Si se quiere instalar a partir de repositorios, los mas actualizados y fiables son los de Centos/Redhat, para el resto, es recomendable compilarlos a partir de los fuentes.

No olvide los siguientes puntos:

– Asegúrese que entiende las distintos modos de configuración e invierta suficiente tiempo en planificar su entorno. La parametrización de Pgpool-II no es sencilla (stremming replication, replication, master/slave, raw, watchdog….).

– A diferencia de PgBouncer los clusters postgresql se añaden a nivel de servidor (backends) y la seguridad puede ser configurada en los ficheros pool_hba o pg_hba.

– El tamaño de los pool son parametrizados por 2 parametros num_init_children para el numero de procesos arrancados por pgpool y max_pool que controla en numero de conexiones a base de datos por cada “children”. Es fácil confundir ambos conceptos y que nuestro pool llegue al numero máximo de sesiones.

– A diferencia de PgBouncer, Pgpool-II se maneja a nivel de sentencia, esto puede no ser compatible con su aplicación si esta programa en sentencias multi linea (BEGIN…END;).

Otros consejos

Siempre es mejor idea instalar nuestro pool en un servidor diferente al de base de datos. Su administración sera mas sencilla, es mas fácil identificar las incidencias y la latencia entre pool y PostgreSQL no suele ser un problema.

Evite sorpresas y realice todas las pruebas posibles de su aplicación antes de lanzarse a instalar su pool en producción, poniendo especial interés en como se realiza la autorización y autenticacion de los clientes.

Deja un comentario

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *

Este sitio usa Akismet para reducir el spam. Aprende cómo se procesan los datos de tus comentarios.