Tableau des paramètres d'instance

Lire une classe d'instance comme un jeu de valeurs de paramètres

Une classe d'instance ressemble à un fait en deux colonnes — tant de vCPU, tant de mémoire — mais c'est en réalité un ensemble de décisions déjà prises pour vous. La seule valeur de mémoire fixe le plafond de connexions, le cache tampon et la vision du monde du planificateur. Ce tableau affiche chaque instance à côté des valeurs de paramètres qu'implique sa mémoire, pour lire une classe comme la configuration qu'elle est réellement.

Comment ça marche

• Liste chaque classe d'instance du catalogue pour le cloud choisi, de la plus petite à la plus grande.
• Affiche la mémoire par vCPU, le moyen le plus rapide de distinguer une classe généraliste d'une classe optimisée mémoire.
• Donne max_connections par instance, calculé selon la règle publiée du fournisseur et le moteur sélectionné.
• Affiche shared_buffers ou innodb_buffer_pool_size et effective_cache_size, déduits des expressions par défaut de RDS.

colonnes et leur provenance
  vCPU, memoire    le tableau des classes d'instance du fournisseur
  Gio / vCPU       memoire divisee par vCPU
  max_connections  la regle publiee du fournisseur pour le moteur choisi
  shared_buffers        25% de la memoire  (PostgreSQL)
  innodb_buffer_pool    75% de la memoire  (MySQL)
  effective_cache_size  75% de la memoire  (indication au planificateur)

Exemple chiffré

Une classe d'instance, db.m5.2xlarge avec 8 vCPU et 32 Gio, lue sur les deux moteurs.

1. mémoire par vCPU = 32 ÷ 8 = 4 Gio, le rapport généraliste
2. PostgreSQL : environ 3 324 connexions, shared_buffers 8 Gio, effective_cache_size 24 Gio
3. MySQL : environ 2 518 connexions, innodb_buffer_pool_size 24 Gio
4. le même matériel, deux moteurs, et l'allocation de tampon diffère d'un facteur trois

PostgreSQL garde 25% pour lui et laisse le reste au cache du système ; MySQL réclame 75% pour InnoDB parce qu'il ne s'appuie pas sur ce cache. Ni l'un ni l'autre n'est un choix de réglage anodin : les deux découlent du choix de la classe, et c'est pourquoi la même instance se comporte différemment selon le moteur.

Lire le résultat

• La mémoire par vCPU dit à quoi sert une classe. Environ 2 Gio par vCPU vise le calcul, 4 Gio le généraliste, 8 Gio et plus l'optimisation mémoire — les classes r d'AWS, la série E d'Azure. Pour une base, les rapports élevés sont généralement le meilleur rapport qualité-prix, car la mémoire achète à la fois du cache et de la marge de connexions.
• B1ms d'Azure est la seule ligne qui déroge à son propre schéma : 50 connexions là où la règle par Gio en prédirait bien plus. Ce tableau reproduit les valeurs publiées d'Azure au lieu d'y ajuster une courbe, si bien que l'anomalie subsiste au lieu d'être lissée.
• La classe t d'AWS et la série B d'Azure sont burstables. Elles accumulent des crédits CPU au repos et bridant une fois les crédits épuisés, ce qui les rend excellentes pour le développement et médiocres sous charge de production constante — le tableau montre leur gabarit, pas cette réserve, alors gardez-la en tête.
• Les entrées Cloud SQL sont des gabarits personnalisés courants, pas un catalogue exhaustif, car Cloud SQL accepte presque n'importe quelle combinaison de vCPU et de mémoire. Considérez cette colonne comme représentative.
• Ces valeurs sont celles par défaut d'une instance, pas des limites. Les trois clouds permettent de les remplacer via un groupe de paramètres ou un indicateur, et les formules de connexions en particulier ne sont que des valeurs par défaut — voyez le calculateur de connexions maximales pour ce que coûte leur modification.

Questions fréquentes

Pourquoi max_connections change-t-il quand je change de moteur ?

Parce que chaque moteur a son propre diviseur dans la formule du fournisseur. Chez AWS, PostgreSQL divise la mémoire disponible par environ 9,5 Mo par connexion et MySQL par environ 12,6 Mo : la même instance donne donc moins de connexions MySQL. MariaDB utilise encore un autre diviseur depuis la 10.5.

Plus de mémoire par vCPU est-il toujours meilleur pour une base ?

Généralement oui, jusqu'à ce que l'ensemble de travail tienne en mémoire. Une fois les données touchées par les requêtes en cache, ajouter de la mémoire n'achète plus de vitesse mais seulement de la marge de connexions. Si votre jeu de données est petit et vos requêtes gourmandes en CPU — beaucoup de tris, d'agrégations ou de traitement JSON — un rapport plus faible avec plus de cœurs peut être le meilleur choix.

Puis-je modifier ces valeurs après le lancement ?

Oui, via un groupe de paramètres sur RDS, les paramètres serveur sur Azure ou les indicateurs de base sur Cloud SQL. Certains prennent effet immédiatement, d'autres exigent un redémarrage : shared_buffers et innodb_buffer_pool_size s'allouent au démarrage et relèvent de la seconde catégorie. Les valeurs par défaut affichées ici sont de bons points de départ et méritent une raison avant d'être remplacées.

Sources

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