¿Cómo calcular max_connections para PostgreSQL y default_pool_size para pgbouncer?

¿Hay una regla o algo que pueda usar para calcular un número bueno para max_connections, default_pool_sizey max_client_conn?

Los valores predeterminados son impares. PostgreSQL tiene como valor predeterminado max_connections = 100, mientras que pgbouncer tiene como valor predeterminado default_pool_size = 20. ¿No debería default_pool_size ser siempre superior a max_ connections? De lo contrario, ¿cuál es el punto? Pensé que pgbouncer estaba destinado a permitirnos manejar más conexiones al reducir su sobrecarga (reutilizando las conexiones de PostgreSQL). Estoy confundido.

Estoy buscando consejos similares a los que se encuentran en el wiki de PostgreSQL , como "este parámetro debería ser ~ 50% de su memoria".

Recuerdo que había una hoja de cálculo para MySQL que le permitiría calcular este tipo de parámetros. Sería increíble tener algo así para PostgreSQL / pgbouncer.

Primero, lea nuestra pregunta canónica sobre Planificación de capacidad .
^{_{El consejo específico que está solicitando es un consejo de planificación de capacidad, y tendrá que resolverlo por su cuenta, para su entorno particular.}}

En segundo lugar, estás mirando esto mal.
La cantidad de memoria (o cualquier otro recurso) que tenga no dicta la cantidad de conexiones que establece, la cantidad de conexiones que necesita determina qué tan robusto debe comprar un servidor.
Los requisitos de recursos por conexión se dan en el manual con considerable detalle, así como se discuten en el Wiki al que se vinculó. Averigüe qué necesita su entorno (o haga una suposición bien informada) y asegúrese de que el hardware con el que va a ejecutar pueda manejar lo que le va a lanzar.

Específicamente con respecto a los límites de conexión y el tamaño del grupo, debe tener conexiones "suficientes" para cumplir con los requisitos de su aplicación, ya sea en un solo servidor o mediante un grupo / gorila.

"Suficiente" es un número relativo: una aplicación que realiza (y reutiliza continuamente) una conexión solo requiere una conexión. Una aplicación que establece una conexión para cada usuario final que inicia sesión requiere tantas conexiones de base de datos como usuarios.

Los valores predeterminados para ambos Postgres y pgbouncerson sensibles como predeterminados :

• 100 conexiones de base de datos es mucho para la persona típica que lanza Postgres a un entorno.
  Los desarrolladores probablemente no necesitarán más de 10. Cualquier otra persona sabrá lo suficiente como para aumentar el número.

• 20 conexiones pgbouncerpor grupo de base de datos significa que puede obtener 4 grupos apuntando a un servidor y no abrumar el límite de conexión predeterminado de Postgres.
  Es posible tener múltiples recursos agrupados pgbouncerapuntando a una base de datos de fondo, y siempre desea tener algunas conexiones disponibles en sus servidores de fondo.

Si los valores predeterminados no son adecuados para su entorno, se espera que los cambie.

Recuerde que las conexiones agrupadas no significan "atar siempre cada conexión de base de datos disponible".
El punto de pgbouncerlo que notó es reutilizar las conexiones. La ganancia de eficiencia aquí no requiere que conecte todas las conexiones disponibles, simplemente que no desconecte, vuelva a conectar, renegocie SSL, vuelva a autenticarse en la base de datos y vuelva a ejecutar sus consultas de configuración de conexión cada vez.

Observe la definición de la documentación dedefault_pool_size

Cuántas conexiones de servidor permitir por par de usuario / base de datos.

Entonces, si la configuración predeterminada es un tamaño de grupo de 20, de un total de 100 conexiones, esto implica que 5 pares distintos de usuarios / bases de datos tendrán que maximizar el tamaño de su grupo antes de alcanzar el límite general. Por el contrario, si, por ejemplo, está usando pgbouncer para enrutar a una única base de datos a través de un solo usuario, su límite de conexión efectivo es 20, no 100, por lo que debe establecer el tamaño del grupo para ese caso de uso en consecuencia. YMMV.