Como calcular max_connections para PostgreSQL e default_pool_size para pgbouncer?

Existe uma regra ou algo que eu possa usar para calcular um número bom para max_connections, default_pool_sizee max_client_conn?

Os padrões são ímpares. O PostgreSQL assume como padrão max_connections = 100, enquanto o pgbouncer assume como default_pool_size = 20. Default_pool_size não deve sempre ser maior que max_connections? Caso contrário, qual é o objetivo? Eu pensei que o pgbouncer deveria nos permitir lidar com mais conexões diminuindo a sobrecarga (reutilizando as conexões do PostgreSQL). Estou confuso.

Estou procurando conselhos semelhantes aos encontrados no wiki do PostgreSQL , como "este parâmetro deve ser ~ 50% da sua memória".

Lembro que havia uma planilha para o MySQL que permitia calcular esse tipo de parâmetro. Seria incrível ter algo assim para o PostgreSQL / pgbouncer.

Primeiro, leia nossa pergunta canônica sobre Planejamento de Capacidade .
^{_{O conselho específico que você está solicitando é o planejamento de capacidade, e você terá que resolver isso sozinho, para o seu ambiente específico.}}

Segundo, você está vendo isso errado.
A quantidade de memória (ou qualquer outro recurso) que você possui não determina o número de conexões definidas, o número de conexões necessárias determina o quão robusto um servidor você deve adquirir.
Os requisitos de recursos por conexão são fornecidos no manual em detalhes consideráveis, bem como discutidos no Wiki ao qual você vinculou. Descubra o que o seu ambiente precisa (ou faça um palpite) e garanta que o hardware no qual você vai executar possa lidar com o que você vai jogar nele.

Especificamente quanto aos limites de conexão e tamanho do pool, você deve ter conexões "suficientes" para atender aos requisitos do seu aplicativo - em um único servidor ou por meio de um pool / segurança.

"Chega" é um número relativo: um aplicativo que faz (e reutiliza continuamente) uma conexão requer apenas uma conexão. Um aplicativo que estabelece uma conexão para cada usuário final que efetua login requer quantas conexões de banco de dados tiver usuários.

Os valores padrão para o Postgres e pgbouncersão sensíveis aos padrões :

• 100 conexões de banco de dados é muito para a pessoa típica que está lançando o Postgres em um ambiente.
  Os desenvolvedores provavelmente não precisarão de mais de 10. Qualquer outra pessoa saberá o suficiente para aumentar o número.

• 20 conexões pgbouncerpor pool de banco de dados significa que você pode obter 4 pools apontando para um servidor e não sobrecarregar o limite de conexão padrão do Postgres.
  É possível ter vários recursos em pool pgbouncerapontando para um banco de dados back-end e você sempre deseja algumas conexões disponíveis nos seus servidores back-end.

Se os padrões não forem adequados para o seu ambiente, você deverá alterá-los.

Lembre-se de que conexões agrupadas não significam "sempre amarre todas as conexões de banco de dados disponíveis".
O ponto de pgbouncercomo você observou é reutilizar conexões. O ganho de eficiência aqui não exige que você vincule todas as conexões disponíveis, apenas que você não desconecte, reconecte, renegocie o SSL, autentique novamente no banco de dados e execute novamente as consultas de configuração de conexão todas as vezes.

Observe a definição da documentação dedefault_pool_size

Quantas conexões de servidor permitem por par de usuário / banco de dados.

Portanto, se a configuração padrão for um tamanho de pool de 20, de um total de 100 conexões, isso implica que 5 pares de usuário / banco de dados distintos terão que maximizar cada tamanho de pool antes de atingirem o limite geral. Por outro lado, se, por exemplo, você estiver usando o pgbouncer para rotear para um único banco de dados por meio de um único usuário, seu limite de conexão efetivo é 20, e não 100, portanto, você deve definir o tamanho do pool para esse caso de uso de acordo. YMMV.