In diesem Dokument sind die Kontingente und Limits für AlloyDB for PostgreSQL aufgeführt.
- Kontingente geben an, wie viel einer zählbaren, freigegebenen Ressource Sie verwenden können. Kontingente werden von Google Cloud -Diensten wie AlloyDB for PostgreSQL definiert.
- Systemlimits sind feste Werte, die nicht geändert werden können.
Kontingente
Google Cloud nutzt Kontingente, um Fairness zu gewährleisten und Spitzen bei Ressourcennutzung und -verfügbarkeit zu reduzieren. Ein Kontingent schränkt ein, wie viel von einerGoogle Cloud -Ressource Ihr Google Cloud -Projekt nutzen darf. Kontingente gelten für eine Reihe von Ressourcentypen, einschließlich Hardware, Software und Netzwerkkomponenten. Mit Kontingenten können Sie beispielsweise die Anzahl der API-Aufrufe an einen Dienst, die Anzahl der von Ihrem Projekt gleichzeitig verwendeten Load Balancer oder die Anzahl der Projekte begrenzen, die Sie erstellen können. Die Kontingente sollen eine Überlastung von Diensten verhindern und dadurch die Community derGoogle Cloud -Nutzer schützen. Außerdem können Sie mithilfe von Kontingenten Ihre eigenen Google Cloud -Ressourcen verwalten.
Das Cloud-Kontingentsystem ermöglicht Folgendes:
- Verbrauch von Google Cloud -Produkten und ‑Diensten überwachen
- Ihren Verbrauch dieser Ressourcen einschränken
- Eine Möglichkeit bieten, Änderungen am Kontingentwert anzufordern
Wenn Sie versuchen, mehr von einer Ressource zu verbrauchen, als das Kontingent zulässt, blockiert das System in den meisten Fällen den Zugriff auf die Ressource. Die Aufgabe, die Sie ausführen möchten, schlägt fehl.
Kontingente gelten in der Regel auf Google Cloud -Projektebene. Ihre Nutzung einer Ressource in einem Projekt hat keinen Einfluss auf Ihr verfügbares Kontingent in einem anderen Projekt. Innerhalb eines Google Cloud -Projekts werden die Kontingente für alle Anwendungen und IP-Adressen gemeinsam genutzt.
Google Cloud bietet außerdem kostenlose Testkontingente, die einen eingeschränkten Zugriff auf Projekte ermöglichen, um Google Cloud kostenlos zu testen.
Es gelten nicht für alle Projekte dieselben Kontingente. Wenn Sie Google Cloud stärker nutzen, können Ihre Kontingente erhöht werden.
Weitere Informationen zu Kontingenten finden Sie unter Mit Kontingenten arbeiten.
Informationen zu AlloyDB-Kontingenten finden Sie unter Ratenkontingente und Ressourcenkontingente.
Für AlloyDB-Ressourcen gelten außerdem Limits. Im Gegensatz zu Kontingenten können Systemlimits nicht geändert werden.
Berechtigungen zum Prüfen und Bearbeiten von Kontingenten
Um Ihre Kontingente aufzurufen, benötigen Sie die Berechtigung serviceusage.quotas.get.
Um Ihre Kontingente zu ändern, ist die Berechtigung serviceusage.quotas.update erforderlich.
Diese Berechtigungen sind standardmäßig in den einfachen IAM-Rollen "Inhaber" und "Bearbeiter" sowie in der vordefinierten Rolle "Kontingentadministrator" enthalten.
Kontingente prüfen
In der Tabelle mit den Kontingenten in der Google Cloud Console sind standardmäßig Kontingente für alle Dienste aufgeführt. Die aktuellen Kontingente für AlloyDB-Ressourcen in Ihrem Projekt finden Sie in der Liste Filter in der Tabelle.
So prüfen Sie die aktuellen Kontingente für AlloyDB-Ressourcen in Ihrem Projekt:
Rufen Sie in der Google Cloud Console die Seite Kontingente auf.
Klicken Sie in der Tabelle „Kontingente“ auf Filter.
Wählen Sie in der Liste Properties die Option Service und dann in der Liste Values die Option AlloyDB API aus.
Kontingente erhöhen
Bei einer intensiveren Nutzung von Google Cloud können Ihre Kontingente entsprechend erhöht werden. Wenn Sie eine deutlich höhere Nutzung erwarten, sollten Sie schon einige Tage vorher entsprechend höhere Kontingente anfordern.
- Klicken Sie auf der Seite Kontingente auf Filter.
Wählen Sie in der Liste Properties die Option Service und dann in der Liste Values die Option AlloyDB API aus.
Wenn Sie die AlloyDB API nicht sehen, wurde die AlloyDB Admin API nicht aktiviert.
Wählen Sie die Kontingente aus, die Sie ändern möchten.
Klicken Sie auf Kontingente bearbeiten.
Geben Sie Ihren Namen, Ihre E-Mail-Adresse und Ihre Telefonnummer ein und klicken Sie auf Weiter.
Geben Sie Ihre Kontingentanfrage ein und klicken Sie auf Anfrage senden.
Ratenkontingente
AlloyDB unterstützt Ratenkontingente, die auch als Ratenbegrenzungen oder API-Kontingente bezeichnet werden. Ratenkontingente definieren die Anzahl der Anfragen, die Sie an die AlloyDB Admin API senden können.
Jedes Ratenkontingent entspricht allen Anfragen für eine Gruppe von einer oder mehreren AlloyDB Admin API-Methoden. Ratenkontingente werden nach einem für den Dienst spezifischen Zeitintervall zurückgesetzt, z. B. die Anzahl der API-Anfragen pro Tag.
Wenn Sie die Google Cloud CLI oder die Google Cloud Console verwenden, stellen Sie Anfragen an die API. Diese Anfragen werden auf Ihre Ratenbegrenzungen angerechnet. Wenn Sie mithilfe von Dienstkonten auf die API zugreifen, werden diese Anfragen auch auf Ihr Ratenlimit angerechnet.
Die Ratenkontingente werden erzwungen und automatisch in 60-Sekunden-Intervallen (1 Minute) neu aufgefüllt. Wenn Ihr Projekt also innerhalb von 60 Sekunden das Maximum eines Ratenkontingents erreicht, müssen Sie warten, bis dieses Kontingent aufgebraucht ist, bevor Sie in dieser Gruppe weitere Anfragen stellen. Wenn Ihr Projekt eine Ratenbegrenzung überschreitet, erhalten Sie den HTTP-Statuscode 429 mit dem Grund rateLimitExceeded.
Die AlloyDB Admin APIs sind je nach Vorgangstyp in sechs Gruppen unterteilt. Die Ratenkontingente gelten pro Minute, API-Gruppe, Projekt, Region und Nutzer. Für jede eindeutige Kombination dieser Attribute gilt ein separates Kontingent. Wenn beispielsweise 100 Nutzer innerhalb einer Minute auf die Mutate APIs für ein bestimmtes Projekt und eine bestimmte Region zugreifen, erhält jeder Nutzer ein Standardkontingent von 180 bis 250 Anfragen pro Minute für jede Kombination aus Projekt und Region.
Der Standardkontingentbereich für jede Gruppe ist:
| Gruppenname | Beschreibung | Standardkontingentbereich in Anfragen pro Minute | API-Methoden |
|---|---|---|---|
| Connect APIs | Neue Kontakte knüpfen. | 180-2000 |
|
| APIs abrufen | Eine einzelne Ressource lesen | 180-1000 |
|
| Get-Vorgang-API | Ruft den letzten Status eines lang andauernden Vorgangs ab. | 950-1400 |
|
| APIs auflisten | Eine Gruppe von Ressourcen desselben Typs lesen | 180-1000 |
|
| List operations API | Listet Vorgänge auf, die zu einem bestimmten Filter in der Anfrage passen. | 2200-3000 |
|
| APIs mutieren | Ressourcenstatus ändern | 180-250 |
|
Ressourcenkontingente
AlloyDB unterstützt Ressourcenkontingente, auch als Allokationskontingente bezeichnet. Mit Ressourcenkontingenten wird festgelegt, wie viele Ressourcen eines Typs Sie maximal erstellen können, wenn diese Ressourcen verfügbar sind. Ressourcenkontingente begrenzen die Nutzung von Ressourcen, die keine Nutzungsrate haben, z. B. die Anzahl der VM-Instanzen, die zu einem bestimmten Zeitpunkt von Ihrem Projekt verwendet werden.
Ressourcenkontingente werden nicht nach Ablauf einer bestimmten Zeit zurückgesetzt. Stattdessen müssen Sie Maßnahmen ergreifen, um die nicht verwendeten Ressourcen freizugeben, z. B. einen nicht benötigten Cluster löschen.
Derzeit gelten Ressourcenkontingente für die Anzahl der verwendeten Cluster und vCPUs, wie in den folgenden Abschnitten beschrieben.
Ressourcenkontingente für Cluster
Dieses Kontingent gilt für die Anzahl der Cluster pro Projekt und Region. Der Standardwert für dieses Kontingent liegt je nach Nutzungsverlauf des Projekts zwischen 3 und 10 Clustern pro Projekt und Region. Der maximal unterstützte Wert für dieses Kontingent beträgt 15 Cluster pro Projekt und Region.
Wenn Sie über die Google Cloud Console, die gcloud CLI oder die AlloyDB Admin API eine Anfrage zum Erstellen oder Wiederherstellen eines Clusters stellen und dies zu einem Kontingentverstoß führt, schlägt die Anfrage fehl und Sie erhalten eine Fehlermeldung, die in etwa so lautet:
Quota limit 'ClustersUsedPerProjectPerRegion' has been exceeded. Limit: 5 in region us-central1.
Ressourcenkontingente für vCPUs
Dieses Kontingent gilt für die Anzahl der vCPUs pro Projekt und Region. Jede Instanz belegt einen Teil dieses Kontingents, je nachdem, wie viele VMs sie verwendet. Für jede Primärinstanz werden zwei VMs verwendet. Jede Read Pool-Instanz verwendet eine VM für jeden Knoten, den sie enthält. Die Anzahl der von jeder VM verwendeten vCPUs geben Sie beim Erstellen oder Aktualisieren der Instanz an.
Der Standardwert für dieses Kontingent liegt je nach Nutzungsverlauf des Projekts zwischen 128 und 512 vCPUs pro Projekt und Region.
Wenn Sie über die Google Cloud Console, die gcloud CLI oder die AlloyDB Admin API eine Instanz erstellen oder aktualisieren und dies zu einem Kontingentverstoß führt, schlägt die Anfrage fehl und Sie erhalten eine Fehlermeldung, die in etwa so aussieht:
Quota limit 'VCPUsUsedPerProjectPerRegion' has been exceeded. Limit: 128 in region us-central1.
Ressourcenkontingente für den Speicher
Dieses Kontingent gilt für die Datenmenge, die in jedem Cluster gespeichert werden kann. Der Standardwert für dieses Kontingent beträgt 16 TiB pro Cluster. Der maximal unterstützte Wert beträgt 128 TiB pro Cluster.
Wenn Sie eine Datenbankschreibanfrage stellen, z. B. eine INSERT-Anweisung, die zu einem Kontingentverstoß führt, schlägt die Anfrage mit der folgenden Fehlermeldung fehl:
AlloyDB instance exceeds available storage quota.
Ressourcenverfügbarkeit
Ressourcenkontingente sind keine Garantie dafür, dass jederzeit Ressourcen zur Verfügung stehen. Wenn eine Ressource für Ihre Region physisch nicht verfügbar ist, können Sie keine neuen Ressourcen dieses Typs erstellen, auch wenn in Ihrem Projekt noch ein ausreichendes Kontingent dafür vorhanden ist.
Limits
Fordern Sie einen Supportfall an, um eine Erhöhung des Limits anzufordern.
| Element | Limit |
|---|---|
| Lesepoolknoten pro Cluster (über alle Lesepoolinstanzen hinweg) | 20 |
| Maximale Anzahl gleichzeitiger Verbindungen pro Instanz | Standardmäßig 1.000, einstellbar bis 240.000 |
Maximale Anzahl gleichzeitiger Verbindungen
AlloyDB begrenzt die maximale Anzahl gleichzeitiger Verbindungen einer Instanz auf 1.000,es sei denn, Sie legen das Flag max_connections auf einen höheren Wert fest.
Verwenden Sie die folgende Tabelle als Richtlinie, um den Wert für die maximale Anzahl von Verbindungen anhand der Instanzgröße zu bestimmen:
| VCPU | Speicher | Empfohlener max_connections-Wert |
|---|---|---|
| 2 | 16 | 1000 |
| 4 | 32 | 2000 |
| 8 | 64 | 4000 |
| 16 | 128 | 5000 |
| 32 | 256 | 5000 |
| 64 | 512 | 5000 |
| 96 | 768 | 5000 |
| 128 | 864 | 5000 |
Beachten Sie die folgenden Hinweise, bevor Sie den Wert festlegen:
- Wenn Sie das Flag
max_connectionsfür eine Instanz des Lesepools festlegen, muss der neue Wert mit demmax_connections-Wert der primären Instanz des Clusters übereinstimmen oder ihn überschreiten. - Wir empfehlen, maximal vier gleichzeitige Abfragen pro vCPU der Instanz auszuführen.
- Für Arbeitslasten mit kurzfristigen Verbindungen sollten Sie einen Verbindungspooler wie pgbouncer oder pgpool-II verwenden.
- Wir empfehlen, einen anwendungsseitigen Verbindungspooler wie HikariCP oder c3p0 hinzuzufügen.
Wenn Sie den Wert auf einen Wert festlegen, der über den Empfehlungen liegt (bis zu 240.000), sollten Sie die zusätzliche Speichernutzung für jede aktive Verbindung berücksichtigen, die den Speicher für den freigegebenen Puffer verringern würde.
Dieser Speicherverbrauch kann berechnet werden, indem die Anzahl der gleichzeitigen Abfragen mit dem für das
work_mem-Flag festgelegten Wert multipliziert wird. Der Standardwert für dieses Flag ist4MBoder die Anzahl der vCPUs in der Instanz, je nachdem, was höher ist.