Comment calculer max_connections pour PostgreSQL et default_pool_size pour pgbouncer?

Y a-t-il une règle ou quelque chose que je peux utiliser pour calculer un bon nombre max_connections, default_pool_sizeet max_client_conn?

Les valeurs par défaut sont étranges. PostgreSQL par défaut à max_connections = 100 tandis que pgbouncer par défaut à default_pool_size = 20. Default_pool_size ne devrait-il pas toujours être supérieur à max_connections? Sinon, à quoi ça sert? Je pensais que pgbouncer était destiné à nous permettre de gérer plus de connexions en réduisant leur surcharge (en réutilisant les connexions de PostgreSQL). Je suis confus.

Je cherche des conseils similaires à ceux trouvés sur le wiki de PostgreSQL , comme "ce paramètre devrait représenter environ 50% de votre mémoire".

Je me souviens qu'il y avait une feuille de calcul pour MySQL qui vous permettrait de calculer ce genre de paramètres. Ce serait génial d'avoir quelque chose comme ça pour PostgreSQL / pgbouncer.

Tout d'abord, veuillez lire notre question canonique sur la planification des capacités .
^{_{Le conseil spécifique que vous demandez est un conseil en matière de planification des capacités, et vous devrez le faire vous-même, pour votre environnement particulier.}}

Deuxièmement, vous regardez mal.
La quantité de mémoire (ou de toute autre ressource) dont vous disposez ne dicte pas le nombre de connexions que vous définissez, le nombre de connexions dont vous avez besoin détermine la puissance d'un serveur que vous devez acheter.
Les besoins en ressources par connexion sont donnés dans le manuel de manière très détaillée, ainsi que discutés sur le Wiki auquel vous vous êtes connecté. Déterminez ce dont votre environnement a besoin (ou faites une supposition éclairée) et assurez-vous que le matériel sur lequel vous allez exécuter peut gérer ce que vous allez lui lancer.

Plus précisément, concernant les limites de connexion et la taille du pool, vous devez disposer de «suffisamment» de connexions pour répondre aux exigences de votre application - soit sur un seul serveur, soit via un pool / videur.

"Assez" est un nombre relatif: une application qui établit (et réutilise continuellement) une connexion ne nécessite qu'une seule connexion. Une application qui établit une connexion pour chaque utilisateur final qui se connecte requiert autant de connexions de base de données qu'elle a d'utilisateurs.

Les valeurs par défaut pour Postgres et pgbouncersont valables comme valeurs par défaut :

• 100 connexions de base de données, c'est beaucoup pour la personne typique qui lance Postgres dans un environnement.
  Les développeurs n'auront probablement pas besoin de plus de 10. Tout le monde en saura assez pour augmenter le nombre.

• 20 connexions pgbouncerpar pool de bases de données signifient que vous pouvez obtenir 4 pools pointant vers un serveur et ne pas dépasser la limite de connexion Postgres par défaut.
  Il est possible d'avoir plusieurs ressources regroupées en pgbouncerpointant vers une base de données principale, et vous voulez toujours des connexions disponibles sur vos serveurs principaux.

Si les valeurs par défaut ne conviennent pas à votre environnement, vous devez les modifier.

N'oubliez pas que les connexions groupées ne signifient pas «toujours bloquer toutes les connexions de base de données disponibles».
Le point pgbouncerque vous avez noté est de réutiliser les connexions. Le gain d'efficacité ici ne nécessite pas de bloquer toutes les connexions disponibles, mais simplement de ne pas déconnecter, reconnecter, renégocier SSL, réauthentifier auprès de la base de données et réexécuter vos requêtes de configuration de connexion à chaque fois.

Notez la définition de la documentation dedefault_pool_size

Combien de connexions serveur autoriser par paire utilisateur / base de données.

Donc, si la configuration par défaut est une taille de pool de 20, sur un total de 100 connexions, cela implique que 5 paires utilisateur / base de données distinctes devront chacune maximiser leur taille de pool avant d'atteindre la limite globale. Inversement, si par exemple vous utilisez pgbouncer pour router vers une seule base de données via un seul utilisateur, votre limite de connexion effective est de 20, et non de 100, vous devez donc définir la taille du pool pour ce cas d'utilisation en conséquence. YMMV.