Que tamanho de pool de conexões em relação aos núcleos de CPU as equipes adotaram num servidor PostgreSQL, e qual medição as fez mudá-lo?

Pergunta em aberto

A documentação do PostgreSQL descreve max_connections como o número máximo de conexões simultâneas ao servidor, com um valor padrão que costuma ser 100. A página da wiki do PostgreSQL sobre o número de conexões com o banco de dados apresenta uma regra prática para obter a vazão ideal: o número de conexões ativas deve ficar próximo de duas vezes o número de núcleos mais o número efetivo de discos (spindles). A página argumenta ainda que mais conexões do que isso reduzem a vazão em vez de aumentá-la. Entre os dois pontos fica o pool: um pool dentro do processo de cada instância da aplicação, um pooler externo como o PgBouncer, ou ambos. O tamanho do pool é o número que as equipes de fato ajustam.

A wiki não tem registro do valor a que esse número chega depois de uma equipe ajustá-lo numa carga de trabalho real. As equipes acabam perto da fórmula, ou uma ordem de grandeza acima, porque cada uma das vinte instâncias da aplicação insiste em ter o seu próprio pool de dez conexões? Quando o pool foi reduzido, o que aconteceu com a latência na aplicação: as requisições ficaram em fila no pool e estouraram o tempo limite, ou o banco de dados ficou mais rápido porque menos transações competiam por locks e CPU? Quando foi aumentado, algo melhorou, ou a mudança apenas transferiu a espera do pool para o banco de dados? Qual medição foi decisiva: o tempo de espera no pool, os estados em pg_stat_activity, as esperas por locks, a saturação de CPU no host do banco de dados ou um percentil de latência na borda? E a resposta muda entre transações curtas de OLTP, consultas analíticas longas e cargas com sessões idle in transaction?

A pergunta importa porque a fórmula é muito citada e raramente verificada, e porque o tamanho do pool interage com o número de instâncias, a duração das transações e o modo do próprio pooler de maneiras que uma regra prática não consegue captar.

O que uma resposta útil contém

O número de núcleos e o armazenamento do host do banco de dados, o número de instâncias da aplicação, o pooler e o seu modo (session, transaction) e o perfil da carga de trabalho (distribuição da duração das transações, fração do tempo em idle in transaction). O tamanho do pool antes e depois de cada mudança, com a data. A medição que motivou a mudança e a medição que a avaliou: tempo de espera no pool e seus percentis, CPU do banco de dados, contagem de esperas por locks, percentis de latência das requisições, taxas de erro por esgotamento do pool. Se max_connections também foi alterado. Relatos em que a fórmula se confirmou, relatos em que ficou muito distante e relatos em que o tamanho do pool se mostrou menos importante do que a duração das transações são todos úteis, desde que os números venham acompanhados da fonte e do período observado.