Como calcular max_connections para PostgreSQL e default_pool_size para pgbouncer?

Question

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

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

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

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

    

Answer 1

First, please read our canonical question on Capacity Planning.
^{_{The specific advice you're asking for is capacity planning advice, and you're going to have to work that out on your own, for your particular environment.}}

Em segundo lugar, você está olhando para isto errado.
A quantidade de memória (ou qualquer outro recurso) que você tem não determina o número de conexões que você definiu, o número de conexões necessárias para determinar o quanto um servidor você deve comprar. Os requisitos de recursos por conexão são fornecidos em manual em detalhes consideráveis, como bem como discutido no Wiki que você vinculou. Descubra o que o seu ambiente precisa (ou faça um palpite) e garanta que o hardware em que você vai rodar possa lidar com o que você vai usar.

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

"Suficiente" é 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 tantas conexões de banco de dados quantas as de usuários.

Os valores padrão para o Postgres e o pgbouncer são sensatos como padrões :

• 100 conexões de banco de dados são muito para a pessoa comum jogando o Postgres em um ambiente.
  Os desenvolvedores provavelmente não precisarão de mais de 10. Alguém mais saberá o suficiente para aumentar o número.

• 20 conexões de pgbouncer por pool de DB 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 em pgbouncer apontando para um banco de dados back-end, e você sempre deseja algumas conexões disponíveis em seus servidores back-end.

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

Lembre-se de que as conexões em pool não significam "sempre amarrar todas as conexões de banco de dados disponíveis". O ponto de pgbouncer , como você observou, é reutilizar as conexões. O ganho de eficiência aqui não exige que você amarre todas as conexões disponíveis, apenas que você não desconecte, reconecte, negocie novamente o SSL, se autentique novamente no banco de dados e execute novamente as consultas de configuração de conexão todas as vezes. / p>     

Answer 2

Repare a definição da documentação de default_pool_size

How many server connections to allow per user/database pair.

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