Calculateur de connexions maximales

Combien de connexions une base managée vous accorde vraiment

Chaque base managée a un plafond de connexions, et aucun des trois grands clouds ne le fixe de la même façon. AWS le dérive d'une formule sur la mémoire de l'instance, Azure publie une table fixe par produit, et Google Cloud SQL utilise des paliers de mémoire qui progressent par sauts. Cet outil applique la règle publiée par chaque fournisseur, pour que vous connaissiez le vrai plafond avant de dimensionner un pool sur une intuition.

Comment ça marche

• Applique la règle documentée du fournisseur à l'instance choisie, et non une règle empirique.
• Affiche côte à côte le résultat de la formule et le résultat réaliste, car DBInstanceClassMemory est inférieure à la RAM de l'instance.
• Compare les trois clouds à mémoire égale — c'est là que les écarts deviennent impossibles à ignorer.
• Retranche les connexions qu'Azure réserve à la réplication et à la supervision, pour que le chiffre affiché soit celui dont dispose votre application.

AWS RDS, d'après les paramètres par défaut documentés
  PostgreSQL   LEAST({DBInstanceClassMemory/9531392}, 5000)
  MySQL        {DBInstanceClassMemory/12582880}
  MariaDB 10.5+ LEAST({DBInstanceClassMemory/25165760}, 12000)

Azure Flexible Server
  une table publiée par produit, environ 107 par Gio, plafonnée à 5000
  moins 15 réservées à la réplication et à la supervision

Google Cloud SQL
  des plages de mémoire publiées, borne basse incluse
  3,75-6 Gio -> 100   6-7,5 -> 200    7,5-15 -> 400
  15-30      -> 500  30-60  -> 600   60-120 -> 800
  120+       -> 1000

Exemple chiffré

Une db.r7g.xlarge sous PostgreSQL — 4 vCPU et 32 Gio de mémoire — et ce que les mêmes 32 Gio achètent ailleurs.

1. 32 Gio = 34 359 738 368 octets
2. 34 359 738 368 / 9 531 392 = 3 604 — la réponse de la formule
3. le plafond de 5 000 ne joue pas à cette taille, donc 3 604 tient
4. mais DBInstanceClassMemory n'est pas la RAM de l'instance : RDS retire d'abord le système et ses propres processus
5. en appliquant la surcharge documentée par AWS, on obtient environ 3 324 en pratique
6. Azure à 32 Gio : 3 437 au total, 3 422 utilisables après les 15 réservées
7. Google Cloud SQL à 32 Gio : 600, car 32 tombe dans la plage 30 à 60 Gio

Matériel identique, et Cloud SQL vous donne un cinquième de ce que donnent les deux autres. Si vous déplacez un service d'un cloud à l'autre, ce seul chiffre risque davantage de faire échouer la migration que tout ce que contient votre schéma.

Lire le résultat

• DBInstanceClassMemory n'est pas la mémoire annoncée sur la fiche. RDS réserve de la mémoire pour le système et ses propres processus de gestion, puis calcule la formule sur ce qui reste. AWS documente l'écart par un exemple : une instance de 8 Gio donne environ 630 connexions là où la division naïve en donne 683. Soit environ 8% de moins, à toutes les tailles.
• Google Cloud SQL fonctionne par plages publiées et non par formule : la limite ne monte donc pas régulièrement avec la mémoire — à l'intérieur d'une plage, elle ne monte pas du tout. Toute instance de 30 Gio à un peu moins de 60 Gio obtient les mêmes 600 connexions ; doubler la mémoire dans une plage n'apporte rien, et toute la hausse se produit à la borne.
• Azure traite B1ms comme un cas particulier à 50 connexions, en dehors du schéma par Gio par ailleurs cohérent. C'est pourquoi cet outil reproduit la table Azure littéralement plutôt que d'y ajuster une droite.
• Ce sont des valeurs par défaut, pas des limites dures. max_connections est un paramètre modifiable sur les trois clouds. L'augmenter est généralement le mauvais remède, car chaque connexion coûte de la mémoire et un processus — la raison même pour laquelle la valeur par défaut suit la mémoire.
• Une limite de connexions n'est pas un objectif de concurrence. Postgres n'accélère pas quand les connexions montent ; au-delà de quelques fois le nombre de cœurs, plus de connexions signifie plus de changements de contexte et moins de débit. Utilisez un pooler et gardez le pool nettement sous le plafond.

Questions fréquentes

Pourquoi mon instance annonce-t-elle un max_connections différent ?

Trois causes fréquentes. Le groupe de paramètres a pu être modifié, auquel cas votre valeur remplace entièrement la formule. La version du moteur compte — MariaDB a changé son diviseur en 10.5. Et chez AWS le chiffre bouge légèrement selon la mémoire exacte que rapporte l'hôte, d'où l'affichage des deux valeurs.

Puis-je simplement augmenter max_connections ?

Rarement une bonne idée. Chaque connexion PostgreSQL est un processus avec sa propre mémoire, et chaque connexion MySQL porte des tampons par thread. Relever le plafond déplace la panne : de connexions refusées, visibles et réversibles, vers une pression mémoire et l'OOM killer, qui ne sont ni l'un ni l'autre. Un pooler est presque toujours la meilleure réponse.

Un réplica de lecture a-t-il la même limite ?

Il a celle de sa propre classe d'instance, souvent identique puisque les réplicas correspondent généralement au primaire. Mais leurs connexions sont comptées séparément : router les lectures vers un réplica gagne donc réellement de la marge sur le primaire, au lieu de simplement déplacer le problème.

Pourquoi Cloud SQL est-il si bas ?

Google dimensionne la valeur par défaut sur ce que l'instance sert bien, non sur ce qu'elle accepte techniquement, et suppose qu'une charge à nombreuses connexions passe par un pooler. C'est un parti pris de conception, pas une contrainte matérielle — mais il est appliqué, donc il vous contraint quand même.

Sources

• Amazon RDS — quotas et contraintes
• Amazon RDS — classes d'instance de base de données
• Azure Database for PostgreSQL — limites
• Cloud SQL pour PostgreSQL — indicateurs