Vous trouverez sur cette page des informations sur les quotas et les limites de Cloud SQL. Les quotas sont appliqués par projet, tandis que les limites sont définies pour l'instance ou le projet.
Quotas
Un quota limite la quantité d'une ressource Cloud de Confiance by S3NS que votre projet Cloud de Confiance peut utiliser. Cloud SQL est un exemple de ce type de ressource.
Pour Cloud SQL, les quotas font partie d'un systÚme qui effectue les opérations suivantes :
- Surveiller votre utilisation ou votre consommation des instances Cloud SQL
- Restreindre la consommation de ces instances pour des raisons telles que l'équité et la réduction des pics d'utilisation
- Gérer des configurations qui appliquent automatiquement des restrictions recommandées
- Fournir un moyen de modifier le quota ou de demander des modifications
Dans la plupart des cas, lorsqu'un quota est dépassé, le systÚme bloque immédiatement l'accÚs à l'instance concernée et la tùche que vous essayez d'effectuer échoue. Les quotas s'appliquent à chaque projet Cloud de Confiance et sont partagés entre toutes les instances qui utilisent ce projet.
Autorisations permettant de vérifier et d'augmenter vos quotas
Pour vérifier et augmenter vos quotas, vous devez disposer des autorisations suivantes :
serviceusage.quotas.get:vérifier les quotasserviceusage.quotas.update:augmenter les quotas
Par dĂ©faut, ces autorisations sont incluses dans les rĂŽles IAM de base Ăditeur et PropriĂ©taire, ainsi que dans le rĂŽle prĂ©dĂ©fini Administrateur de quotas. Si vous avez besoin d'autorisations supplĂ©mentaires, contactez votre administrateur de quotas.
Vérifier les quotas
Pour vĂ©rifier les quotas actuels associĂ©s aux ressources de votre projet, accĂ©dez Ă la page Quotas de la consoleCloud de Confiance et filtrez sur l'API Cloud SQL Admin. Ces quotas ne s'appliquent qu'aux appels d'API. Ils n'incluent pas les requĂȘtes de base de donnĂ©es.
Augmenter les quotas
à mesure que votre utilisation de Cloud de Confiance s'accroßt, les quotas peuvent augmenter en conséquence. Si vous prévoyez une augmentation importante de l'utilisation, vous devez envoyer une demande quelques jours avant afin de toujours disposer du quota approprié.
Aucuns frais ne s'appliquent lorsque vous demandez une augmentation de quota. Vos coûts n'augmentent que si vous utilisez plus de ressources.
Pour augmenter vos quotas, procédez comme suit :
Dans la console Cloud de Confiance , accédez à la page Quotas.
Filtrez sur le service API Cloud SQL Admin.
Si ce service ne s'affiche pas, activez l'API Cloud SQL Admin.
Cochez les cases à cÎté des quotas que vous souhaitez modifier, puis cliquez sur Modifier les quotas.
Pour chaque quota sélectionné, saisissez la valeur de la limite souhaitée dans le champ Nouvelle limite.
Dans le champ Description de la raison, saisissez un motif pour votre demande d'augmentation de quota, puis cliquez sur Terminé.
Cliquez sur Suivant.
Indiquez votre nom, votre adresse e-mail et votre numéro de téléphone, puis cliquez sur Envoyer la demande.
Si vous ne parvenez pas à augmenter vos quotas, déposez une demande d'assistance.
Renouvellement des quotas de ressources
Les quotas quotidiens sont réinitialisés à minuit (heure du Pacifique),
Quotas et disponibilité des ressources
Les quotas de ressources reprĂ©sentent le nombre maximal de ressources que vous pouvez crĂ©er pour un type de ressources donnĂ©, sous rĂ©serve de disponibilitĂ©. Les quotas ne garantissent pas la disponibilitĂ© systĂ©matique des ressources. Si une ressource n'est pas disponible physiquement pour votre rĂ©gion, vous ne pouvez pas crĂ©er de ressources de ce type, mĂȘme si vous disposez du quota suffisant dans votre projet.
Les quotas de débit
Cloud SQL accepte les quotas de dĂ©bit, Ă©galement appelĂ©s limites de dĂ©bit ou quotas d'API. Les quotas de dĂ©bit dĂ©finissent le nombre de requĂȘtes que vous pouvez envoyer Ă l'API Cloud SQL Admin.
Chaque quota de dĂ©bit correspond Ă toutes les requĂȘtes pour une catĂ©gorie d'une ou plusieurs mĂ©thodes d'API Cloud SQL Admin. Les quotas de dĂ©bit sont rĂ©initialisĂ©s aprĂšs un dĂ©lai propre Ă Cloud SQL (par exemple, le nombre de requĂȘtes API par minute).
Lorsque vous utilisez la gcloud CLI ou la console Cloud de Confiance , vous envoyez des requĂȘtes Ă l'API Cloud SQL Admin. Ces requĂȘtes sont comptabilisĂ©es dans vos quotas de dĂ©bit. Si vous utilisez des comptes de service pour accĂ©der Ă l'API, ces requĂȘtes sont Ă©galement comptabilisĂ©es dans vos quotas de dĂ©bit.
Cloud SQL applique et remplit automatiquement les quotas de dĂ©bit sur des intervalles de 60 secondes. Si votre projet atteint une limite de quota de dĂ©bit Ă tout moment dans un dĂ©lai de 60 secondes, vous devez attendre que le quota soit rĂ©initialisĂ© avant d'effectuer d'autres requĂȘtes dans cette catĂ©gorie. Si votre projet dĂ©passe cette limite, vous recevez un code d'Ă©tat HTTP 429 pour le motif suivant : rateLimitExceeded.
L'API Cloud SQL Admin comprend les catégories suivantes :
- Se connecter : permet de rechercher les valeurs requises pour se connecter à une base de données Cloud SQL.
- Obtenir : permet de récupérer des informations sur une ressource (par exemple, une instance, une opération ou une sauvegarde).
- Liste : permet de répertorier les ressources.
- Modification : permet de créer, modifier et supprimer des ressources.
- Par défaut par région : permet d'interagir avec une instance Cloud SQL sans s'y connecter, la récupérer, la répertorier ni la modifier.
- Valeur par défaut : répertorie les options de base de données et les types de machines (niveaux) pour les instances Cloud SQL. Les API de cette catégorie sont globales.
Cloud SQL impose des quotas de débit pour chaque catégorie par minute, par utilisateur et par région. Pour chaque combinaison unique de ces attributs, Cloud SQL impose une limite de débit distincte.
L'API Cloud SQL Admin génÚre des métriques détaillées qui peuvent vous aider à suivre votre utilisation de l'API, surveiller les performances de votre instance Cloud SQL et de l'API, et identifier les problÚmes entre votre instance et l'API. Pour en savoir plus, consultez la section Surveiller l'utilisation des API.
Le tableau suivant fournit des informations sur la métrique, les API et la limite par défaut pour chaque catégorie :
| Catégorie | Métrique | API | Limite par défaut |
|---|---|---|---|
| Connexion |
Nombre de requĂȘtes effectuĂ©es par minute, par utilisateur et par rĂ©gion pour utiliser les API de cette catĂ©gorie. |
1000 | |
| Télécharger |
Nombre de requĂȘtes effectuĂ©es par minute, par utilisateur et par rĂ©gion pour utiliser les API de cette catĂ©gorie. |
500 | |
| Liste |
Nombre de requĂȘtes effectuĂ©es par minute, par utilisateur et par rĂ©gion pour utiliser les API de cette catĂ©gorie. |
500 | |
| Modification |
Nombre de requĂȘtes effectuĂ©es par minute, par utilisateur et par rĂ©gion pour utiliser les API de cette catĂ©gorie. |
|
180 |
| Par défaut par région |
Nombre de requĂȘtes rĂ©gionales par dĂ©faut effectuĂ©es par minute, par utilisateur et par rĂ©gion pour utiliser les API de cette catĂ©gorie. |
180 | |
| Par défaut |
Nombre de requĂȘtes par dĂ©faut effectuĂ©es par minute et par utilisateur pour utiliser les API de cette catĂ©gorie. |
180 |
Limites
Certaines ressources Cloud SQL non renouvelĂ©es rĂ©guliĂšrement sont soumises Ă des restrictions. Elles ne figurent pas sur la page "Quotas" de la console Cloud de Confiance . Certaines limites peuvent ĂȘtre augmentĂ©es, d'autres non.
Limites configurables
Instances par projet
Le nombre maximal d'instances que vous pouvez avoir dans un mĂȘme projet dĂ©pend de l'architecture rĂ©seau de ces instances :
- Nouvelle architecture réseau SQL : vous pouvez avoir jusqu'à 1 000 instances par projet.
- Ancienne architecture réseau SQL : vous pouvez avoir jusqu'à 100 instances par projet.
- Utilisation des deux architectures : votre limite se situera entre 100 et 1 000, en fonction de la répartition de vos instances entre les deux architectures.
Déposez une demande d'assistance si vous souhaitez augmenter cette limite. Les instances dupliquées avec accÚs en lecture sont considérées comme des instances.
Nous vous recommandons de répartir le nombre d'instances sur plusieurs projets afin de réduire la dépendance aux demandes d'augmentation de quota. Vous éviterez ainsi les blocages potentiels.
Nombre maximal de connexions simultanées
MySQL
Vous pouvez utiliser l'option
max_connections pour configurer une limite de connexions.
Lorsque vous créez une instance Cloud SQL pour MySQL, vous choisissez un type de machine, qui détermine la quantité de mémoire. La quantité de mémoire disponible détermine les limites de connexion pour l'instance.
Pour connaßtre la limite de connexions de votre instance, connectez-vous à votre base de données et exécutez cette commande : SHOW VARIABLES LIKE "max_connections";
PostgreSQL
Vous pouvez utiliser l'option max_connections pour configurer les limites de connexion. Lorsque vous crĂ©ez une instance Cloud SQL pour PostgreSQL, les paramĂštres de configuration du type de machine ajustent automatiquement la gamme de tailles de mĂ©moire disponible, en fonction du nombre de cĆurs sĂ©lectionnĂ©s. Les limites de connexion par dĂ©faut initiales de l'instance sont Ă©galement dĂ©finies.
Pour connaßtre les limites de connexion de votre instance, connectez-vous à votre base de données et exécutez cette commande : SELECT * FROM pg_settings WHERE name = 'max_connections';
La valeur sur les instances dupliquĂ©es doit ĂȘtre supĂ©rieure ou Ă©gale Ă la valeur de l'instance principale. Les modifications sur l'instance principale se propagent sur les instances dupliquĂ©es dont la valeur est infĂ©rieure Ă la nouvelle valeur principale ou dont la valeur par dĂ©faut n'a pas Ă©tĂ© modifiĂ©e.
Si la valeur sur l'instance principale est default, la valeur des instances dupliquĂ©es ne peut pas ĂȘtre modifiĂ©e. Pour modifier la valeur des instances dupliquĂ©es, commencez par dĂ©finir la valeur de l'instance principale sur un entier.
SQL Server
Le nombre réel de connexions utilisateur autorisées dépend de la version de SQL Server que vous utilisez, ainsi que des limites de vos applications et de votre matériel. SQL Server autorise un maximum de 32 767 connexions utilisateur.
Pour plus d'informations sur la configuration des connexions utilisateur dans SQL Server, reportez-vous à la documentation de référence.
Mises en garde
Utilisation du quota des connecteurs Cloud SQL
Le proxy d'authentification Cloud SQL et les autres connecteurs Cloud SQL utilisent le quota de l'API Cloud SQL Admin. Les connecteurs Cloud SQL fonctionnent en exécutant une opération d'actualisation environ toutes les heures. Cette opération d'actualisation effectue deux appels d'API : l'un récupérant les métadonnées de l'instance, l'autre un certificat éphémÚre.
L'utilisation du quota est calculée comme suit :
Quota usage = connector processes running * instances * 2 API calls per hour
Par exemple, si trois processus exécutent un connecteur, que celui-ci est configuré pour se connecter à deux instances Cloud SQL et que deux appels d'API sont effectués pendant une heure, votre consommation de quota est de 12 (3 processus * 2 instances * 2 appels d'API).
Si vous commencez tout juste Ă utiliser Cloud SQL, notez la formule ci-dessus et soyez attentif aux points suivants :
La vitesse à laquelle vous faites évoluer les nouveaux clients de base de données
La vitesse d'ajout des instances
L'utilisation de comptes de service différents pour chaque application
Authentification IAM pour les bases de données dans Cloud SQL
Chaque instance dispose d'un quota de connexion par minute, qu'il s'agisse de connexions réussies ou pas. Lorsque le quota est dépassé, les connexions sont temporairement indisponible. Nous vous recommandons d'éviter les connexions fréquentes et de restreindre les connexions à l'aide de réseaux autorisés. Le quota d'autorisation de connexions est de 12 000 par minute et par instance.
Quota de rĂšgle de transfert
Chaque instance Cloud SQL se compose d'une rĂšgl de transfert et d'un Ă©quilibreur de charge. Une limite de quota s'applique Ă la rĂšgle de transfert, en fonction du type d'Ă©quilibreur de charge vers lequel elle pointe. Il existe plusieurs quotas pour chaque type de rĂšgle de transfert, par projet, par rĂ©seau et par groupe d'appairage. Il existe Ă©galement une rĂšgle de remplacement pour les quotas par rĂ©seau et par groupe d'appairage pour Cloud SQL. Cela signifie que lorsque nous atteignez le quota par rĂ©seau pour les rĂ©seaux de producteurs, le quota par groupe d'appairage est Ă©galement augmentĂ© Ă la mĂȘme valeur.
Le VPC de producteurs Cloud SQL est appairé au VPC du client. Nous atteignons donc souvent le quota par réseau pour le réseau de producteurs Cloud SQL et le quota de groupe d'appairage pour le VPC du client.
Lorsque le quota est atteint, certaines opérations peuvent échouer, y compris les suivantes :
Opération de création : nous avons besoin de nouvelles rÚgles de transfert lorsque nous créons de nouvelles instances.
Opération de mise à jour : nous permettons aux clients de changer de réseau d'instances. Nous avons donc besoin de nouvelles rÚgles de transfert dans le nouveau réseau.
Opération de maintenance : les rÚgles de transfert sont recréées.
Pour éviter tout problÚme, nous vous recommandons de limiter le nombre total d'instances par réseau à moins de 500.
Si vous rencontrez un problÚme, déposez une demande d'assistance. Nous augmenterons le quota en fonction de vos besoins.
Limites fixes
IOPS
Les IOPS correspondent au nombre d'opérations d'entrée/de sortie (ou de lecture/écriture) que votre disque peut traiter par seconde.
Cloud SQL utilise des machines virtuelles (VM) Compute Engine équipées de disques de stockage persistants. Pour en savoir plus sur les caractéristiques de performances spécifiques des VM, consultez le tableau du nombre maximal d'IOPS soutenues sur la page Performances des disques persistants.
Limites des tables
Cloud SQL pour MySQL impose une limite de 50 000 tables par dĂ©faut, ou 500 000 tables pour une instance si vous respectez une configuration matĂ©rielle d'au moins 32 cĆurs et 200 Go de mĂ©moire. Pour des performances optimales, nous vous recommandons de ne pas cumuler plus de 50 000 tables dans une mĂȘme base de donnĂ©es.
Les instances qui dépassent ces limites ne sont pas couvertes par le contrat de niveau de service. Lorsqu'une table atteint la taille de 16 To, soit la taille maximale pour une partition Linux, il n'est plus possible d'ajouter des données.
La mémoire requise par votre instance dépend de différents facteurs. Pour en savoir plus sur la maniÚre dont Cloud SQL pour MySQL utilise la mémoire, consultez la page Utilisation de la mémoire par MySQL.
Si le nombre de vos tables actives est supérieur aux valeurs par défaut de Cloud SQL, ou si la taille globale du cache est considérable, vous devez ajuster votre instance. Pour maintenir des performances optimales, vous pouvez :
- passer à l'édition Cloud SQL Enterprise Plus pour bénéficier d'options de mémoire plus élevées ;
- mettre à niveau votre machine Cloud SQL pour ajouter de la mémoire à votre instance ;
- réduire la valeur de l'option de base de données
innodb_buffer_pool_size.
Les options
table_open_cache et
table_definition_cache
peuvent ĂȘtre utilisĂ©es pour modifier le cache de la table Cloud SQL pour MySQL.
Vous pouvez utiliser le schéma de performance pour obtenir une estimation de la taille du cache des tables pour votre instance.
Si le nombre de tables actives est considérablement plus élevé que les valeurs par défaut des tables Cloud SQL et du nombre de tables ouvertes recommandé par MySQL, Cloud SQL recommande de configurer les options de base de données table_open_cache et table_definition_cache sur le nombre de tables actives de votre instance.
Pour en savoir plus, consultez la page Ouverture et fermeture de tables par MySQL.
La taille maximale des tables pour Cloud SQL pour PostgreSQL est de 32 To. Lorsqu'une table atteint la taille de 32 To, il n'est plus possible d'ajouter des données.
Limite sur les opérations
Les types de machines de niveaux "micro" et "small" limitent le nombre d'opérations simultanées.
Le dépassement de ces limites entraßne une erreur Too many operations.
Le type de machine db-custom-1-3840 (processeur unique) est limité à 50 opérations simultanées.
Limites d'executeSQL
Les requĂȘtes envoyĂ©es Ă l'API REST ExecuteSQL sont soumises Ă certaines limites.
- Il ne peut pas y avoir plus de 10 requĂȘtes simultanĂ©es par instance Ă la fois.
- Les requĂȘtes sont limitĂ©es Ă 100 requĂȘtes par minute.
- Les requĂȘtes sont limitĂ©es Ă 0,5 Mo et les rĂ©ponses ne peuvent pas dĂ©passer 10 Mo.
Limite sur la collecte de métriques
Les métriques PostgreSQL sont collectées pour un maximum de 500 bases de données. S'il existe plus de 500 bases de données, seules les 500 premiÚres bases de données sont incluses pour une métrique donnée. Ces bases de données ont le nombre de transactions le plus élevé.
Limites de stockage de Cloud SQL
- CĆur dĂ©diĂ© : jusqu'Ă 64 To.
- CĆur partagĂ© : jusqu'Ă 3 To.
Pour en savoir plus, consultez la section Tarifs des instances.
Options de stockage de Cloud SQL
Pour configurer une option de stockage et obtenir des performances optimales, il est important de comprendre votre charge de travail, et de choisir la taille et le type de disque appropriés. Pour en savoir plus sur les options disponibles pour Cloud SQL, consultez les paramÚtres des instances.Limites d'App Engine
Chaque instance App Engine exécutée dans un environnement standard ne peut pas avoir plus de 100 connexions simultanées à une instance. Pour les applications en PHP 5.5, la limite est de 60 connexions simultanées.
Les applications App Engine sont soumises Ă des dĂ©lais de requĂȘtes selon l'utilisation et l'environnement. Pour en savoir plus, dĂ©couvrez comment les instances sont gĂ©rĂ©es dans les environnements standard et flexible d'App Engine.
Les applications App Engine sont également soumises à d'autres quotas et limites App Engine, comme indiqué sur la page Quotas d'App Engine.
Limites de Cloud Run
Si vous utilisez la connexion Cloud SQL intégrée sur Cloud Run, les instances de conteneur Cloud Run sont limitées à 100 connexions par base de données Cloud SQL.
Chaque instance d'un job ou d'un service Cloud Run peut avoir 100 connexions à la base de données, et le nombre total de connexions par déploiement peut augmenter à mesure que ce service ou ce job évolue.
Cette limite ne s'applique pas lorsque vous utilisez d'autres méthodes de connexion, telles que le proxy d'authentification Cloud SQL dans un sidecar, les connecteurs de langage Cloud SQL ou lorsque vous vous connectez directement à l'adresse IP de l'instance Cloud SQL.
Limites de Cloud Run Functions
Dans Cloud Run Functions (1re gĂ©nĂ©ration), les exĂ©cutions simultanĂ©es sont limitĂ©es Ă une par instance. Il n'arrive jamais qu'une seule instance de fonction 1re gĂ©nĂ©ration traite deux requĂȘtes en mĂȘme temps. Dans la plupart des cas, une seule connexion Ă la base de donnĂ©es suffit.
Cloud Run Functions (2e génération) est basé sur Cloud Run et dispose d'une limite de 100 connexions de base de données par instance.
Limites des requĂȘtes enregistrĂ©es
| Valeur | Limite |
|---|---|
| Nombre maximal de requĂȘtes enregistrĂ©es par projet (y compris les requĂȘtes enregistrĂ©es pour d'autres produits Cloud de Confiance by S3NS ) | 10 000 |
| Taille maximale de chaque requĂȘte | 1 Mio |
Limites de stockage de Cloud SQL
- CĆur dĂ©diĂ© : jusqu'Ă 64 To.
- CĆur partagĂ© : jusqu'Ă 3 To.
Pour en savoir plus, consultez la section Tarifs des instances.
Options de stockage de Cloud SQL
Pour configurer une option de stockage et obtenir des performances optimales, il est important de comprendre votre charge de travail, et de choisir la taille et le type de disque appropriés. Pour en savoir plus sur les options disponibles pour Cloud SQL, consultez les paramÚtres des instances.Limites d'App Engine
Chaque instance App Engine exécutée dans un environnement standard ne peut pas avoir plus de 100 connexions simultanées à une instance. Pour les applications en PHP 5.5, la limite est de 60 connexions simultanées.
Les applications App Engine sont soumises Ă des dĂ©lais de requĂȘtes selon l'utilisation et l'environnement. Pour en savoir plus, dĂ©couvrez comment les instances sont gĂ©rĂ©es dans les environnements standard et flexible d'App Engine.
Les applications App Engine sont également soumises à d'autres quotas et limites App Engine, comme indiqué sur la page Quotas d'App Engine.
Limites de Cloud Run
Si vous utilisez la connexion Cloud SQL intégrée sur Cloud Run, les instances de conteneur Cloud Run sont limitées à 100 connexions par base de données Cloud SQL.
Chaque instance d'un job ou d'un service Cloud Run peut avoir 100 connexions à la base de données, et le nombre total de connexions par déploiement peut augmenter à mesure que ce service ou ce job évolue.
Cette limite ne s'applique pas lorsque vous utilisez d'autres méthodes de connexion, telles que le proxy d'authentification Cloud SQL dans un sidecar, les connecteurs de langage Cloud SQL ou lorsque vous vous connectez directement à l'adresse IP de l'instance Cloud SQL.
Limites de Cloud Run Functions
Dans Cloud Run Functions (1re gĂ©nĂ©ration), les exĂ©cutions simultanĂ©es sont limitĂ©es Ă une par instance. Il n'arrive jamais qu'une seule instance de fonction 1re gĂ©nĂ©ration traite deux requĂȘtes en mĂȘme temps. Dans la plupart des cas, une seule connexion Ă la base de donnĂ©es suffit.
Cloud Run Functions (2e génération) est basé sur Cloud Run et dispose d'une limite de 100 connexions de base de données par instance.