Calculateur de pool de connexions

Dimensionner un pool de connexions pour le déploiement, pas pour la moyenne

Les pools de connexions cèdent rarement en charge stable. Ils cèdent pendant un déploiement, quand les anciens pods ne se sont pas encore arrêtés et que les nouveaux ont déjà ouvert leurs pools : la demande double brièvement. Cet outil calcule ce que votre flotte demande réellement à la base, au repos et à cet instant précis, et compare les deux à la limite appliquée par l'instance.

Comment ça marche

• Multiplie les instances d'application par la taille du pool : c'est le chiffre que voit la base, pas la taille que vous avez configurée.
• Retranche les connexions réservées à la réplication et à la supervision, pour comparer à ce qui est réellement disponible.
• Double la demande pour modéliser un déploiement progressif, quand anciennes et nouvelles instances détiennent des pools en même temps.
• Signale trois états : au-delà de la limite, assez juste pour qu'un déploiement la dépasse, et confortable.

utilisables    = max_connections - reservees
regime_stable  = instances x pool_par_instance
pendant_deploiement = regime_stable x 2

sur quand pendant_deploiement <= utilisables

Exemple chiffré

Un service sur 40 pods, chacun avec un pool de 20, face à une instance de 500 connexions dont 15 réservées.

1. utilisables = 500 - 15 = 485
2. régime stable = 40 x 20 = 800 — déjà 165% de la limite
3. marge = 485 - 800 = -315 : des connexions sont refusées dès maintenant
4. en divisant le pool par deux, à 10 : régime stable = 400, soit 82% — au repos, cela passe
5. mais pendant un déploiement : 400 x 2 = 800, toujours 165%, donc les déploiements échouent encore
6. pool de 6 : régime stable = 240 (49%), déploiement = 480 contre 485 — cela passe de justesse

Le pool qui survit à un déploiement fait le tiers de celui qui survit seulement à la moyenne. Rien du trafic n'a changé entre l'étape deux et l'étape six — seulement le réglage du pool, et la décision de le dimensionner pour le pire moment plutôt que pour le moment ordinaire.

Lire le résultat

• Un pool de 6 par pod semble petit, et ne l'est pas. La recommandation de HikariCP est que les petits pools l'emportent sur les grands : un pool n'a besoin que d'assez de connexions pour occuper les cœurs de la base, et attendre brièvement dans l'application coûte moins cher qu'attendre dans la base. Quelques connexions par cœur, à l'échelle de la flotte, est la cible.
• Comptez chaque processus qui ouvre un pool, pas seulement la couche web. Les workers, les tâches planifiées, les migrations, les consoles d'administration et votre propre session psql puisent au même plafond — ce sont les connexions que personne ne compte jusqu'à ce que le plafond soit atteint.
• Le doublement retenu ici correspond au cas courant d'un déploiement progressif avec sonde de disponibilité. Un déploiement qui remplace tout d'un coup peut dépasser ce pic ; un qui remplace un pod à la fois ne le crée presque pas. Ajustez le nombre d'instances si votre stratégie diffère.
• Les charges serverless et autoscalées brisent entièrement cette arithmétique, car le nombre d'instances vous échappe. C'est le cas qu'un proxy — RDS Proxy, PgBouncer, Cloud SQL Auth Proxy — résout vraiment, en multiplexant de nombreuses connexions clientes sur peu de connexions base.
• Les connexions inactives ne sont pas gratuites. Sous PostgreSQL chacune est un processus qui retient de la mémoire ; sous MySQL chacune porte des tampons par thread. Un pool généreux qui reste inactif vous coûte quand même la mémoire qu'il a réservée.

Questions fréquentes

Pourquoi doubler la demande pour un déploiement ?

Parce qu'un déploiement progressif se chevauche délibérément. La nouvelle instance doit démarrer, ouvrir son pool et passer sa sonde avant que l'ancienne soit vidée : pendant cette fenêtre, les deux détiennent des pools pleins. Si votre plateforme remplace les instances une à une, le chevauchement est moindre, mais le mode de panne est identique et mérite d'être vérifié.

Mon pool est bien sous la limite et j'ai quand même des erreurs de connexion. Pourquoi ?

En général quelque chose hors du pool. Cherchez les workers, les tâches planifiées et les scripts ponctuels qui ouvrent leurs propres connexions, une migration lancée pendant le déploiement, et des connexions fuitées par du code qui ne les rend pas. Le pool n'est que la part de la demande que vous avez configurée.

Un pool plus grand est-il plus rapide ?

Passé un seuil, non — il est plus lent. Une fois tous les cœurs de la base occupés, davantage de connexions simultanées ajoutent des changements de contexte et de la contention de verrous, pas du débit. L'effet mesurable d'un pool surdimensionné est généralement une pire latence de queue, pas un meilleur débit.

Où se place un pooler comme PgBouncer ?

Entre les deux chiffres. Il permet à un nombre important et variable de connexions clientes de partager un petit nombre fixe de connexions base — exactement ce que cet outil montre comme nécessaire lorsque les instances sont nombreuses ou imprévisibles. En mode transaction, il libère aussi les connexions entre instructions au lieu de les retenir pour la session.