Quelle taille de pool de connexions par rapport au nombre de cœurs les équipes ont-elles retenue pour un serveur PostgreSQL, et quelle mesure les a poussées à la changer ?

Question ouverte

La documentation de PostgreSQL décrit max_connections comme le nombre maximal de connexions concurrentes au serveur, avec une valeur par défaut typiquement fixée à 100. La page du wiki PostgreSQL sur le nombre de connexions à la base de données donne une règle empirique pour un débit optimal, qui place le nombre de connexions actives près du double du nombre de cœurs plus le nombre effectif de disques, et affirme qu'au-delà de ce nombre, davantage de connexions réduisent le débit au lieu de l'augmenter. Entre les deux se trouve le pool : un pool intra-processus par instance d'application, un pooler externe tel que PgBouncer, ou les deux, et la taille du pool est le paramètre que les équipes ajustent effectivement.

Le wiki ne conserve aucune trace de ce que devient ce nombre une fois qu'une équipe l'a réglé sur une charge réelle. Les équipes se rapprochent-elles de la formule, ou en sont-elles à un ordre de grandeur au-dessus parce que chacune des vingt instances d'application insiste pour avoir son propre pool de dix ? Lorsque le pool a été réduit, qu'est-il arrivé à la latence côté application : les requêtes se sont-elles mises en file d'attente au niveau du pool jusqu'au dépassement de délai, ou la base de données est-elle devenue plus rapide parce que moins de transactions se disputaient les verrous et le CPU ? Lorsqu'il a été agrandi, quelque chose s'est-il amélioré, ou le changement a-t-il seulement déplacé l'attente du pool vers la base de données ? Quelle mesure a été déterminante : le temps d'attente au pool, les états de pg_stat_activity, les attentes de verrous, la saturation du CPU sur l'hôte de la base de données, ou un percentile de latence en bordure ? Et la réponse diffère-t-elle entre de courtes transactions OLTP, de longues requêtes analytiques et des charges comportant des sessions inactives en transaction (idle-in-transaction) ?

La question importe parce que la formule est largement citée et rarement vérifiée, et parce que la taille du pool interagit avec le nombre d'instances, la durée des transactions et le mode propre du pooler de façons qu'une règle empirique ne peut pas saisir.

Ce qu'une réponse utile contient

Le nombre de cœurs et le stockage de l'hôte de base de données, le nombre d'instances d'application, le pooler et son mode (session, transaction), ainsi que la nature de la charge (distribution de la durée des transactions, part du temps passé en idle-in-transaction). La taille du pool avant et après chaque changement, avec la date. La mesure qui a déclenché le changement et celle qui l'a évalué : temps d'attente au pool et ses percentiles, CPU de la base de données, nombre d'attentes de verrous, percentiles de latence des requêtes, taux d'erreur dus à l'épuisement du pool. Si max_connections a également été modifié. Les rapports où la formule s'est vérifiée, ceux où elle était très éloignée, et ceux où la taille du pool s'est révélée compter moins que la durée des transactions sont tous utiles, à condition que les chiffres soient présentés avec leur source et la période observée.