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 pgbouncer
sont 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 pgbouncer
par 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 pgbouncer
pointant 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 pgbouncer
que 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.